Google、クロール速度低減ドキュメントにRetry-Afterの詳細を追記
GoogleクロールRetry-AfterテクニカルSEOSEO
Googleが検索ドキュメントを更新し、「Googleのクロール速度を下げる」ページに Retry-After HTTPヘッダーの詳細とサンプルコードを追加した。緊急時のクロール速度低減セクションも再構成されている。挙動自体の変更はなく、503／429レスポンスに添える再試行指示が明文化された形だ。
何が発表されたか
- Googleのクロール関連ドキュメント更新履歴に「Retry-After HTTPヘッダーの詳細をクロール速度低減ドキュメントに追加」と記載された。
- Retry-After は、503（Service Unavailable）または429（Too Many Requests）を返すときに添えるヘッダーで、Googleのクローラーに再試行タイミングを伝える。値は秒数または絶対UTC日時で指定でき、サンプルコードも追加された。
- 緊急時のクロール速度低減セクションが再構成された。その他の変更は主にページ内の構成整理。
- Retry-Afterのサポート自体は新規ではなく、従来は「サイトを一時的に停止または無効にする」ページに記載されていた。今回クロール速度ガイド側でも直接扱われるようになった。
- 500／503／429をクロール低減シグナルとして扱う挙動は従来どおりで、Retry-Afterは503・429に対する明示的な追加シグナルという位置づけ。
実務への影響
小規模サイトの保守では見落としやすいが、メンテナンス時やアクセス集中時のHTTPレスポンス設計に直結する話だ。
WordPressのメンテナンスモードやサーバー移転時に、素の503を返すだけで済ませているケースは多い。ここに Retry-After: 3600 のように再試行時間を添えておけば、Googleのクローラーが無駄に叩き続けるのを抑えつつ、復旧後に早く戻ってきてもらえる期待値が立つ。逆に長期の停止で絶対日時を返すなら、実際の復旧予定とズレないよう運用ルールを決めておきたい。
注意点として、503や429を「クロールを減らす手段」として常用するのは危険だ。Googleは長期間続く5xxをインデックス削除のシグナルとして扱うため、恒久的なクロール制御はrobots.txtやサーバー側のレート制御で行い、Retry-Afterは一時的な局面に限定するのが筋である。
補足
ドキュメント本体は「Reduce the Google crawl rate」、変更履歴はGoogleのクロール関連changelogに掲載されている。