AIクローラをCDNで一括ブロックすると検索はどうなるか

robots.txt に書いた拒否は、クローラに守ってもらうことを前提にした取り決めです。 robots.txt の標準である RFC 9309 は、この規則を「not a form of access authorization」（アクセスを許可・拒否する仕組みではない）と書いています。 そこで CDN や WAF のルールで AI クローラの要求そのものを断ろうとすると、今度は止める範囲の誤りが Google 検索に直接響きます。 Google は、robots.txt の取得に 5xx 系のエラーが返ると、最初の 12 時間はサイトのクロールを停止すると説明しています。 CDN のルールが robots.txt への接続を遮断した場合も、Google はこれをサーバーエラーとして扱います。

robots.txtとCDNのブロックは、止まる理由が違う

robots.txt は、クローラが自分でファイルを取りに行き、取得できたら書かれた規則に従う仕組みです。 RFC 9309 は、robots.txt に載せたパスへのアクセスを制御したいなら、robots.txt を配信している層で有効なセキュリティ対策を使うべきだとしています。 HTTP の場合の例として挙がっているのは、HTTP 認証です。

robots.txtで断ったサイトの数に、CDNのブロックは入っていない

Ahrefs の調査（約 1 億 4,000 万サイトの robots.txt を集計）では、最も多く止められていた AI ボットは GPTBot で、全サイトの 5.89% が止めていました。 ただしこの集計は robots.txt だけを見たもので、原文は「this doesn’t include any other block types such as firewalls or IP blocks」（ファイアウォールや IP でのブロックは含まない）と断っています。 CDN やファイアウォールで AI ボットを止めているサイトは、この 5.89% には表れません。

robots.txtの規則が届かない取得がある

Google は、ユーザーの操作をきっかけに取得する「ユーザー トリガー フェッチャー」について、「このようなフェッチャーでは robots.txt ルールは無視されます」と書いています。 OpenAI も、ChatGPT の利用者の操作で動く ChatGPT-User について「robots.txt rules may not apply」（robots.txt の規則が適用されない場合がある）としています。

CDNはボットをユーザー エージェントとIPで見分ける

Google はクローラの一覧のページで、「HTTP ユーザー エージェント文字列はなりすましが可能です」と注意しています。 ユーザー エージェントの名前だけを条件にしたルールは、名前を偽ったアクセスにも同じように当たります。

本物のGooglebotはDNSとIPの一覧で確かめる

Google は、自社のクローラからの要求かを確かめる方法として、コマンドライン ツールでの確認と、公開している IP アドレスの一覧との照合の 2 つを挙げています。 コマンドライン ツールでの確認は、host コマンドを 2 回使う手順です。

1. ログに残った IP アドレスに host コマンドでリバース DNS ルックアップをかける
2. 返ってきたドメイン名が googlebot.com・google.com・googleusercontent.com のいずれかであることを確かめる
3. そのドメイン名に host コマンドでフォワード DNS ルックアップをかける
4. 返ってきた IP アドレスが、ログに残っていた元の IP アドレスと同じかを確かめる

Google が例 1 として載せている結果は次のとおりです。

host 66.249.66.1
1.66.249.66.in-addr.arpa domain name pointer crawl-66-249-66-1.googlebot.com.

host crawl-66-249-66-1.googlebot.com
crawl-66-249-66-1.googlebot.com has address 66.249.66.1

要求が多いサイトで機械的に判定するなら、Google が公開している IP 範囲の一覧と照合します。 Googlebot などの一般的なクローラーの一覧は common-crawlers.json で公開されています。 ただし Google は、「このリストにない IP アドレスを使用して Google がサイトにアクセスする場合があります」とも書いています。 その場合は、アクセスに使われた IP アドレスを通常の Google の IP アドレスの一覧と照合するよう案内しています。

OpenAIも、検索に載せたいならIP範囲からの要求を許可するよう勧めている

OpenAI もボットごとに IP アドレスの一覧を公開していて、OAI-SearchBot は searchbot.json、GPTBot は gptbot.json、ChatGPT-User は chatgpt-user.json です。 そのうえで、ChatGPT の検索結果に載せたいなら、robots.txt で OAI-SearchBot を許可し、公開した IP 範囲からの要求も許可するよう勧めています。

Google-Extendedは名前で止められない

Google の一覧は、Google-Extended について「個別の HTTP リクエスト ユーザー エージェント文字列はありません」と書いています。 クロールは既存の Google のユーザー エージェント文字列で行われ、Google-Extended という名前は robots.txt の中で制御にだけ使われます。 そのため CDN のルールに Google-Extended の名前を書いても、その名前を名乗る要求は来ません。 Gemini の学習とグラウンディングに使わせない指定は robots.txt で行います（書き方はGoogle-Extendedを止めてもAIによる概要からは消えないで扱いました）。

Googlebotやrobots.txtを巻き込むとGoogle検索で起きること

CDN のルールが Googlebot を止めた場合に何が起きるかは、ルールがページと robots.txt のどちらに、何を返したかで分かれます。

ページが4xxを返すと、インデックスから外れる

Google は、4xx 系のステータス コードを返す URL のコンテンツを使いません。 すでにインデックスに登録されている URL が 4xx を返すと、その URL はインデックスから削除されます。 新しく見つかった URL が 4xx を返す場合は、インデックスに登録されません。 Google は 429 を除くすべての 4xx エラーを同じように扱うとしているので、CDN のルールが 403（forbidden）を返した場合もこの扱いになります。 Google は「クロール頻度を制限する目的で 401 および 403 のステータス コードを使用しないでください」とも書いています。 429 を除く 4xx は、クロール頻度に影響しないとされています。

ページが5xxを返すと、時間をおいて削除される

5xx 系と 429 のエラーは、Google のクローラに一時的にクロールのペースを落とさせます。 すでにインデックスに登録されている URL はいったん保持されますが、最終的には削除されます。

robots.txtが5xxを返すと、12時間クロールが止まる

Google は、robots.txt の取得に 5xx 系のエラーが返ると、最初の 12 時間はサイトのクロールを停止し、robots.txt の取得だけを続けます。 新しい版を取得できないまま 30 日間は、前回正常に取得できた版を使いながら取得を試み続けます。 キャッシュに保存された版を利用できない場合は、クロールの制限は無いものとみなします。 30 日を過ぎてもエラーが続くと、サイトが一般公開されているなら robots.txt が無いものとして動作します（新しい版の確認は続けます）。 サイトの一般公開に問題がある場合は、サイトのクロールを止めたまま、robots.txt の取得を定期的に続けます。 反対に、robots.txt に 429 以外の 4xx が返ると、Google は有効な robots.txt が無いものとみなし、クロールの制限は無いと判断します。 RFC 9309 も同じ向きで、robots.txt がサーバーやネットワークのエラーで到達できないときはクローラが「complete disallow」（全面拒否）とみなさなければならないとしています。 4xx 系で取得できないときは、クローラはサーバー上のどのリソースにもアクセスしてよいとしています。

AI検索への露出は、止めるボットで分かれる

OpenAI は、OAI-SearchBot を断ったサイトは ChatGPT の検索の回答に表示されなくなる一方、ナビゲーションのリンクとしては表示されうると書いています。 OpenAI は、OAI-SearchBot と GPTBot の設定は互いに独立していると書いています。 Google 側では、Google-Extended が Google 検索でのサイトの登録に影響したり、ランキング シグナルとして使われたりすることは無いと書かれています。

「AIボット」をまとめて止めると、学習用と検索用が同時に止まる

CDN の一括ブロックが OAI-SearchBot のような検索用のボットまで対象にしているなら、学習を断るつもりで ChatGPT の検索の回答からも外れます。

AIからの流入は小さいが、止めた影響は流入の数字だけでは測れない

Ahrefs は、Ahrefs Analytics を使う約 3.5 万サイトの流入の構成を調べ、AI からの参照流入は全体の 0.1% で、検索よりはるかに少なかったと書いています。 この数字は流入の量を示すもので、ChatGPT の検索の回答に表示されるかどうかを示すものではありません。

CDNでAIクローラを止める前に確かめること

DigitalGOAT編集部の推奨する初期設定の順番では、CDN 側の一括ブロックは最後の手段に置き、Googlebot を巻き込まないかを先に確認します。 DigitalGOAT編集部の推奨では、その前の段で、止めたい対象を学習・AI 機能での引用・検索そのもののどれか 1 つに決め、学習だけを断るなら robots.txt で Google-Extended と GPTBot を止めます（この 2 つを止めても、検索と AI による概要には効きません）。 DigitalGOAT編集部が、CDN のルールを入れる前に確かめる項目として勧めているのは次のとおりです。

• 止めたい対象を 1 つに決めた（学習に使われること／AI の回答に引用されること／検索結果に出ること）
• robots.txt の URL をルールの対象から外し、どのボットにも正常な応答を返している
• Googlebot を名乗る要求を、名前ではなくリバース DNS か common-crawlers.json で確かめている
• ChatGPT の検索に載り続けたいなら、OAI-SearchBot と searchbot.json の IP 範囲を通している
• Google-Extended を CDN のルールに書かず、Gemini の学習とグラウンディングへの利用を断る指定は robots.txt に置いている
• ルールを入れたあと、Search Console の URL 検査で検索用のクロールが止まっていないかを確かめた

まとめ：止める相手を1つに決めてからCDNを触る

robots.txt の規則は、クローラに守ってもらうことを前提にした取り決めで、アクセスを許可・拒否する仕組みではありません。 CDN のブロックは要求そのものを断れる一方、Googlebot や robots.txt への要求を巻き込むと、Google 検索のクロールとインデックスに直接響きます。 ChatGPT の検索での露出を残すなら、OpenAI が勧めるとおり、OAI-SearchBot のような検索用のボットを通しておきます。 止めたい相手を決め、自社の CDN のルールが robots.txt と Googlebot をどう扱っているかを確かめた段階にいるなら、次はそのボットだけに当たるルールを書く番です。