Google は 2026 年 10 月 6 日、「Google のクロール頻度を下げる」ドキュメントを改訂しました。更新履歴によれば、緊急時のクロール頻度削減のセクションを再構成し、Retry-After ヘッダーの説明と例をこのガイドに直接加えたものです。更新履歴は、Retry-After のサポート自体は新しいものではないとも明記しています。以前から「ウェブサイトを一時停止または無効にする」のページに記載されており、今回は見つけやすい場所に移しただけです。小さなマシンでサイトを運営している人にとっては、ブックマークしておく価値のある公式の「ブレーキ」の説明です。

ブレーキを踏む前に原因を探す

ドキュメントによれば、Google に寄せられた報告から見て、クロールが急増する原因として最も多いのはサイト自身の URL 構成です。ファセットナビゲーションなどの並べ替え・絞り込み機能、特定の日付ごとに大量の URL を生むカレンダー、動的検索広告のターゲットです。Google は、まずホスティング会社に確認し、サーバーの最近のアクセスログを見て、トラフィックがこれらに当てはまるかを調べるよう勧めています。ログの見方は VPS の CPU 使用率 100% の調べ方が参考になります。実際には AI クローラーやクローラーを装ったボットが来ているなら、それは別の問題で、AI クローラーがサーバーの帯域を食いつぶしているで取り上げています。

緊急ブレーキ：500、503、429 を返す

  • 方法：短い期間（ドキュメントの例では数時間、または 1〜2 日）、Google のクロールリクエストに 200 ではなく 500、503、429 を返します。
  • 効果：Google のクローラーがこれらのステータスコードを大量に受け取ると、ホスト名全体（例：subdomain.example.com）でクロール頻度を下げます。エラーを返す URL だけでなく、正常にコンテンツを返す URL も含まれます。エラーが減れば自動的に元に戻ります。
  • Retry-After：503 または 429 を返すときは Retry-After ヘッダーを付けて、秒数（例：Retry-After: 120）か UTC の絶対日時で、いつ再訪してよいかをクローラーに伝えられます。

代償もはっきり書かれている

  • 検索では、ブレーキをかけている間、Googlebot が見つける新しいページが減り、既存ページの更新頻度も下がり（たとえば価格や在庫の変化が反映されるまでに時間がかかる）、削除したページがインデックスに長く残ることがあります。Google 広告では、キャンペーンが取り消されたり一時停止されたりし、広告が配信されなくなる可能性があります。
  • 1〜2 日を超えて続けないこと。Googlebot が同じ URL で数日にわたってこれらのステータスコードを見ると、その URL がインデックスから削除されることがあります。
  • クローラーにエラーを返すのが難しい場合は、クロール頻度が異常に高いことを特別なリクエストで報告できますが、頻度を上げる申請はできず、審査には数日かかることがあります。

VPS での実践

503 を返す処理は Web サーバーかアプリケーションの層に置き、対象はクローラーだけ、期間は緊急時だけに限り、終わったら必ず外してください。User-Agent は偽装できるため、Google のドキュメントでは逆引き DNS や公開されている IP アドレスとの照合で Google のクローラーを確認する方法が説明されています。負荷によってすでに 502 / 504 エラーが出ているなら、まず 502 / 504 のトラブルシューティングガイドでサービスを復旧させてください。長い目で見て、通常のクロールにもマシンが耐えられないなら、用途に合わせて VPS の構成を見直すか、静的ファイルを CDN に任せる時期です。