Googleは2026年10月6日（UTC）、クローラーのドキュメント「Reduce the Google crawl rate（Google のクロール頻度を下げる）」を英語版で更新しました（出典：Google のクロール インフラストラクチャ「Changelog」英語版）。緊急時にクロールを減らす方法を説明するセクションが再構成され、503 または 429 を返す際に Retry-After HTTPヘッダーを使える旨の説明と記述例が追加されています（出典：Google「Reduce the Google crawl rate」英語版）。
もっとも、Google自身が変更履歴で「Retry-After HTTPヘッダーのサポートは新しいものではない」と説明しているとおり、仕組みそのものは以前から別ページで案内されていたものです（出典：Google のクロール インフラストラクチャ「Changelog」英語版）。Googleの説明によれば、今回の目的は緊急時に情報を見つけやすくすることで、新しいクロール抑制の手段が加わったわけではありません。Search Engine Roundtableも、変更の多くは既存内容の再構成だと伝えています。
本記事では、2026年10月11日時点の公式ドキュメントをもとに、変更点、Retry-After の書き方、503・429 を使うときの注意点を整理します。
更新の概要
| 項目 | 内容 |
|---|---|
| 更新日 | 2026年10月6日（英語版、UTC。ページの最終更新日も2026-10-06 UTC） |
| 対象ページ | Reduce the Google crawl rate（Google のクロール インフラストラクチャのドキュメント） |
| 主な変更 | 緊急時のクロール削減セクションを再構成し、Retry-After ヘッダーの情報と例を追加 |
| 新しい仕組みか | いいえ。以前から「ウェブサイトを一時停止または無効化する」ページに記載あり |
| 日本語版 | 2026年10月11日時点で未反映（最終更新日 2025-12-25 UTC、Retry-After の記載なし） |
（出典：Google のクロール インフラストラクチャ「Changelog」英語版、Google「Reduce the Google crawl rate」英語版、Google「Google のクロール頻度を下げる」日本語版）
変更履歴では、更新の理由を次のように説明しています。
「
Retry-AfterHTTPヘッダーのサポートは新しいものではなく（すでに『Temporarily pause or disable a website（ウェブサイトを一時停止または無効化する）』で説明されていました）、クロール頻度を下げるガイドに直接追加することで、緊急にクローラーのトラフィックを減らす際に見つけやすく、理解しやすくなります」（筆者訳）
（出典：Google のクロール インフラストラクチャ「Changelog」英語版）
なお、このドキュメントは現在、Google検索セントラルではなくクローリング基盤（Crawling infrastructure）側のサイトに置かれています。Google検索セントラルの更新履歴では、2025年11月20日の項目でクローリング関連ドキュメントの移転と、クローリング用の変更履歴への登録が案内されており、2026年10月11日時点で今回の更新は検索セントラル側の更新履歴には掲載されていません（出典：Google検索セントラル「Latest Google Search documentation updates」英語版）。クロール関連の変更を追う場合は、クローリング用の変更履歴も確認対象に加えておくとよいでしょう。
Retry-Afterの書き方
ドキュメントでは、503 または 429 を返すときに、RFC 9110（HTTP Semantics）で定義された Retry-After ヘッダーを含めることで、Googleのクローラーがいつリクエストを再試行できるかを示せると説明しています。値は「秒数による遅延」か「UTCの絶対日時」のどちらかで指定します（出典：Google「Reduce the Google crawl rate」英語版）。
秒数で指定する例（ドキュメント掲載の例と同じ内容）
HTTP/1.1 503 Service Unavailable
Retry-After: 120日時で指定する例（同上）
HTTP/1.1 503 Service Unavailable
Retry-After: Wed, 21 Oct 2026 07:28:00 GMT（出典：Google「Reduce the Google crawl rate」英語版）
日時はHTTPの日付形式（Date ヘッダーと同じ、GMT表記）で書き、秒数はレスポンス受信後に待つ秒数を0以上の整数で表します（出典：MDN Web Docs「Retry-After」）。仕様の原典は RFC 9110「10.2.3. Retry-After」です。
503・429を使うときの注意
ドキュメントが案内する緊急時の方法は、クロールリクエストに 200 の代わりに 500、503、429 のいずれかを返すことです。これによりホスト名全体でクロール頻度が下がり、エラーが減ると自動的にクロール頻度が戻るとされています（出典：Google「Reduce the Google crawl rate」英語版）。
一方で、次の点に注意が必要です。
- 短期間に限る：対象は「数時間や 1～2 日」程度の短期間で、「対象期間が長い（1～2 日では済まない）場合は、この方法はおすすめしません」とされています（出典：Google「Google のクロール頻度を下げる」日本語版）。
- インデックスから外れるおそれ：「Googlebot が同じ URL で上記ステータス コードを数日にわたり検出すると、その URL が Google のインデックスから削除される場合があります」と明記されています（出典：Google「Google のクロール頻度を下げる」日本語版）。
- 影響は検索以外にも及ぶ：クロール頻度を下げると、新しいページの発見や既存ページの更新が遅れ、削除したページがインデックスに長く残る可能性があります。Google広告では、キャンペーンが取り消しまたは一時停止されたり、広告が配信されなくなったりする場合がある、とも注意書きされています（出典：Google「Reduce the Google crawl rate」英語版）。
- robots.txtには503を返さない：サイトの一時停止に関するページでは、「すべてのクロールがブロックされるため、robots.txt ファイルで
503HTTP レスポンス ステータス コードを返さないでください」と案内しています（出典：Google検索セントラル「ウェブサイトを一時停止または無効化する」日本語版）。
使ってはいけない方法
クロール頻度の調整に、429 以外の4xxを使うのは逆効果です。HTTPステータスコードに関するドキュメントでは、「クロール頻度を制限する目的で 401 および 403 のステータス コードを使用しないでください」とし、「4xx ステータス コード（429 を除く）はクロール頻度に影響しません」と説明しています。429 は、サーバーが過負荷であることを示すシグナルとして扱われます（出典：Google「HTTP ステータス コードが Google のクローラーに及ぼす影響」日本語版）。
また、サイトを一時停止するケースについても、403・404・410 を返したり、noindex を使ったりしてサイトをブロックしないよう注意されています（出典：Google検索セントラル「Temporarily pause or disable a website」英語版）。
通常時のクロール抑制
エラーを返す方法が取れない場合は、Search Consoleの「Googlebot」レポートから特別なリクエストを送信し、クロール頻度が異常に高い問題を報告して、サイトに最適なクロール頻度を伝える方法が案内されています。ただし、クロール頻度の増加はリクエストできず、審査と処理には数日かかる場合があります（出典：Google「Reduce the Google crawl rate」英語版）。
なお、かつてSearch Consoleにあった「クロール頻度制限ツール（Crawl Rate Limiter Tool）」については、2023年11月にGoogleがサポート終了予定を告知しています（出典：Google検索セントラル ブログ「Search Console のクロール頻度制限ツールのサポート終了予定」日本語版）。
ドキュメントはまた、クロールの急増にはサイト側の原因がある場合があるとして、ファセットナビゲーションなどの並べ替え・絞り込み機能、多数の日付URLを生むカレンダー、動的検索広告のターゲットを例に挙げ、サーバーのアクセスログの確認やホスティング事業者への相談で原因を特定するよう促しています（出典：Google「Reduce the Google crawl rate」英語版）。クロールの仕組みやクロールバジェットの考え方は、「Googleのクローラーの仕組みとクロールバジェット」で解説しています。
状況別の対応
| 状況 | ドキュメントが示す対応 | 注意点 |
|---|---|---|
| サーバー障害などで数時間〜1〜2日だけクロールを減らしたい | 500・503・429 を返す。503/429 には Retry-After を付けられる | 同じURLで数日続くとインデックスから削除される場合がある |
| 再開の目安時刻が分かっている | Retry-After に日時（GMT）を指定 | 秒数での指定も可 |
| サイト全体を一時的に止めたい | 全コンテンツの代わりに 503 の情報ページを返し、retry-after ヘッダーを使う | Googleは「非推奨」の方法と位置づけ、ごく短期間（長くても数日）に限るとしている。robots.txtに 503 を返さない |
| 継続的にクロール頻度を下げたい | Search ConsoleのGooglebotレポートから特別なリクエスト | 増加の依頼は不可、処理に数日 |
| アクセス制限のつもりで401/403/404を返す | 使わない | 429 以外の4xxはクロール頻度に影響しない |
（出典：Google「Reduce the Google crawl rate」英語版、Google検索セントラル「Temporarily pause or disable a website」英語版、Google「HTTP ステータス コードが Google のクローラーに及ぼす影響」日本語版）
よくある質問（FAQ）
Q. Retry-Afterヘッダーは今回新しく使えるようになったのですか？
A. いいえ。Googleは変更履歴で、サポートは新しいものではなく、以前から「ウェブサイトを一時停止または無効化する」ページで説明されていたとしています。今回はクロール頻度のガイドに説明と例を追加した更新です。
Q. 503を返し続けても問題ありませんか？
A. 推奨されていません。対象は数時間〜1〜2日程度で、同じURLで数日にわたって返し続けると、そのURLがインデックスから削除される場合があります。
Q. 403や404でクロールを減らせますか？
A. 減らせません。429 以外の4xxはクロール頻度に影響せず、401・403 をクロール頻度の制限に使わないよう案内されています。
まとめ
- 2026年10月6日、Googleは「クロール頻度を下げる」ドキュメント（英語版）の緊急時セクションを再構成し、
Retry-Afterの説明と例を追加しました。 Retry-After自体は新しい仕組みではなく、見つけやすさを高めるための整理です。503・429には、秒数またはUTC日時でRetry-Afterを付けられます。- エラーを返すのは数時間〜1〜2日に限り、同じURLで数日続くとインデックスから外れるおそれがあります。
401・403・404などでのクロール抑制は避け、エラーを返せない場合はSearch Consoleからの特別なリクエストを検討しましょう。
なお、本記事の情報は2026年10月11日時点のものです。日本語版ドキュメントは同日時点で今回の更新が反映されていないため、最新の内容は英語版でご確認ください。
参考リンク
- Google「Reduce the Google crawl rate」（英語版）
- Google「Google のクロール頻度を下げる」（日本語版）
- Google のクロール インフラストラクチャ「Changelog」（英語版）
- Google検索セントラル「Temporarily pause or disable a website」（英語版）
- Google検索セントラル「ウェブサイトを一時停止または無効化する」（日本語版）
- Google「How HTTP status codes affect Google’s crawlers」（英語版）
- Google「HTTP ステータス コードが Google のクローラーに及ぼす影響」（日本語版）
- Google検索セントラル「Latest Google Search documentation updates」（英語版）
- Google検索セントラル ブログ「Search Console のクロール頻度制限ツールのサポート終了予定」
- RFC 9110 HTTP Semantics「10.2.3. Retry-After」
- MDN Web Docs「Retry-After」
- Search Engine Roundtable「Google Search Crawl Rate Doc Adds Retry-After HTTP & More」
