crawl-delayは効かない｜Googlebotのクロールを減らす手順

アクセスログが Googlebot（Googleの検索ロボット）で埋まっている。応答が重い。robots.txt に Crawl-delay: 10 を書き足した。それでも減らない。——当然です。Google は crawl-delay という行を、そもそも読んでいません。

Google の robots.txt 仕様は、サポートするフィールドを user-agent / allow / disallow などに限っていて、「crawl-delay のようなそれ以外のフィールドはサポートされない」と明記しています。つまり、その1行は効きません。書いた側だけが「設定した」と思い込む、いちばん厄介な形の無効設定です。

では何をすればいいのか。緊急でクロールを減らす手段は、robots.txt ではなくサーバーの応答コードの側にあります。

対処する前に、2つだけ確かめる

いきなりステータスコードをいじると事故ります。先に切り分けてください。

1つめは、本当に Googlebot かどうか。 Google 自身が「HTTP のユーザーエージェント文字列は偽装できる」と注意書きを出しています。ログに Googlebot/2.1 と並んでいても、それだけでは本物の証拠になりません。名乗りは自己申告です。Googlebot のふりをした収集ツールに負荷をかけられている場合、対処法はまったく別（そちらは遠慮なくブロックしていい）になります。

2つめは、何が大量に叩かれているのか。 ログを URL のパターン単位で集計します。トップページや記事ページが均等に叩かれているのか、それとも ?color=red&size=M&sort=price のような組み合わせURLや、無限に先へ進むカレンダーページが上位を占めているのか。ここで後者だった場合、あとで書く「根本原因」の話に直行してください。ステータスコードの応急処置は要りません。

この2つを飛ばして503を返し始めると、直せるはずの原因を温存したまま、インデックスだけ失う結果になりかねません。

緊急でクロール頻度を下げる5ステップ

サーバーが本当に落ちそうで、数時間から1〜2日をしのぎたい。そのときだけの手順です。

1. 対象URLを絞る。 サイト全体ではなく、負荷の大きいパターン（重い検索結果ページ、絞り込み付き一覧など）に限定します。全ページ一律は後述の理由で危険です。
2. 500・503・429 のいずれかを返す設定を入れる。 Google は「短期間（例: 数時間、または1〜2日）緊急でクロール速度を下げる必要がある場合は、クロールのリクエストに対して200の代わりに500、503、429のHTTPステータスコードを返す」と案内しています。Google のクロール基盤は、これらを検出するとサイトのクロール速度を落とします。
3. robots.txt だけは200で返し続ける。 ここが最大の落とし穴です。理由は次の節で詳しく書きます。
4. 開始時刻を記録し、終了時刻を先に決める。 「様子を見て戻す」にすると必ず戻し忘れます。カレンダーに戻す日時を入れてから設定してください。
5. 1〜2日を超えないうちに200へ戻す。 Google は、これより長い期間にわたって返し続けることを推奨していません。

ステップ2で3つのコードのどれを選ぶかは、意味の正確さで決めます。429 は「リクエストが多すぎる」、503 は「一時的にサービス利用不可」。クローラーに対して伝えたいのは前者に近いので、負荷起因なら429が素直です。

なぜ1〜2日で切る必要があるのか。Google は、これより長い期間（1〜2日を超える意味）返し続けることを推奨しないとしたうえで、「検索の場合、Googlebot が同じURLでこれらのステータスコードを複数日にわたって観測すると、そのURLは Google のインデックスから削除される可能性がある」と書いています。順位が下がるという話ではありません。インデックスから消える可能性の話です。

robots.txt まで503にすると、逆効果になる

サイト全体を503にする設定を入れると、robots.txt も一緒に503になります。ここで何が起きるか。

Google の robots.txt 仕様には、503が返ったときの挙動が段階で書かれています。まず、503（service unavailable）はかなり頻繁な再取得を引き起こします。新しい版を取得できない状態が続く場合、Google は直近の有効な版を今後30日間使い続けます。そして——キャッシュされた版が手元にない場合、Google は「クロールの制限はない」とみなします。

つまり、robots.txt を一度も正常に読ませたことのない新しいサイトや、キャッシュの30日を使い切った状態でサイト全体を503にすると、Disallow が全部無効化された扱いになります。負荷を下げるつもりの設定が、止めていたはずの領域へのクロールを解禁する。これが「robots.txt だけは200で返す」がステップ3に入っている理由です。

使ってはいけないステータスコード

クロールを減らしたい一心で403や404を返す設定を見かけますが、目的を達しません。

Google は「クロール頻度を制限するために401や403のステータスコードを使用しないでください」「429を除く4xxのステータスコードは、クロール頻度に影響しません」と明示しています。表の下3行を選んでも、クロール頻度は動きません。サーバーの応答を書き換える手間だけがかかって、負荷はそのまま残ります。いちばん割に合わない選択です。

上の表を、さきほどの5ステップに当てはめてみます。ステップ2で選ぶのは上3行のどれか。下3行はステップ2の選択肢に入りません。そしてどの行を選んでも、ステップ5の「1〜2日で戻す」からは逃れられません。

たいていの原因は、URLの作られ方にある

ここからは公式の記述ではなく、切り分けの実務の話です。

Googlebot が急に増えるとき、多くはサイト側が「新しいURLを大量に生み出した」瞬間と重なっています。絞り込み検索の組み合わせ、並び替えパラメータ、日付を無限にたどれるカレンダー、セッションIDつきのリンク。人間には数十ページに見えても、クローラーには数万URLに見えていることがあります。

たとえば、こういう追い方をします。ある通販サイトで、色5種・サイズ4種・並び順3種の絞り込みができるとします。カテゴリが40個あれば、組み合わせだけで 5×4×3×40 = 2,400 のURLが機械的に生成されます。実際に売っている商品は数百点。ログを見ると、上位を占めているのは商品ページではなく ?color= を含むURLでした。この場合、応急処置で503を返すのは筋が悪い。パラメータつきURLを Disallow でクロール対象から外すほうが、負荷も落ちて、余計なURLがインデックスに溜まる問題も同時に片づきます。

ただし、Disallow は万能ではありません。クロールを止めても、外部からリンクされているURLは検索結果に出てくることがあります（説明文のない、URLだけの表示になりがちです）。クロールの制御とインデックスの制御は別物、という前提は崩さないでください。この線引きは小規模サイトのクロールバジェットやrobots.txt の allow と disallow の優先順位でも同じ論点になります。

もう一つ。サーバーの応答が遅くなればクロールは自然に落ち着く傾向がありますが、それは「遅いサイト」として扱われた結果でもあります。減らす方向だけでなく、耐えられるようにする方向（キャッシュ、重いクエリの見直し）も同時に検討する価値があります。

AI学習用のクロールを止めても、検索順位には関係ない

負荷の相談でよく混ざるのが、AI向けクローラーの話です。「Google-Extended をブロックしたら検索順位が落ちるのでは」と心配して手を出せない、という状態。

そこは切り離して考えて大丈夫です。Google は「Google-Extended は、サイトの Google 検索への掲載に影響を与えず、ランキングシグナルとしても使用されない」と明記しています。robots.txt では user-agent: Google-Extended として個別に指定できます。検索での見え方を守りながら、AI向けの利用だけを断つ判断ができるということです。

なお、これは負荷対策とは別枠の設定です。Google-Extended は Googlebot とは別のトークンで、robots.txt でもそれぞれ独立して指定します。

設定前の自己点検

手を動かす前に、この6行を上から確認してください。

crawl-delay の1行を消すところから始めるのが、実質的な第一歩です。効かない設定が残っていると、「もう手は打ってある」という誤った前提のまま次の判断をしてしまいます。