GEO Rankings
← ブログ
公開日

Cloudflareが9月15日から混合型AIクローラーをブロック開始：サイトを引用可能に保つ14項目アクセスチェックリスト

Cloudflareは2026年9月15日から、AgentとTrainingのAIクローラーをデフォルトでブロックします。この14項目のチェックリストで、サイトへのアクセスが保たれているか確認しましょう。

結論

Cloudflareは2026年9月15日から、広告収益化されたページでAgentとTrainingのAIクローラーをデフォルトでブロックします。Trainingをブロックすると、Googlebotのような混合型ボットも一律にブロックされます。Otterly.AIの調査では、すでにサイトの73%がAIクローラーに対する技術的な障壁を抱えていることが判明しています。以下の14項目のチェックリストで、あなたのサイトがその一つになっていないか確認しましょう。

2026年9月更新。 このチェックリストは、新しいAI Crawl Controlのデフォルト設定が適用される2026年9月15日時点で、Cloudflareが公開しているポリシーを反映しています。

ほとんどのサイト運営者は、robots.txtの1行がAIクローラーのアクセスを決定すると考えています。しかし、それは違います。CDNはそのファイルより上位で独自のボットルールを適用しており、Cloudflareのルールは、あなたが頼りにしていたクローラーを気づかないうちに遮断しかねない形に変わったばかりです。

2026年9月15日、Cloudflareは従来の単一のAIボットトグルを、Search、Agent、Trainingという3つの名前付きカテゴリーに分割しました。新規顧客、既存アカウント上の新規サイト、そしてすべての無料プランのアカウントは、広告ユニットを含むすべてのページでAgentとTrainingのクローラーをデフォルトでブロックするようになりました。Googlebot、Applebot、Bingbotを含む、複数のカテゴリーにまたがるボットは、設定したルールのうち最も厳しいものを引き継ぎます。そのため、Trainingをブロックすると、許可していたつもりのクローラーまで機能を失うことがあります。

これは仮定の話ではありません。Otterly.AIが100万件を超えるAI引用を分析した結果、サイトの73%がすでに技術的な障壁、robots.txtによるブロック、CDNルール、あるいはJavaScriptレンダリングのギャップを抱えており、ページが引用シェアを競う前の段階でAIクローラーを締め出していることが分かりました。以下の14項目のチェックを行えば、そのリスクを推測ではなく、数分で検証できるものに変えられます。

2026年9月15日に何が変わるのか

Cloudflareは現在、すべてのAIクローラーを、名前だけでなく、サイト上で何を行うかによって分類しています。

  • Search： 後で質問に答えるために、コンテンツをクロールしてインデックスします。
  • Agent： ユーザーがAIアシスタントに依頼したことをきっかけに、リアルタイムでページを取得します。
  • Training： モデルの学習やファインチューニングのためにコンテンツを収集します。

複数の役割を果たすクローラーは、Cloudflareでは混合型クローラーと呼ばれ、自分が属するすべてのカテゴリーのうち、最も厳しいルールを引き継ぎます。サイト内のどこかでTrainingをブロックすると、Googlebotのような混合型ボットは、維持したかったはずのSearchの挙動も含めて、あらゆる場面でブロックされます。

設定項目2026年9月15日より前2026年9月15日以降
広告収益化ページ上のSearchクローラー許可引き続き許可
広告収益化ページ上のAgentクローラーデフォルトで許可デフォルトでブロック
広告収益化ページ上のTrainingクローラー手動でブロックしない限り許可デフォルトでブロック
混合型クローラー（Googlebot、Applebot、Bingbot）Searchとしてのみ扱われるTrainingをブロックすると完全にブロック
自動的に影響を受けるアカウントなし新規顧客、新規サイト、既存の無料プランのアカウント
既存の有料アカウント該当なしオプトインしない限り現行設定を維持

Cloudflareアカウント内のすべてのサイトが9月15日より前から存在し、かつ有料プランを利用している場合、あなたが何もしない限り何も変わりません。しかし、同じアカウントに追加された新規サイトや、無料プランで稼働しているクライアントのサイトは、公開された瞬間に新しいブロックを引き継ぎます。主力ドメインだけでなく、管理しているすべてのプロパティを確認しましょう。

14項目のアクセスチェックリスト

以下の各チェックは、AIクローラーのアクセスが実際にどう壊れるかという主張と、あなたのドメインに対して今すぐ実行できるコマンドをセットにしたものです。yoursite.comの部分は実際のドメインに置き換えてください。特定のボット名が挙がっているチェックでは、あなたのエンジン構成において重要なボットに置き換えましょう。

1. AI Crawl Controlの階層設定を確認する

主張： アカウントのSearch、Agent、Trainingのトグルは、ボットがサーバーに到達する前に結果を決定します。一度も触っていない設定であっても、トラフィックをブロックしている可能性があります。

検証方法： Cloudflareダッシュボードで、すべてのゾーンについてSecurity > Bots > AI Crawl Controlを開き、Search、Agent、Trainingの横にあるステータスを確認します。この設定はアカウント単位ではなくサイト単位なので、管理しているプロパティごとに繰り返し確認してください。

2. 本番環境のrobots.txtを取得してAIボットのルールを確認する

主張： robots.txtは、それに従うことを選んだクローラーしか止められません。それでも、GPTBot、ClaudeBot、PerplexityBot向けのDisallow行は、ほとんどのエンジンが最初に確認する項目です。

検証方法：

curl -s https://yoursite.com/robots.txt | grep -iE "gptbot|claudebot|perplexitybot|google-extended|ccbot|bytespider"

一致した項目があれば、サイト内のどこかでどのTrainingボットが許可されていないかが、そのまま分かります。

3. 各Trainingボットを直接curlでテストする

主張： Trainingクローラー（GPTBot、ClaudeBot、Google-Extended、CCBot、Bytespider）は、リアルタイムの回答ではなく、モデルの学習に使われます。Cloudflareの新しいデフォルト設定がこれらを密かにブロックしているかどうかは、推測せずに確認しましょう。

検証方法：

for ua in GPTBot ClaudeBot Google-Extended CCBot Bytespider; do
  echo "$ua:"; curl -s -A "$ua" -o /dev/null -w "%{http_code}\n" https://yoursite.com/
done

403または429が返ってきた場合、robots.txtの記載内容にかかわらず、そのボットはエッジでブロックされています。

4. 各Agentボットを直接curlでテストする

主張： Agentボット（ChatGPT-User、Perplexity-User、Claude-User）は、ユーザーが今まさにアシスタントへ質問したことをきっかけにページを取得します。この階層を失うと、将来の学習データだけでなく、その場の回答そのものを失います。

検証方法：

for ua in "ChatGPT-User" "Perplexity-User" "Claude-User"; do
  echo "$ua:"; curl -s -A "$ua" -o /dev/null -w "%{http_code}\n" https://yoursite.com/
done

5. 混合型のSearchボットをcurlでテストする

主張： Cloudflareの新しいルールでは、Googlebot、Applebot、BingbotはSearchとTrainingの両方の挙動を併せ持ちます。どこかでTrainingをブロックすると、この3つのボットはあらゆる場面でそのブロックを引き継ぎます。

検証方法：

for ua in Googlebot Applebot Bingbot; do
  echo "$ua:"; curl -s -A "$ua" -o /dev/null -w "%{http_code}\n" https://yoursite.com/
done

ここで403が返ってくることは、このチェックリストの中で最もコストの高い失敗です。AI引用だけでなく、オーガニック検索まで失うことになります。

6. 新しいデフォルト設定を発動させる広告シグナルがページにあるか確認する

主張： AgentとTrainingのブロックは、Cloudflareが広告収益化されていると判定したページでのみ、デフォルトで発動します。広告スクリプトのないページは、以前の、より寛容な挙動を維持します。

検証方法：

curl -s https://yoursite.com/ | grep -iE "adsbygoogle|doubleclick|googlesyndication|ad-slot"

一致した場合、このページは新しいデフォルト設定の対象だと考えて、チェック1の設定がこのページに適用されているか確認してください。

7. 従来のBot Fight Modeが新しい設定を上書きしていないか除外する

主張： Bot Fight ModeとSuper Bot Fight ModeはAI Crawl Controlより前から存在しており、AI専用のトグルが「許可」になっていても、クローラーにチャレンジを課したりブロックしたりすることがあります。

検証方法： Security > Botsで、Bot Fight Modeがオフになっているか、またはAIクローラーのユーザーエージェントが許可リストに含まれているかを確認します。ここには信頼できるcurlテストがありません。チャレンジを課されたボットは、クリーンな403ではなく、JavaScriptチャレンジページを伴う200ステータスを受け取るため、ブロックは目に見える形では現れません。

8. カスタムWAFルールを監査し、意図しないクローラーブロックがないか確認する

主張： スクレイパーを止めるために書かれたファイアウォールルール、「Refererヘッダーのないリクエストをブロックする」や「ASN Xからのトラフィックをブロックする」といったものは、AIクローラーもまとめて捕捉してしまうことがよくあります。AIクローラーはRefererをほとんど送らず、少数のデータセンターASNを経由してアクセスするためです。

検証方法： Security > WAF > Custom rulesで、すべてのルールの一致条件を、チェック3から5で使ったユーザーエージェントと照らし合わせて確認します。ヘッダーの欠如、ASN、国を条件にしているルールは、いずれも改めて見直す価値があります。

9. レート制限がクローラーをほぼゼロまで絞っていないか確認する

主張： 人間のトラフィック向けに調整されたレート制限は、クローラーのリクエストを数分に1回まで制限してしまうことがあります。ダッシュボードには「許可」と表示されたままでも、クローラーからはサイトに到達できない状態になっています。

検証方法：

for i in 1 2 3 4 5; do
  curl -s -A "GPTBot" -o /dev/null -w "%{http_code} " https://yoursite.com/
done; echo

最初のリクエストが200を返し、その後のリクエストが429を返す場合、本当のブロック要因はAI Crawl Controlのトグルではなく、レート制限です。

10. 主要ページがクライアントサイドレンダリングの裏にコンテンツを隠していないか確認する

主張： ほとんどのAIクローラーは生のHTMLを取得するだけで、ブラウザのようにJavaScriptを実行しません。スクリプトが実行された後にしか回答をレンダリングしないページは、ボット設定にかかわらず、クローラーからは見えないままです。

検証方法：

curl -s https://yoursite.com/your-key-page | grep -c "<p"

その件数を、ブラウザでレンダリングされたページで実際に見える数と比較します。大きな差があれば、コンテンツはクライアントサイドで読み込まれており、クローラーには空の外殻しか見えていません。

11. サーバーログをgrepして実際に何が起きたかを確認する

主張： ダッシュボードのトグルは意図を表すものにすぎません。ログは結果を表します。しかも、Cloudflareではないプロキシ層を経由して処理されたボットの結果も含まれます。

検証方法：

grep -E "GPTBot|ClaudeBot|PerplexityBot|Google-Extended|ChatGPT-User|Perplexity-User" access.log | awk '{print $9}' | sort | uniq -c

これは、各ボットが実際に受け取ったステータスコードを集計します。403や429が固まっていれば、設定の見直しでは見落としていたブロックがあると分かります。

12. AIユーザーエージェントに対するManaged ChallengeとCAPTCHAのルールを確認する

主張： Managed Challengeは、人間ならクリックして通過できるページとともに、HTTP 200を返します。しかし、クローラーには通過できません。ブロックとしては一切表示されないため、このリストの中で最も見落としやすい失敗です。

検証方法： Security > WAFで、ファイアウォールのイベントログをチェック3から5のユーザーエージェントで絞り込み、Action列を確認します。AIクローラーに対して「Managed Challenge」や「JS Challenge」が表示されている場合、HTTPステータスは正常に見えても、それは静かなブロックです。

13. llms.txtとrobots.txtを比較し、矛盾がないか確認する

主張： 公開されているllms.txtファイルは、robots.txtが許可しているのと同じページを指しているべきです。robots.txtが許可していないページをllms.txtが挙げていると、AIクローラーは、スキップするよう指示されているのと同じURLへ誘導されてしまいます。

検証方法：

curl -s https://yoursite.com/llms.txt
curl -s https://yoursite.com/robots.txt

両方を並べて読み比べます。llms.txt内のすべてのURLは、robots.txt内に対応するDisallowルールがない状態で解決できるべきです。

14. このチェックリストを定期的なスケジュールに組み込む

主張： Cloudflareのデフォルト設定、ボット名、カテゴリールールは、9月15日以降も変わり続けます。一度実行しただけのチェックは、来月について何も教えてくれません。

検証方法： チェック2から11をスクリプトとして保存し、毎月、あるいはCDN、WAF、ホスティングに変更があるたびに実行しましょう。クローラーアクセス専用のツールを使えば、これを自動的に実行し、ステータスコードが変化した瞬間にアラートを出せます。

これらのチェックを自動化するツール

14項目すべてを一度手作業で行うのは、無理のない範囲です。しかし、管理しているすべてのプロパティで毎月それを行うのは、現実的ではありません。

Profoundは、Agent階層のアクセス状況を引用トラッキングと組み合わせており、チェック4と5に直接対応します。ChatGPT-UserやPerplexity-Userがページに到達できるかどうかだけでなく、そのアクセスが実際の言及につながっているかどうかまで確認できます。

Knowatoaは、robots.txtの解析、ボットごとの到達性テスト、ステータスコード変化時のアラートといった、クローラーアクセスのチェックをパッケージ化されたワークフローとして実行し、手作業のスクリプトなしでチェック2から11の大部分をカバーします。

Otterly.AIは、先ほどの73%という技術的障壁の数値の出典であり、ChatGPT、Perplexity、Google AI Overviewsにわたる引用トラッキングと合わせて、クロール可能性の監査をより広範なGEOモニタリングに組み込んでいます。

クローラーアクセスのモニタリングを、引用トラッキングやコンテンツ実行と一つのサブスクリプションでまとめて済ませたいなら、**Temso**が最も手軽なオールインワンの選択肢です。月額$89から利用でき、どのプランでもプロジェクト数、ユーザー数、レコメンデーション数は無制限です。

GEOプラットフォームを横並びで比較した全体像は/rankings/geo-toolsにあります。レビューするすべてのプラットフォームでクローラーアクセスのシグナルをどのようにテストしているかについては、/methodologyをご覧ください。

FAQ

サイトがAIクローラーをブロックしているかどうかを確認するには、どうすればよいですか？

次の4つのチェックをまとめて実行しましょう。本番環境のrobots.txtを取得してAIボット向けのDisallowルールを確認する、各ボットのユーザーエージェント（GPTBot、ClaudeBot、PerplexityBot、ChatGPT-User、Googlebot）でサイトにcurlを実行してステータスコードを読む、サーバーログをgrepしてそれらのボットが実際に受け取ったコードを調べる、そしてCDNのボット管理設定を見直すことです。ファイアウォールルールやレート制限は、robots.txtが許可しているクローラーもブロックできるためです。

2026年9月15日、CloudflareのAIクローラーポリシーは何が変わったのですか？

Cloudflareは、単一だったAIボットのトグルを、Search、Agent、Trainingという3つのカテゴリーに置き換えました。この日から、新規顧客、新規サイト、そして既存の無料プランのアカウントでは、広告ユニットを含むすべてのページでAgentとTrainingのクローラーがデフォルトでブロックされるようになりました。一方、Searchクローラーは引き続き許可されています。

新しいルールのもとで、Googlebot、Applebot、Bingbotはどうなりますか？

Cloudflareはこれらを、SearchとTrainingの両方の挙動を併せ持つ混合型クローラーとして扱います。サイト内のどこかでTrainingをブロックすると、Search設定には一切手を加えていなくても、この3つのボットは完全にブロックされます。その結果、通常のGoogleインデックスまで失う可能性があります。

robots.txtがきれいであれば、AIクローラーのアクセスは保証されますか？

保証されません。robots.txtは要請であり、強制するレイヤーではありません。しかも、行儀の良いボットしかそれを読みません。CDNのボット管理ルール、WAFのカスタムルール、レート制限、Managed Challenge設定は、いずれもrobots.txtより上位に位置し、そのファイルが明示的に許可しているクローラーであってもブロックできます。

意図せずAIクローラーをすでにブロックしているサイトは、どれくらいありますか？

Otterly.AIが100万件を超えるAI引用を分析した結果によると、サイトの73%が、AIクローラーがコンテンツに到達するのを妨げる技術的な障壁（robots.txtによるブロック、CDNルール、またはJavaScriptレンダリングのギャップ）を抱えています。

AIクローラーのアクセスを継続的に検証するには、どのツールが役立ちますか？

Knowatoaはボットごとの到達性テストを実行し、ステータスコードが変化するとアラートを出します。Profoundは、Agent階層のアクセス状況を引用トラッキングと組み合わせるため、到達可能なページが実際の言及につながっているかどうかを確認できます。Otterly.AIのGEO Auditは、ChatGPT、Perplexity、Google AI Overviewsにわたる独自の引用モニタリングと合わせて、クロール可能性をチェックします。