429 Too Many Requests（リクエスト過多）

TL;DR — 429 Too Many Requestsは、サーバーが訪問者やボットに「短時間にページを要求しすぎています。速度を落としてください」と伝えることを意味します。これをレート制限と呼びます。SEOにとって良い知らせは、429がこの仲間の中でGoogleが穏やかに扱う唯一のエラーだということです。ページを削除する代わりに、Googlebotはしばらく速度を落としてクロールします。問題になるのは、サーバーが何日も429を返し続ける場合だけです。

429が実際に伝えること

ブラウザー、スクリプト、検索エンジンのクローラーがサーバーにページを要求するたび、サーバーはステータスコードで応答します。200は「ページはこちら」という意味です。429は「短時間にリクエストを送りすぎたため、今回は応答しません。後でもう一度来てください」という意味です。

サーバーは自身を守るために、意図的に429を使います。訪問者（またはボット）がサイトを全員にとって遅くするほど高速に叩いているなら、429を返すことで「少しの間やめてください」と伝えます。適切な429レスポンスにはRetry-Afterヘッダーも含まれます。これは、再試行する前に何秒待つべきかをクライアントに伝えるメモです。 Evidence for this claim A 429 response means the user sent too many requests in a given time, and the response may include Retry-After. Scope: RFC 9110 defines the status and optional Retry-After field; it does not define a universal rate threshold. Confidence: high · Verified: 2026-07-14 IETF: RFC 9110 §15.5.20 — 429 Too Many Requests

429がSEOにとって「親切な」エラーである理由

ここが意外な点です。429は、403 Forbiddenや404 Not Foundと並ぶ「4xxクライアントエラー」グループに属します。この2つをGoogleが見続けると、検索からページを削除するため悪い知らせです。

429は例外です。Googleは429を*“server overloaded, slow down”* (翻訳)「サーバーが過負荷なので速度を落としてほしい」と読み取り、503や500のサーバーエラーと同じように扱います。そのため、ページを削除する代わりに、Googlebotはしばらくサイトのクロールを遅くします。Googleは実際に、クローラーを遅くする正しい方法として429を推奨し、そのために403や404を使わないよう明確に警告しています。 Evidence for this claim Google treats 429 as a server-overload signal that reduces crawl rate and recommends 429, 500, or 503 for temporary crawl reduction instead of other 4xx codes. Scope: Google's guidance covers Google crawler behavior and short-term overload; it does not promise indexing preservation during prolonged unavailability. Confidence: high · Verified: 2026-07-14 Google: Reduce Google crawl rate

429が問題になる場合

429が時々出るのはまったく正常で、自然に回復します。サーバーが返すのをやめると、Googleは自動的にクロール速度を戻します。何かを申請する必要はありません。

危険なのは429が続く場合です。Googlebotが1〜2日を超えて同じページに429を受け続けると、Googleからはサイトが何日も壊れて利用できないように見えるため、そのページをインデックスから外し始める可能性があります。429は恒久的な設定ではなく、短期的な手段です。

どう対応するか

• この応答を返すつもりがなかった場合（Google Search Consoleやクロールツールに突然出てきた場合）、何かが過度にレート制限しています。セキュリティプラグイン、ファイアウォール（WAF）、ホスティング／CDNがよくある原因です。原因を見つけ、実際の検索エンジンをブロックしないよう制限を緩めます。
• この応答を意図的に返していた場合 — サーバーに大きな負荷がかかっている場合など — それ自体は問題ありません。ただし時間を区切り、Retry-Afterヘッダーを追加してください。1〜2日以内に停止します。

サーバー設定の方法、Googleの正確な文言、人々が間違えている神話を知りたいなら、Advancedタブに切り替えてください。

TL;DR — 429は、Googleが5xxのように扱う唯一の4xxコードです。500／503／429レスポンスを一定数検出すると、Googleはそれをサーバー過負荷の信号と読み、コンテンツを削除する代わりに、Googlebotのクロールレートをホスト名全体で抑制します。クローラーを遅くするためにGoogleが推奨する唯一のコードであり、403や404は使いません。Googleの文書は緊急時の目安を「a couple of hours, or 1–2 days」 (翻訳)「数時間、または1〜2日」としています。安全な期間を保証するものではありません。同じURLへの429が続けば、URLが最終的にインデックスから外れるリスクがあり、エラー量が減るとスロットルは再び増加し始めます（必ずしも即時または完全ではありません）。RFC 6585は429が条件を説明することを推奨し、Retry-Afterを含めてもよいとしています。送るのは推奨実務であり、準拠の必須条件ではありません。正しいトラフィックに制限を適用し、例外を書く前にクローラーの身元を確認してください。

プロトコルレベルでの429

仕様をそのまま、MDNは次のように説明しています。「The HTTP 429 Too Many Requests client error response status code indicates the client has sent too many requests in a given amount of time. This mechanism of asking the client to slow down the rate of requests is commonly called ‘rate limiting.’」 (翻訳)「HTTP 429 Too Many Requestsクライアントエラーレスポンスステータスコードは、クライアントが一定時間内にリクエストを送りすぎたことを示します。クライアントにリクエストの速度を落とすよう求める仕組みは、一般に『レート制限』と呼ばれます。」 Evidence for this claim A 429 response means the user sent too many requests in a given time, and the response may include Retry-After. Scope: RFC 9110 defines the status and optional Retry-After field; it does not define a universal rate threshold. Confidence: high · Verified: 2026-07-14 IETF: RFC 9110 §15.5.20 — 429 Too Many Requests

RFC 6585 §4は、多くの要約より正確です。429の表現は条件を説明すべきであり、クライアントが再試行前に待つ具体的な秒数（RFC 9110ではHTTP日付も可）を示すRetry-Afterヘッダーを含めてもかまいません。Retry-Afterは推奨実務であり、準拠の必須条件ではありません。仕様は、クライアントをどう識別するか、リクエストをどう数えるかも定義していません。IP、セッション、APIキー、リソースごとなど、レスポンスを発行した側の実装ポリシーに任されています。見落としやすいもう1つのルールとして、RFC 6585では429レスポンスをキャッシュに保存してはなりません。健全なオリジンなのに429がキャッシュ済みまたは再生されたように見えるなら、オリジンが再び制限を判断したのではなく、中間層（CDN、プロキシ）の不具合です。

私はいつも、HTTPステータスコードとSEOへの影響 ガイドで、429を「a form of rate-limiting to protect the server because the client sent too many requests to the server too fast.」 (翻訳)「クライアントがサーバーへ高速にリクエストを送りすぎたため、サーバーを保護するレート制限の一形態」と平易に説明しています。名目上はクライアントエラーです。クライアントが要求しすぎたという意味で、クライアント側が間違えています。しかし、SEOの話が仕様から分岐するのは、まさにこの点です。

4xxコードにおける唯一の例外

このページで最も重要な事実は、Googleが429を4xxファミリーの他のコードと同じように扱わないことです。Gary Illyesは2023年2月、このことについてGoogle Search Centralのブログ記事全体を書きました。十分な数のサイトやCDNがGooglebotを抑えるために、見つからない応答を誤用していたため、Googleが止めるよう伝える必要があったのです。

彼のルールはこうです。「The one exception is 429, which stands for ‘too many requests’. This error is a clear signal to any well-behaved robot, including our beloved Googlebot, that it needs to slow down because it’s overloading the server.」 (翻訳)「唯一の例外は429で、too many requestsを意味します。このエラーは、私たちが愛するGooglebotを含む、適切に動作するすべてのロボットに、サーバーに過負荷をかけているため速度を落とす必要があるという明確な信号です。」そしてGoogleのステータスコードリファレンスには、「Don’t use 401 and 403 status codes for limiting the crawl rate. The 4xx status codes, except 429, have no effect on crawl rate.」 (翻訳)「クロールレートの制限に401や403のステータスコードを使わないでください。429を除く4xxステータスコードはクロールレートに影響しません。」とあります。

つまり、403と404がコンテンツを検索から削除する一方、429は一時的な低速化をもたらします。Googleは文字どおりサーバーエラーと同じ分類に入れています。「Google’s crawlers treat the 429 status code as a signal that the server is overloaded, and it’s considered a server error.」 (翻訳)「Googleのクローラーは429ステータスコードをサーバーが過負荷である信号として扱い、サーバーエラーとみなします。」 Evidence for this claim Google treats 429 as a server-overload signal that reduces crawl rate and recommends 429, 500, or 503 for temporary crawl reduction instead of other 4xx codes. Scope: Google's guidance covers Google crawler behavior and short-term overload; it does not promise indexing preservation during prolonged unavailability. Confidence: high · Verified: 2026-07-14 Google: Reduce Google crawl rate

この点が、429を503 Service Unavailable（従来のメンテナンス／一時利用不可の信号）の便利な姉妹コードにしています。そして、多くのファイアウォールがデフォルトで使うにもかかわらずレート制限には不適切な403 Forbiddenとは正反対です。

クロールレートへの影響はホスト名全体 — ただししきい値がある

ここでは2つの異なる範囲が混同されるため、分けて考える価値があります。レート制限をどう数え、何をキーにするか（IP、セッション、APIキー、リソース、サーバー単位）は、あなた自身のポリシーです。HTTP仕様は定義していません。Googleが観測したエラーをどう扱うかは別の、文書化された動作であり、単一のレスポンスではなく量が条件になります。「Google’s crawling infrastructure reduces your site’s crawling rate when it encounters a significant number of URLs with 500, 503, or 429 HTTP response status codes.」 (翻訳)「Googleのクロールインフラは、500、503、429 HTTPレスポンスステータスコードを返すURLを相当数検出すると、サイトのクロールレートを下げます。」しきい値に達すると、「the reduced crawl rate affects the whole hostname of your site (for example, subdomain.example.com), both the crawling of the URLs that return errors, as well as the URLs that return content.」 (翻訳)「低下したクロールレートは、サイトのホスト名全体（たとえばsubdomain.example.com）に影響し、エラーを返すURLとコンテンツを返すURLの両方が対象になります。」

つまり、たとえば重いAPIパスなど、ページの一部を実際に大量の429にすると、Googlebotはホスト名全体（まだ200を返しているページも含む）のクロールを遅くします。総負荷を減らすことが目的なら、通常これは意図した効果です。ただし、1つのパスに単独で出た429だけでは、ホスト名全体への影響が起きたとはいえません。Google自身の表現は、1件ではなくエラーレスポンスの「相当数」に範囲を限定しています。

1〜2日の指針 — 429が危険になるとき

429は短期的な信号であり、Googleは緊急時の具体的な利用目安を示しています。安全な期間や明確な境界を保証するものではありません。「reduce crawl rate」文書には、「If you need to urgently reduce the crawl rate for short period of time (for example, a couple of hours, or 1-2 days), then return 500, 503, or 429 HTTP response status code instead of 200 to the crawl requests.」 (翻訳)「短期間（たとえば数時間、または1〜2日）にクロールレートを緊急に下げる必要があるなら、クロールリクエストには200ではなく500、503、429 HTTPレスポンスステータスコードを返してください」とあります。

そこを超えると、Googleは約束ではなく可能性として、より危険な領域だと説明しています。「We don’t recommend that you do this for a long period of time (meaning, longer than 1-2 days) as it may have a negative effect on how your site appears in Google products… if Googlebot observes these status codes on the same URL for multiple days, the URL may be dropped from Google’s index.」 (翻訳)「長期間（1〜2日を超える期間）これを行うことは推奨しません。Google製品でのサイトの表示に悪影響を与える可能性があり、Googlebotが同じURLでこれらのステータスコードを複数日にわたり確認すると、URLがGoogleのインデックスから外れる可能性があります。」ステータスコードリファレンスも5xxと429について同じことを述べています。「already indexed URLs are preserved in the index, but eventually dropped.」 (翻訳)「すでにインデックスされたURLはインデックスに保持されますが、最終的には削除されます。」

リスクモデルを正直に言うと、短期的な429はGoogleが緊急利用に推奨する範囲に合います。同じURLへの429が複数日にわたって続くと、Google自身の文言が「may」「eventually dropped」に変わります。これは文書化されたリスクですが、どちらの結果も保証されたものではありません。長期間の503と同じ動きです。

クロールレートは自動的に回復する

安心できる反対側の話として、サイトに付きまとうペナルティフラグはありません。エラーが収まるとGoogleは「the crawl rate will automatically start increasing again.」 (翻訳)「クロールレートは自動的に再び増加し始める」と述べています。申請も再リクエストも不要です。ただし、正確な文言に注意してください。Googleは「starts increasing」と述べており、“instantly returns to your prior rate.” (翻訳)「以前のレートに即座に戻る」とは述べていません。固定の期間や保証された終点のない、文書化された方向性として扱い、SLAとは考えないでください。

これは反対の問題、つまりGoogleに恒久的にクロールを減らしてほしい場合とは対照的です。エラーを配信できないなら、Googleは*「file a special request to report a problem with unusually high crawl rate」* (翻訳)「異常に高いクロールレートの問題を報告する特別なリクエストを送る」よう案内しています。数日かかることがある手動経路で、保証もありません。回復にはそのような面倒はありません。

Bingは429をどう扱うか

Bingbotも同様に動作すると広く報告されています。429／500／503が過負荷を示し、Bingbotが速度を落とすというものです。ただし今回の調査では、Bing自身のヘルプページ（静的テキストを取得できないJS描画SPAでした）で現在の文言を独自に確認できませんでした。この一致の主張は業界の報道として扱い、現行のBing文書で私が検証したものとは扱わないでください。Bingが過去のガイダンスで確認しているのは、Googleが同じ形では提供していない2つの先回り型コントロールです。

• クロール制御（Bingウェブマスターツール）— 1秒あたりのリクエスト数を時間帯ごとに設定するグリッドです。
• crawl-delay robots.txtディレクティブ。 現在のBing Webmasterガイダンス では、1〜20秒の値が文書化されています。Bing固有の機能であり、Googlebotを抑制しません。

したがってBingでは、ステータスコードで事後対応する代わりに、crawl-delayまたはCrawl Controlで先回りして速度を制限できます。（Googleは2024年に手動のクロールレートスライダーを廃止し、現在はサーバーのレスポンスに全面的に依存しています。）

意図的に429を返す場合

意図的に429を返す正当な理由：

• 緊急のサーバー負荷 — トラフィック急増、失敗した移行、障害など、数時間だけGooglebotに今すぐ速度を落としてほしい場合。
• APIやHTML以外のエンドポイントをボットの悪用から守る — 検索エンジンのクローラー、サードパーティのSEOクローラー（Ahrefs、Screaming Frog）、スクレーパーはいずれも、悪用を止めるためのレート制限に当たります。

429の用途ではないもの：望まないボットを恒久的にブロックすることです。何かを絶対にクロールさせたくないなら、それは429ではなくrobots.txtのdisallowの仕事です。ページを維持しつつインデックスから外したいならnoindexです。429は「後で」であり、「決して」ではありません。

意図しないレート制限応答 — よくある原因

GSCのページのインデックス登録またはクロール統計レポートにこの応答が出ていて、自分で設定した覚えがない場合、原因は通常このいずれかです。どれが最も多いかを示す普遍的な確かな証拠は知らないため、診断結果ではなく、該当するか除外する候補のリストとして扱います。

• WAF／ファイアウォールルールが正当なクローラーのIP範囲に誤って発動している。
• 共有ホスティングやCDNのデフォルトのレート制限が、実際のクロールには厳しすぎる。
• ボット管理ツールがGooglebotやBingbotを悪質なトラフィックと誤分類している。
• 強すぎるレート制限ミドルウェアが、API悪用向けの設定で自分のクローラーまで捕捉している。

しきい値を変更したり、実際の検索ボットを除外するルールを書いたりする前に、まず発生源を確立してください。どの層がレスポンスを所有しているか推測しないでください。生のレスポンスヘッダー、正確なリクエストログ行（ダッシュボードの要約ではないもの）、発動したルールまたはレート制限ゾーンの識別子、カウント対象となったクライアントキー（IP、セッション、APIキー）、ルート、CDNのPOP／エッジロケーション、時間帯を取得します。これらの組み合わせで、どの層が429を発行し、何を数えていたかが分かります。その後で初めて、制限を緩めたり例外を追加したりする意味が生じます。クローラーの身元は、ユーザーエージェント文字列だけでなく、リバースDNSとフォワードDNS（Googleの公式手法）で確認してください。偽装された「Googlebot」ユーザーエージェントは一般的です。正確なコマンドはScriptsタブにあります。

プレイブックの短い版

1. クローラーを遅くするには、Retry-After付きの429または503を使う — 403や404は決して使わない。
2. 数時間、または1〜2日にとどめる — それを超えるとURLが削除される可能性がある。
3. スロットルはホスト名全体に及び、エラーが止まると自動回復することを覚えておく。
4. 制限を正しいトラフィックに適用し、ボットを除外する前にクローラーの身元を確認する。

AIによる要約

Advanced版の要点をまとめます。

• 429 Too Many Requests＝サーバーがクライアント（ブラウザー、スクリプト、クローラー）に、リクエストを速く送りすぎたと伝える状態、つまり「レート制限」です。名目上は4xxのクライアントエラーです。
• プロトコルレベル： RFC 6585では、429レスポンスは条件を説明すべきで、Retry-Afterを含めてもよいとされています。推奨であり必須ではありません。キャッシュに保存してはならず、キャッシュ済み／再生された429はオリジンではなく中間層のバグです。制限をどう数え、キーにするか（IP、セッション、APIキー、リソース）は自分のポリシーで、仕様は定義しません。
• 4xx唯一の例外： Googleは429を403／404のような4xxではなく、5xxサーバーエラーのように扱います。“server overloaded, slow down” (翻訳)「サーバーが過負荷なので速度を落とす」と読み、コンテンツを削除する代わりにクロールレートを抑えます。
• Googleはクローラーを遅くするために429（および500／503）を推奨し、403や404は決して推奨しません。 Gary Illyesは2023年、Googlebotを抑えるために404を使うサイトやCDNに停止を求める記事を書きました。
• スロットルはしきい値を超えるとホスト名全体に及ぶ。 Google自身の文言は、単一の429ではなく500／503／429レスポンスを「相当数」検出した場合に、ホスト名全体へ影響するとしています。しきい値を超えると、200を返しているページもクロールが減ります。
• 1〜2日の指針は、硬い境界ではない。 Googleの文書は「a couple of hours, or 1–2 days」 (翻訳)「数時間、または1〜2日」という緊急時の目安を示します。同じURLへの429が複数日続くと、そのURLがインデックスから削除されるリスクがあります。「may」「eventually」であり保証ではなく、長期の503と似ています。
• 回復は方向性であり即時ではない。 429の送信を止めると、Googleはクロールレートが「starts increasing again」 (翻訳)「再び増加し始める」と述べています。再リクエストや残るペナルティはありませんが、固定のタイムラインで即時または完全に復元する保証もありません。
• クライアント側の再試行： 有効なRetry-Afterがあれば従い、ない場合はRFCが数式を定めていないため、上限付きのジッター付きバックオフを使い、試行回数を制限し、非冪等リクエストを繰り返す前に冪等性を確認します。
• 制限を正しいトラフィックに適用し、ボットを除外する前にリバースDNS＋フォワードDNSでクローラーの身元を確認します。
• Bingも429で同様に速度を落とすと広く報告されていますが、今回の調査では現行Bing文書で独自確認できませんでした。Bingの過去のガイダンスでは、crawl-delayとCrawl Controlグリッドが先回りの代替策として確認できます。
• 429はブロックではない。 「後で」であり「決して」ではありません。ボットを排除するにはrobots.txt、ページをインデックスから外すにはnoindexを使います。

公式ドキュメント

検索エンジンとHTTP仕様による一次資料です。

Google

• クロールレート制限に403や404を使わない — Gary Illyesによる2023年2月の記事。429が例外で、403／404が誤ったツールだという決定的な説明です。
• Googleのクロールレートを下げる — 500、503、429を返す指針、1〜2日の目安、ホスト名全体の抑制、自動回復です。
• HTTPステータスコード、ネットワーク、DNSエラー — Googleが各コードを扱う方法です。429はサーバーエラーに分類されます（旧いsearch/docs/crawling-indexing/http-network-errorsパスでも提供）。
• Googleのクロールレートを下げる — 特別なリクエスト経路 — エラー配信が難しい場合に「異常に高いクロールレートの問題を報告する」手動経路です。

Bing／Microsoft

• Crawl Control — Bing Webmaster ToolsでBingbotの1秒あたりのリクエストをスケジュールする機能です。
• Bingbotガイダンス — crawl-delay（1〜20秒）に関する現行のBing Webmasterガイダンスです。

HTTP仕様

• MDN — リクエスト過多 — プロトコルの定義、Retry-After、レート制限の基本です。

原文からの引用

Google、Bing、HTTP仕様に基づく記録に残る発言です。各リンクは、引用箇所へ直接移動するディープリンクです。

Google — Gary Illyes「クロールレート制限にアクセス拒否や未検出応答を使わない」（2023年2月）

• “Over the last few months we noticed an uptick in website owners and some content delivery networks (CDNs) attempting to use 404 and other 4xx client errors (but not 429) to attempt to reduce Googlebot’s crawl rate. 引用箇所へ移動” (翻訳)「ここ数か月、ウェブサイト所有者や一部のコンテンツ配信ネットワーク（CDN）が、Googlebotのクロールレートを下げるために404やその他の4xxクライアントエラー（429を除く）を使おうとする例が増えていることに気付きました。」
• “The one exception is 429, which stands for ‘too many requests’. This error is a clear signal to any well-behaved robot, including our beloved Googlebot, that it needs to slow down because it’s overloading the server.” (翻訳)「唯一の例外は429で、too many requestsを意味します。このエラーは、愛すべきGooglebotを含む適切に動作するロボットに、サーバーに過負荷をかけているため速度を落とす必要があるという明確な信号です。」 引用箇所へ移動
• “All 4xx HTTP status codes (again, except 429) will cause your content to be removed from Google Search. 引用箇所へ移動” (翻訳)「429を除くすべての4xx HTTPステータスコードは、コンテンツをGoogle検索から削除させます。」
• “Use Search Console to temporarily reduce crawl rate. Return a 500, 503, or 429 HTTP status code to Googlebot when it’s crawling too fast.” (翻訳)「Search Consoleを使って一時的にクロールレートを下げてください。Googlebotのクロールが速すぎるときは、500、503、429 HTTPステータスコードを返します。」 引用箇所へ移動

Google — クロールレート低下／ステータスコードのリファレンス

• “If you need to urgently reduce the crawl rate for short period of time (for example, a couple of hours, or 1-2 days), then return 500, 503, or 429 HTTP response status code instead of 200 to the crawl requests. 引用箇所へ移動” (翻訳)「短期間（たとえば数時間、または1〜2日）にクロールレートを緊急に下げる必要があるなら、クロールリクエストには200ではなく500、503、429 HTTPレスポンスステータスコードを返してください。」
• “The reduced crawl rate affects the whole hostname of your site… Once the number of these errors is reduced, the crawl rate will automatically start increasing again.” (翻訳)「低下したクロールレートはサイトのホスト名全体に影響します。これらのエラーの数が減ると、クロールレートは自動的に再び増加し始めます。」 引用箇所へ移動
• “We don’t recommend that you do this for a long period of time (meaning, longer than 1-2 days)… the URL may be dropped from Google’s index.” (翻訳)「これを長期間（つまり1〜2日を超えて）行うことは推奨しません。URLがGoogleのインデックスから外れる可能性があります。」 引用箇所へ移動
• “Google’s crawlers treat the 429 status code as a signal that the server is overloaded, and it’s considered a server error.” (翻訳)「Googleのクローラーは429ステータスコードをサーバー過負荷の信号として扱い、サーバーエラーとみなします。」 引用箇所へ移動
• “Don’t use 401 and 403 status codes for limiting the crawl rate. The 4xx status codes, except 429, have no effect on crawl rate.” (翻訳)「クロールレートの制限に401や403のステータスコードを使わないでください。429を除く4xxステータスコードはクロールレートに影響しません。」 引用箇所へ移動

MDN — プロトコルの定義

• “The HTTP 429 Too Many Requests client error response status code indicates the client has sent too many requests in a given amount of time. This mechanism of asking the client to slow down the rate of requests is commonly called ‘rate limiting.’” (翻訳)「HTTP 429 Too Many Requestsクライアントエラーレスポンスステータスコードは、クライアントが一定時間内にリクエストを送りすぎたことを示します。クライアントにリクエスト速度を下げるよう求める仕組みは、一般に『レート制限』と呼ばれます。」 引用箇所へ移動

Bing — 現在のWebmasterガイダンス

• Bingbotガイダンス はcrawl-delayの値を1〜20秒として文書化しています。一般的なクローラーの制御ではなく、Bing固有のガイダンスとして扱ってください。

Googleの発言に対する業界の裏付け

• 2023年2月のIllyesの記事は、検索エンジン・ランド、検索エンジン・ラウンドテーブル、検索エンジン・ジャーナル で逐語的に報じられています。いずれも429を「唯一の例外」と位置付けています。 Googleの記事を扱った業界紙の報道です。一次資料は上で引用したIllyesのブログ記事です。

適切な429を送る — Retry-After付きで

適切に動作する429の最も重要な要素はRetry-Afterヘッダーです。これはGooglebotを含む準拠クライアントに、どのくらい待つべきかを伝えます。値は秒数またはHTTP日付のいずれかです。

HTTP/1.1 429 Too Many Requests
Retry-After: 3600
Content-Type: text/html

<html><body>Too many requests. Please retry later.</body></html>

HTTP/1.1 429 Too Many Requests
Retry-After: Wed, 01 Jul 2026 12:00:00 GMT

Retry-Afterを省略しても準拠違反にはなりませんが、含めるのがベストプラクティスであり、クローラーに具体的なバックオフ信号を与えます。

nginx — 429を返すレート制限

デフォルトではnginxのlimit_reqは503を返します。クローラーに優しい意味にするには、429へ上書きし、Retry-Afterヘッダーを追加します。この例では、IPごとに毎秒10リクエストを、小さなバースト付きで許可します。

# In the http {} block: define a shared memory zone keyed by client IP
limit_req_zone $binary_remote_addr zone=crawl_limit:10m rate=10r/s;

server {
    location / {
        limit_req zone=crawl_limit burst=20 nodelay;

        # Return 429 (not the default 503) when the limit is exceeded
        limit_req_status 429;
    }

    # Attach a Retry-After header to 429 responses
    error_page 429 = @too_many;
    location @too_many {
        add_header Retry-After 3600 always;
        return 429;
    }
}

Apache — mod_ratelimit／mod_evasiveでレート制限

Apacheのコアmod_ratelimitはリクエスト数ではなく帯域幅を制限するため、リクエストレートの制限には通常mod_evasive（またはWAF）を使います。制限されたレスポンスにRetry-Afterを付けて429を返すには、明示的に設定します。

# Send a 429 with Retry-After for a chosen condition (e.g. a rate-limit env var)
<If "%{ENV:RATE_LIMITED} == '1'">
    Header always set Retry-After "3600"
    Redirect 429 /
</If>

# mod_evasive: throttle abusive request bursts (returns 429 in recent versions;
# older builds default to 403 — override where possible)
<IfModule mod_evasive20.c>
    DOSPageCount        5
    DOSSiteCount        50
    DOSPageInterval     1
    DOSBlockingPeriod   60
</IfModule>

注意点があります。古いmod_evasiveビルドは、デフォルトでブロックレスポンスを403にします。これはGoogleがレート制限に使わないよう述べているコードそのものです。使用中のビルドが429を返すこと（またはそれを行うCDN／WAFを前段に置くこと）を確認してください。

Cloudflare／CDN — レート制限で429を返す

CDN層では、レート制限ルールのアクションレスポンスを429に設定します（デフォルトが403やチャレンジのものも多い）。CloudflareのRate Limitingルールでは、上限超過時のレスポンスステータスを設定できます。429を選び、対応していればRetry-Afterを付けます。Fastly、Akamai、APIゲートウェイでも同じ原則です。上限超過時のアクションは403 Forbiddenではなく429 Too Many Requestsにします。

クライアント側：数式なしで429の後に再試行する

クライアントを書く場合、RFCが定める厳格なルールは1つだけで、フォールバックアルゴリズムはありません。有効なRetry-Afterがあれば、それに従います。ない場合、RFC 6585は再試行間隔、バックオフ数式、ジッター分布、試行回数、「成功」条件を規定していません。これらは仕様の要件ではなく、あなたが設定するポリシーです。下記を含め、どの数式もHTTPの法律のように扱わないでください。妥当な上限付きデフォルトではありますが、唯一の正解ではありません。

on 429 response:
    if Retry-After header present and valid:
        wait = parse(Retry-After)          # seconds or HTTP-date
    else:
        wait = min(cap, base * 2^attempt) + random_jitter(0, jitter_window)

    if attempt >= max_attempts or wait > cap:
        stop and surface the failure        # don't retry forever
    if request is not idempotent (e.g. a POST that isn't safe to repeat):
        confirm idempotency (idempotency key, or a safe no-op check) before retrying
    sleep(wait)
    attempt += 1
    retry request

選んだ具体的な数値にかかわらず重要なのは、総待機時間と試行回数の上限（永遠に再試行しない）、ジッター（クライアント群が同時に再試行して再び制限を発動させない）、そして安全に繰り返せないリクエストを再試行する前の冪等性チェックです。冪等でないPOSTには、無条件の再試行ではなく重複排除キーが必要です。

除外する前に、本当にGooglebotか確認する

検索エンジン向けのレート制限例外を書く場合は、リバースDNS + フォワードDNSで身元を確認してください。偽装された「Googlebot」ユーザーエージェントは一般的であり、UA文字列だけでは何も証明できません。

macOS / Linux

# 1) Reverse DNS the IP from your logs — it should end in googlebot.com or google.com
host 66.249.66.1
# → ... domain name pointer crawl-66-249-66-1.googlebot.com

# 2) Forward DNS that hostname back — it must resolve to the same IP
host crawl-66-249-66-1.googlebot.com
# → crawl-66-249-66-1.googlebot.com has address 66.249.66.1

Windows

nslookup 66.249.66.1
nslookup crawl-66-249-66-1.googlebot.com

リバース検索がGoogleドメインで終わらない場合、またはフォワード検索が元のIPと一致しない場合、それはGooglebotではありません。Googleが公開しているIP範囲（googlebot.json）と照合することもできます。

429とSEOに関するよくある神話

神話：「どんな429でもSEOを損ない、インデックスから外れる。」 いいえ。Googleは429を安全で想定されるスロットリング信号として設計しました。短期または断続的な429は正常で、自動的に修正されます。インデックス削除のリスクが出るのは、同じURLへの429が複数日にわたり継続する場合だけです。Googleの1〜2日の指針が境目です。

神話：「429と503はSEO上、ほぼ互換である。」 クロールレートの抑制については、Googleは両者を同様に扱います。しかし、意味は異なります。503 Service Unavailableは従来の「一時的に停止／メンテナンス中」という信号で、429はレート／量の過負荷を明確に伝えます。Googlebotがどちらでも速度を落とすとしても、自分の監視、ツール、ステータスコードを読む下流の処理のため、意味的に正しいものを使うことが重要です。

神話：「429と同じように、403や404でGooglebotを遅くできる。」 Illyesの2023年2月の記事が直接否定しています。これは十分に一般的だったため、Googleが停止を求める専用記事を書いたほどです。403／404はクロールレートに影響せず、コンテンツをインデックスから積極的に削除します。スロットルする4xxコードは429だけです。

神話：「検索ボットをレート制限すると、クロールバジェットが恒久的に減る。」 減少は一時的で、エラー量が収まると自動回復します。エラーが止まった後にサイトに残るフラグはありません。Googleの文書はクロールレートが*「will automatically start increasing again.」* (翻訳)「自動的に再び増加し始める」と述べています。

神話：「Googlebotが429を受けると、そのURLを永久に諦める。」 Googleは後で再試行します。問題になるのは、URLごとに複数日にわたって429が続く場合であり、Googlebotが尊重して回復する単発または時々のレート制限ではありません。

よくある質問

429エラーはSEOを損ないますか？ それだけでは損ないません。短期または断続的な429はGooglebotを一時的に遅くし、自動的に回復します。リスクが出るのは、同じURLが複数日にわたり429を返す場合だけです。

Googleがページをインデックスから外す前に、どのくらい429を返せますか？ Googleの文書は「a couple of hours, or 1–2 days.」 (翻訳)「数時間、または1〜2日」に制限するよう述べています。それを超えると「the URL may be dropped from Google’s index.」 (翻訳)「URLがGoogleのインデックスから外れる可能性」があります。1〜2日を目標ではなく、厳しい上限として扱ってください。

SEOにおける429と503の違いは何ですか？ Googleはどちらでも同様にクロールを抑制します。しかし、503は「一時的に利用不可／メンテナンス」を意味し、429は「リクエストを送りすぎている」という意味です。自分の監視やツールが正しく解釈できるよう、意味に合うコードを使います。

Googlebotを恒久的にクロールさせたくない場合、429でブロックすべきですか？ いいえ。429は短期的な信号であり、恒久的な設定ではありません。長期的に減らすなら、高いクロールレートについて特別なリクエストを送るようGoogleは案内しています。空間からボットを完全に排除するにはrobots.txt、ページをインデックスから外すにはnoindexを使います。

BingbotはGooglebotと同じように429を尊重しますか？ Bingbotも429／500／503のような過負荷信号を受けると速度を落とします。さらにBingには、Googleにない先回り型の制御として、crawl-delay robots.txtディレクティブと、Bing Webmaster Toolsの1秒あたりリクエスト数のCrawl Controlグリッドがあります。

Retry-Afterヘッダーとは何ですか。必要ですか？ Retry-Afterは、再試行する前にどのくらい待つか（秒数またはHTTP日付）をクライアントに伝えます。厳密には必須ではありませんが、ベストプラクティスであり、クローラーに具体的なバックオフ信号を与えます。

レート制限応答の返却を止めると、Googleは通常のクロールを再開しますか？ はい、自動的に再開します。エラー量が減ると、「the crawl rate will automatically start increasing again.」 (翻訳)「クロールレートは自動的に再び増加し始めます」。再リクエストも不要で、恒久的なペナルティもありません。

WAFやCDNツールが誤ってGooglebotに429を返すことはありますか？ 非常によくあります。強すぎるファイアウォールルール、CDN／ホスティングのデフォルト制限、ボット管理ツールがGooglebotやBingbotを悪質なトラフィックと誤分類することがあります。例外を書く前に、リバースDNS＋フォワードDNSでクローラーの身元を確認し、実際の検索エンジンを捕捉している制限を緩めます。

429はクライアントエラーですか、サーバーエラーですか？ HTTP仕様上は技術的に4xxのクライアントエラーです。しかしGoogleはクロールに関して、5xxと同じグループに入る唯一の4xxコードとして、サーバーエラーのように扱います。

Retry-Afterヘッダーなしで429を受けた場合、クライアントはどうすべきですか？ HTTPが定める数式はありません。仕様はポリシーに任せています。妥当な上限付きデフォルトは、ジッター付き指数バックオフ、総待機時間と試行回数の上限（永遠に再試行しないため）、そして2回送っても安全でないリクエストを繰り返す前の冪等性チェックです。実装した疑似コードはScriptsタブを参照してください。

429にどう対応すべきか

よくある429の問題

Googlebotには429が返るが、通常の訪問者には返らない

**症状：**クローラーのレポートは429だが、ブラウザーチェックは200を返す。**考えられる原因：**ボット管理、UAルール、IPベースのレート制限。**修正：**WAFイベントと確認済みクローラーのIPを突き合わせ、担当ルールを狭めるか修正します。ユーザーエージェント文字列だけを許可リストに追加してはいけません。

ホスト名全体のクロールレートが下がる

**症状：**429を返したURL以外でもクロールが遅くなる。**考えられる原因：**Googleが過負荷信号をホスト名全体に適用している。**修正：**意図しない429を止め、安定した成功レスポンスを戻し、クロールレートが自動回復するのを待ちます。

インシデント後も429レスポンスが続く

**症状：**サーバーは健全なのにURLがまだ429を返す。**考えられる原因：**CDNキャッシュ、エッジルール、制限状態がインシデントより長く残っている。**修正：**一時ルールを無効化または期限切れにし、誤ってキャッシュされたレスポンスをパージし、代表的なパスと地域で確認します。

Retry-Afterがない、または使えない

**症状：**クライアントは制限されたことは分かるが、いつ再試行すべきか分からない。**考えられる原因：**汎用セキュリティルールがレスポンスを生成している。**修正：**発行元の層に有効な遅延またはHTTP日付を送らせ、生のヘッダーをテストします。

プロンプト：レート制限ルールを監査する

Review this 429 rate-limit configuration for search-crawler safety. Identify its key,
scope, threshold source, Retry-After behavior, hostname-wide SEO impact, and any
user-agent-only exceptions. Separate deliberate short-term overload protection from
permanent crawl control. Return a minimal safe revision, test matrix, monitoring
signals, and rollback conditions. Do not invent provider syntax.

[PASTE CONFIGURATION AND SANITIZED SAMPLE LOGS]

プロンプト：原因不明のレート制限を診断する

Use these headers, access-log rows, WAF events, and timestamps to determine which
layer generated the 429 and which traffic dimension triggered it. Give competing
hypotheses ranked by evidence, the next exact check for each, and a fix that does not
trust claimed crawler user agents. Do not infer missing logs.

[PASTE EVIDENCE]

レート制限を調査するツール

• 一括HTTPステータスコードチェッカー： 代表的なURLセットをテストし、現在429を返すパスを出力します。
• HTTPヘッダーチェッカー： 制限されたレスポンスのRetry-After、CDNフィンガープリント、リダイレクトの遷移を調べます。
• Googlebot検証ツール： クローラー例外を作る前にIPの証拠を検証します。
• ログファイルアナライザー： アップロードしたログをブラウザー内に保持しながら、ボットとセクション別にステータスコードの無駄を分けます。
• Search Consoleのクロール統計： 429の発生時期を、クロールリクエストやホストのレスポンス動作の変化と比較します。

429の設定を検証する

レスポンス契約テスト

**実行するテスト：**管理された環境で安全に制限を発動し、生のレスポンスを調べます。**期待結果：**有効なRetry-Afterを伴う429で、意図しないリダイレクトや成功ステータスがない。**失敗の解釈：**間違った層またはエラーテンプレートがレスポンスを所有している。**監視期間：**直ちに。**ロールバック条件：**通常のリクエストが制限される、またはテストでサービスが不安定になる。

範囲テスト

**実行するテスト：**意図して制限したクライアント、通常のユーザー、確認済みクローラーのトラフィックを、代表的なURLクラスで実行します。**期待結果：**定義したトラフィックだけが制限を超える。**失敗の解釈：**レート制限キーまたはルール範囲が広すぎる。**監視期間：**管理されたテストとエッジへの伝播中。**ロールバック条件：**無関係なルート、ユーザー、ホストが429を受け取る。

回復テスト

**実行するテスト：**発動条件を停止し、設定した再試行間隔が経過するまで待ってからリクエストを繰り返します。**期待結果：**URLごとの手動回避策なしに、安定した通常レスポンスが戻る。**失敗の解釈：**キャッシュされたレート制限応答または制限状態が残っている。**監視期間：**設定間隔にデプロイ伝播時間を加えた期間。**ロールバック条件：**根本の負荷が消えた後もホスト名が制限される。

キャッシュ保存テスト

**実行するテスト：**制限されたルートの前にキャッシュまたはCDNエッジを置き、429を発動させ、根本条件が解消した後に同じURLを再度要求します。**期待結果：**2回目のリクエストは新鮮な状態で評価され、エッジからキャッシュ済みまたは再生された429が返らない。**失敗の解釈：**中間層が、RFC 6585でキャッシュしてはならないとされるレスポンスを保存している。オリジンではなく、Cache-Controlヘッダーとエッジルールの設定を確認します。**監視期間：**代表的なエッジノード／POP全体で直ちに。**ロールバック条件：**オリジンの回復後にもキャッシュされた429が配信される。

クライアント再試行ポリシーテスト

**実行するテスト：**有効なRetry-Afterヘッダーがある場合とない場合の両方で、クライアントに429を受けさせます。**期待結果：**ヘッダーがあれば指定間隔を待ち、なければ上限付きのジッター付きバックオフを使い、最大試行回数を守り、非冪等リクエストを繰り返す前に冪等性を確認する。**失敗の解釈：**即時または無制限に再試行したり、非冪等リクエストを盲目的に繰り返したりするクライアントは、HTTP準拠の問題ではなく再試行ポリシーが壊れている。**監視期間：**上限付き再試行シーケンス全体。**ロールバック条件：**即時または無制限の再試行によって同じレート制限を再発動させる。

役立つリソース

私の関連記事

• HTTPステータスコードとSEOへの影響 — すべてのステータスコードがSEOに与える影響と、429の位置付けを扱う私の完全ガイドです。
• テクニカルSEO初心者ガイド — クロール制御とステータスコードが全体像のどこにあるかを説明します。
• Robots.txtでランキング上位2ページをブロックした話 — クローラーを遮断すると実際に何が起こるかを調べた私の一次実験です。

私の講演

• How Search Works （SlideShare）— クロール、レンダリング、インデックス登録、ランキングのウォークスルーで、サーバーがクローラーに速度を落とすよう伝える方法も扱います。（通常の免責事項：「This is my understanding of systems… not going to be 100% complete or accurate.」 (翻訳)「これはシステムについての私の理解であり…100%完全または正確ではありません。」）

業界の関連記事

• クロールレート制限に403や404を使わない （Google検索セントラル、Gary Illyes）— 429が例外だという決定的な説明です。
• Googleのクロールレートを下げる （Google）— 1〜2日の目安、ホスト名全体の抑制、自動回復を説明します。
• Googlebotのクロールレート制限に403や404を使わないようGoogleが警告 （検索エンジン・ランド）— Illyesの記事に関する業界報道です。
• Google、Googlebotのクロールレート低下に403や404を使うのをやめるよう要請 （検索エンジン・ラウンドテーブル）— Barry Schwartzが429を「唯一の例外」と位置付けた要約です。
• Google：Googlebotのレート制限に403／404エラーレスポンスを使わない （検索エンジン・ジャーナル）— 同じ指針を扱う3つ目の独立記事です。
• MDN — リクエスト過多 — HTTP仕様の定義とRetry-Afterのリファレンスです。
• Bingbotガイダンス — crawl-delayディレクティブに関する現行Bingガイダンスです。

自分で確認する：429 Too Many Requests

429の動作とGoogleの扱いについての5つの簡単な質問です。それぞれの答えを選んでから、確認しましょう。

変更履歴