Google のクロール頻度を下げる

Google クローラーのインフラストラクチャでは、高度なアルゴリズムで各サイトに最適なクロール頻度が決定されています。サーバーに大きな負荷をかけることなく、1 回のアクセスでサイト内のページをできるだけ多くクロールすることを目標にしています。場合によっては、Google からのサイトのクロールにより、お客様が使用しているインフラストラクチャに重大な負荷がかかったり、サービス停止中に不要な費用が発生したりすることがあります。これを軽減するために、Google クローラーからのリクエストの数を減らすことができます。

クロールが急激に増加する原因を把握する

クロールが急激に増加する場合は、サイトの構造に非効率な箇所があるなど、サイトに問題がある可能性があります。過去の報告に基づいた、よくある理由は以下のとおりです。

  • URL の非効率な設定（通常は以下のようなサイトの特定の機能に起因）
    • ファセット ナビゲーション、またはその他の並べ替えやフィルタリングのための機能
    • 特定の期間に対して多数の URL があるカレンダー
  • 動的検索広告のターゲット

トラフィックの発生元を把握し、前述のクロール急増のよくある理由が該当するか確かめるために、ホスティング会社に連絡して、最近のサーバーのアクセスログを調べることを強くおすすめします。次に、ファセット ナビゲーション URL のクロール管理と、クロール効率の最適化に関するガイドをご確認ください。

すぐにクローラー トラフィックを減らす（緊急時）

短期間（たとえば、数時間や 1～2 日）の間のクロール頻度を至急下げる必要がある場合は、クロール リクエストに対して、200 の代わりに 500、503、429 のいずれかの HTTP レスポンス ステータス コードを返すようにします。

Google のクローラー インフラストラクチャでは、500、503、または 429 HTTP レスポンス ステータス コードを含む URL が多数検出された場合（ウェブサイトを無効にした場合などが該当）:

  • ホスト名全体（例: subdomain.example.com）でサイトのクロール頻度が低下します。これには、エラーを返す URL とコンテンツを返す URL の両方が含まれます。
  • エラーの数が減ると、クロール頻度は自動的に回復します。

503 または 429 ステータス コードを返すときに、Retry-After HTTP ヘッダー（RFC 9110 HTTP Semantics で定義）を含めて、Google のクローラがリクエストを再試行できるタイミングを、遅延時間（秒単位）または絶対 UTC 日時を使用して示すこともできます。

  • 遅延（秒単位）: 
    HTTP/1.1 503 Service Unavailable
Retry-After: 120
  • 絶対 UTC 日時: 
    HTTP/1.1 503 Service Unavailable
Retry-After: Wed, 21 Oct 2026 07:28:00 GMT

特別なリクエストでクロール頻度を抑える

Google のクローラーにエラーを返すことが難しいインフラストラクチャをお使いの場合は、特別なリクエストを送信することで、クロール頻度が異常に高い問題を報告し、自社のサイトに最適なクロール頻度をリクエストできます。クロール頻度の増加をリクエストすることはできません。また、リクエストが審査され、処理されるまで数日かかることがあります。