Cloudflareの「AI Training ブロック」設定でGooglebotも巻き添えに

Cloudflareの「AIボットブロック」設定でGooglebotも巻き添えに——9月15日デフォルト変更前に確認を

要点: Cloudflareの「AI Crawlers & Scrapers」機能で「AI Training = Block」を有効にすると、GooglebotとBingbotの両方がサイトマップ取得時にHTTP 403エラーを受け取り、検索インデックスから漏れる可能性があることがSearch Engine Journalの報道で判明した。原因はCloudflareがGooglebot/Bingbotを「Search + Training」の混合目的クローラーとして扱っており、Trainingブロック設定下では最も制限の強いルールが適用されるため。2026年9月15日のデフォルト変更まで残りわずかな中、Cloudflare利用サイトは今すぐ設定確認が必要だ。

最終更新日: 2026年08月10日

何が起きたのか

Cloudflareは2026年7月1日、AIトラフィックを「Search（検索）」「Agent（エージェント）」「Training（学習）」の3分類で個別に許可/ブロックできる新機能を全プラン（Free〜Enterprise）で提供開始した。従来の「AIボットを一括ブロックするか否か」という単純なトグルから、目的別のきめ細かい制御へと進化させたこの機能変更の詳細は、当メディアの前回の速報記事で報じた通りだ。

その3分類機能をめぐって、2026年8月4日、Search Engine Journal（SEJ News）が「Report That Cloudflare AI Bot Blocking Prevents Googlebot From Indexing Websites」と題する記事を公開し、新たな問題を報じた。

Redditでの発見からJohn Muellerの確認まで

発端は、あるRedditユーザーの報告だった。Cloudflareの「AI Crawlers & Scrapers」機能で「AI Training = Block（AI学習目的のクローラーをブロック）」を有効にしたところ、GooglebotとBingbotの両方が、サイトマップを取得しようとした際にHTTP 403エラー（アクセス拒否）を受け取っていることが発見された。これは単発の不具合報告にとどまらず、Cloudflareコミュニティフォーラムでも「Verified Googlebot intermittently blocked by 'Block AI Training' crawl displays allow」といったスレッドで、複数の類似報告が上がっている状態だ。

この事象について、Googleの検索アドボケイトであるJohn Muellerが確認したことも、SEJの報道で伝えられている。GoogleのSearch Relations担当者本人がこの問題の存在を認めたという事実は、単なる個別サイトの設定ミスでは片付けられない、Cloudflare側の分類ロジックに起因する構造的な問題であることを示唆している。

根本原因——「混合目的クローラー」という分類

なぜ検索エンジンの正規クローラーであるGooglebot・Bingbotが、AI学習ブロックの対象になってしまうのか。その根本原因は、Cloudflareのボット分類の仕組みにある。

CloudflareはGooglebotとBingbotを、Google・Bingが検索インデックスとAIモデル学習の両方の目的でクロールデータを使っているとみなし、「Search + Training」の混合目的クローラーとして分類している。つまりCloudflareの目には、GooglebotもBingbotも「純粋な検索クローラー」ではなく、「検索にも学習にも使われるクローラー」として映っているということだ。

問題はここからだ。混合目的クローラーは、サイト運営者がAI Trainingブロックを有効にする設定にしていた場合、Search/Agent/Trainingのどの粒度設定を選んでいても、最も制限の強いルール（＝ブロック）が適用される仕組みになっている。言い換えれば、「Searchは許可、Trainingはブロック」という一見バランスの取れた設定をしていても、GooglebotがSearchとTrainingの両方に分類されている以上、Trainingのブロックが優先され、結果としてGooglebot自体が丸ごと遮断されてしまう。運営者としては「検索は通す、学習だけ止める」つもりの設定が、意図に反して「検索エンジンそのものを止める」結果を招いてしまうのだ。

9月15日のデフォルト変更でリスクはさらに拡大する

この問題が深刻なのは、Cloudflareが2026年9月15日以降に予定しているデフォルト設定の変更と時期が重なるからだ。9月15日以降、新規にオンボードするドメイン・既存アカウントの新規サイト・設定を変更していないFreeプランアカウントでは、デフォルト設定が変更される。広告収益化ページでは、「Training」「Agent」に分類されたボットは既定でブロック、「Search」は許可のままになる。

一見すると「Searchは許可のまま」という説明は安心材料に見える。しかし、上記の「混合目的クローラーは最も制限の強いルールに従う」という仕様がある以上、Googlebot・Applebot・Bingbotなどの混合目的クローラーは、AI Trainingブロックを選択している顧客の設定下では等しくブロックされる。つまり9月15日以降、何もしなければ新規サイトの多くが、自覚のないまま検索クローラーをブロックする状態に陥りかねない。今回の記事執筆時点（2026年8月10日）で、9月15日のデフォルト変更まで残り約5週間という状況だ。

なお、この事象がCloudflare側の想定通りの仕様なのか、それとも見直されるべき設計上の欠陥なのかは、記事執筆時点でも確定していない。Cloudflareコミュニティフォーラムでの報告が続いていることからも、業界側の注視が続いている段階にある。

aiseo-llmo.com ユーザーへの影響

この問題が重大なのは、「AIクローラーからコンテンツを守りたい」という、運営者にとって本来まったく正当な意図が、意図せず検索順位・インデックスを失う"自傷行為"に転化してしまう構造にあるからだ。Playwireは自社ブログで「Protecting your content from AI scraping is legitimate. Accidentally deindexing your site is not（AIスクレイピングからコンテンツを守るのは正当な行為だが、誤ってサイトをデインデックスしてしまうのは正当ではない）」と指摘しており、パブリッシャーが「AIスクレイピング対策」と「検索可視性の維持」という、本来両立できるはずの2つの目的の板挟みに置かれている構造的な問題であると批判している。

LLMO（大規模言語モデル最適化）やAI検索対策に取り組む事業者にとって、この問題は二重の意味で深刻だ。第一に、AI検索（ChatGPT SearchやPerplexity、Google AI Overviewなど）での引用・露出を狙う戦略の前提として、そもそも従来の検索エンジンにインデックスされていることが土台になる。Googlebotがブロックされてサイトマップの取得すら失敗すれば、通常のGoogle検索結果からの露出はもちろん、AI Overviewのような検索統合型のAI回答面への表示機会も同時に失われかねない。第二に、Training設定を「無断学習からコンテンツを守るため」に有効化していたサイトほど、この巻き添えブロックの対象になりやすいという皮肉な構図がある。つまり、LLMO・GEOへの意識が高く、AIとの向き合い方を能動的に設計しようとしていた事業者ほど、リスクにさらされやすい。

業種別の影響差

メディア・パブリッシャーは、最も直接的な打撃を受けやすい業種だ。広告収益化ページを持つメディアサイトは、9月15日以降のデフォルトでTraining・Agentが既定ブロックの対象になる。もともとAIによる無断学習からコンテンツを守る目的でTrainingブロックを能動的に設定していたメディアほど、Googlebotの巻き添えブロックに気づかず、じわじわと検索トラフィック・広告収益を失っていくリスクが高い。デインデックスは通知が来るものではなく、GSCのクリック数やインプレッションの減少という形で後から気づくケースが多いため、発見が遅れやすい点も厄介だ。

ECサイトでは、商品ページが検索結果から漏れることが売上に直結する。商品データ・価格情報の無断学習を防ぎたいという意図でTrainingブロックを設定しているEC事業者は少なくないはずだが、同じ設定がGooglebotのクロールを阻害していれば、新商品や在庫更新がインデックスに反映されず、機会損失が拡大し続ける。特に季節商材やセール情報など、鮮度が重要なページほど影響が大きい。

BtoBサイト・SaaSは、ホワイトペーパーや導入事例、技術ドキュメントといった専門性の高いコンテンツで指名検索やオーガニック流入を獲得している場合が多い。こうしたコンテンツはリード獲得の入口になっているため、Googlebotのブロックによって新規ページのインデックスが止まれば、リード獲得の機会そのものが静かに目減りしていく。BtoBは検索順位の変動に気づくまでのタイムラグが長い傾向があり、影響発覚がさらに遅れるリスクがある。

いずれの業種にも共通するのは、「意図した防御設定」と「意図しない検索遮断」が同じスイッチの裏表になっているという点だ。これは通常のSEO運用チームだけでなく、Cloudflareの設定を管理するインフラ・情シス部門との連携が不可欠な問題であることを示している。

今すぐできる対応策

Playwireのブログ記事で示されている確認・修正手順を踏まえ、aiseo-llmo.comの読者が今すぐ取れる具体的なアクションを整理する。

ステップ1: Cloudflareダッシュボードでブロック状態を確認する

まず、自社サイトがCloudflareを利用しているか、利用している場合は「AI Crawlers & Scrapers」機能を有効化しているかを確認する。

1. Cloudflareダッシュボードにログインし、対象ドメイン（ゾーン）を選択する
2. 「AI Crawlers & Scrapers」セクションに移動する
3. Googlebot・Bingbotの現在のブロック状態を確認する
4. 「AI Training」の設定が「Block」になっている場合、Googlebot・Bingbotが混合目的クローラーとして巻き添えブロックされていないかを重点的にチェックする

ステップ2: Google Search Consoleの「URL検査ツール」で403応答を確認する

Cloudflare側の設定確認と並行して、実際にGooglebotがブロックされているかを検索エンジン側からも検証する。

1. Google Search Console（GSC）を開き、対象プロパティを選択する
2. 「URL検査ツール」で、サイトマップURL（例: https://example.com/sitemap.xml）や代表的なページURLを入力する
3. 「公開URLをテスト」を実行し、レスポンスが403（アクセス拒否）になっていないか確認する
4. 403が返っている場合、GSCの「ページ」レポートでも「クロール済み - インデックス未登録」や「送信されたURLがrobots.txtによりブロックされました」といったステータスが増えていないかをあわせて確認する

ステップ3: 他のボット対策設定との併用も確認する

Playwireの指摘によれば、「Bot Fight Mode」など、AI Crawlers & Scrapers以外のボット対策設定との併用が問題を複合化させる可能性がある。AI Training関連の設定だけでなく、Cloudflareのセキュリティ設定全体を棚卸しし、複数のボット対策機能が重複してGooglebotを遮断していないかを確認したい。

ステップ4: GooglebotのIPレンジでallowlistルールを作成する

最も実効性の高い対応は、Googleが公開しているGooglebotの正規IPレンジ（developers.google.com/search/docs/crawling-indexing/verifying-googlebot）を使って検証し、AI Trainingブロックから検索クローラーを明示的に除外するallowlist（許可リスト）ルールを作成することだ。

Cloudflareのファイアウォールルール（WAFカスタムルール）で、GooglebotのIPレンジからのアクセスを明示的に許可する設定を追加すれば、AI Training系の一括ブロック設定と衝突せずに、検索クロールだけを確実に通すことができる。設定イメージとしては以下のような考え方になる。

# Cloudflare WAFカスタムルールの考え方（擬似記法）
# 条件: 送信元IPがGooglebot公式IPレンジに一致する場合は、
# AI Crawlers & Scrapersのブロックルールより優先して「許可」する

IF (ip.src in $googlebot_verified_ip_range)
  THEN Allow (skip AI Training block)

同様に、BingbotについてもMicrosoftが公開する公式IPレンジを使って同じ考え方でallowlistを設定すれば、Bing側のインデックス漏れも防げる。

ステップ5: robots.txt / llms.txtとの整合性も再点検する

Cloudflareのネットワークレベルの制御とは別に、robots.txtやllms.txtで検索系クローラーを明示的に許可（Allow）していても、Cloudflare側でネットワークレベルの403を返していれば、そもそもクローラーはリクエストに到達できない。robots.txtの記述が正しくても、Cloudflare側の設定が優先されてしまう点に注意し、両者の整合性を再確認しておきたい。robots.txtの基本的な書き方については、当メディアのrobots.txt / llmsクローラー設定ガイドも参照してほしい。

ステップ6: 9月15日のデフォルト変更前にオプトアウト設定を確認する

2026年9月15日以降、新規にオンボードするドメイン・既存アカウントの新規サイト・設定未変更のFreeプランアカウントでは、デフォルト設定そのものが変更される。今後Cloudflareへ新しいドメインを追加する予定がある場合、あるいは現時点で明示的な設定変更をしていない場合は、期日前にオプトアウト（意図した設定への上書き）が必要かどうかを判断し、上記のallowlistルールをあらかじめ用意しておくことを強く推奨する。

よくある質問

Q1. Cloudflareの「AI Training = Block」設定は、なぜGooglebotまでブロックしてしまうのですか?

CloudflareがGooglebot・Bingbotを「Search + Training」の混合目的クローラーとして分類しており、Trainingブロック時は最も制限の強いルールが適用されるためです。

Googleは検索インデックスとAIモデル学習の両方にクロールデータを活用しているとCloudflareがみなしており、Googlebotを単純な「Searchクローラー」ではなく「Search兼Trainingクローラー」として扱っています。混合目的クローラーは、Search/Agent/Trainingのどの粒度で設定していても、Trainingがブロックされていれば全体がブロック対象になる仕組みのため、意図せずGooglebot自体が遮断される結果になります。

Q2. この問題はいつ、どのように発覚したのですか?

2026年8月4日、Search Engine JournalがRedditユーザーの発見をもとに報道し、GoogleのJohn Muellerが事象を確認しました。

発端はあるRedditユーザーが、Cloudflareの「AI Crawlers & Scrapers」機能でAI Trainingブロックを有効にしたところ、GooglebotとBingbotがサイトマップ取得時に403エラーを受け取ることに気づいたことでした。この報告を受けてSEJが取材・報道し、Googleの検索アドボケイトであるJohn Muellerがこの事象の存在を確認したことも伝えられています。

Q3. 自社サイトが影響を受けているかどうかは、どうやって確認できますか?

Cloudflareダッシュボードの「AI Crawlers & Scrapers」設定と、Google Search Consoleの「URL検査ツール」の両方を確認します。

Cloudflare側ではAI Training設定がBlockになっていないか、GooglebotやBingbotが巻き添えでブロックされていないかを確認します。GSC側では「URL検査ツール」でサイトマップや代表ページを検査し、レスポンスが403になっていないかを確認します。両方をセットで確認することで、設定側と実際のクロール結果の両面から状況を把握できます。

Q4. 影響を受ける条件は何ですか? すべてのCloudflare利用サイトが対象ですか?

Cloudflareを利用し、かつAI Crawlers & Scrapers機能を有効化し、かつAI Trainingブロック設定を適用しているサイトが対象です。すべてのCloudflare利用サイトが自動的に影響を受けるわけではありません。

条件は、(1) Cloudflareを利用している、(2) AI Crawlers & Scrapers機能を有効化している、(3) AI Trainingのブロック設定を適用している、(4) 検索トラフィックに依存している、の4つが重なった場合です。AI Training設定を触っていない、あるいはSearch/Agent/Trainingをすべて許可のままにしているサイトは、この巻き添えブロックの直接対象にはなりません。

Q5. 9月15日のデフォルト変更が来ると、何が変わるのですか?

新規にオンボードするドメインなどで、広告収益化ページのTraining・Agentが既定ブロックになります。Searchは既定で許可のままですが、Googlebotなど混合目的クローラーは巻き添えでブロックされる可能性があります。

「Searchは許可のまま」という説明だけを見ると安心できそうですが、混合目的クローラーの扱いが変わらない限り、Trainingブロックがデフォルトになる9月15日以降、何も設定していない新規サイトの多くが、自覚のないまま検索クローラーを遮断する状態になりかねません。9月15日までに、あらかじめallowlistルールを準備しておくことが重要です。

Q6. GooglebotのIPレンジによるallowlist設定とは、具体的に何をすればよいですか?

Googleが公開する正規Googlebot IPレンジを使い、CloudflareのファイアウォールルールでそのレンジからのアクセスをAI Trainingブロックより優先して許可する設定を作ることです。

Googleはdevelopers.google.com/search/docs/crawling-indexing/verifying-googlebotでGooglebotの正規IPレンジを公開しています。このレンジをCloudflareのWAFカスタムルールの条件に指定し、「このIPレンジからのアクセスはAI Crawlers & Scrapersのブロックルールをスキップして許可する」という優先ルールを追加することで、検索クロールだけを確実に通すことができます。Bingbotについても同様に、Microsoft公式のIPレンジを使って同じ考え方のルールを作成できます。

Q7. robots.txtでGooglebotを明示的に許可していれば、この問題は起きませんか?

いいえ。robots.txtの許可はCloudflareのネットワークレベルの制御より前段で機能しないため、Cloudflare側で403を返していればクローラーはそもそも到達できません。

robots.txtは「宣言」であり、クローラーがサイトにリクエストを送った後に読み取られるファイルです。一方、Cloudflareのネットワークレベルのブロックは、リクエストがサーバーに届く前の段階で拒否します。したがってrobots.txtでいくら「Allow: /」と書いていても、Cloudflare側で403を返している限り、Googlebotはそのrobots.txtの内容自体を読みにいくこともできません。両者は別レイヤーの制御であり、Cloudflare側のallowlist設定が不可欠です。

Q8. この問題は仕様上の欠陥ですか、それとも設定ミスですか?

記事執筆時点（2026年8月10日）では、ユーザーエラーか仕様上の欠陥かは未確定です。Cloudflareコミュニティフォーラムでも複数の類似報告が続いています。

Cloudflare側が意図した分類ロジック（混合目的クローラーは最も制限の強いルールに従う）が、結果として検索エンジンの正規クローラーを巻き添えにしているという構造自体は事実として確認されていますが、これが仕様として維持されるのか、見直しが入るのかは、本記事の時点では明らかになっていません。今後の公式なアナウンスやアップデートを注視する必要があります。

Q9. 「Bot Fight Mode」など他のボット対策機能も影響しますか?

Playwireの指摘によれば、Bot Fight Modeなど他のボット対策設定との併用が問題を複合化させる可能性があります。あわせて確認することが推奨されています。

AI Crawlers & Scrapers機能単体の設定だけでなく、Cloudflareが提供する他のセキュリティ・ボット対策機能が同時に有効化されている場合、複数のルールが重なってGooglebotのブロックを引き起こしている可能性があります。トラブルシューティングの際は、AI Training設定だけでなく、セキュリティ設定全体を棚卸しすることが望ましいです。

Q10. すでにデインデックスされてしまった場合、どう復旧すればよいですか?

まずCloudflare側でallowlistルールを設定してブロックを解除し、GSCの「URL検査ツール」から「インデックス登録をリクエスト」を行うことが基本的な対応になります。

ブロックが解除されれば、Googlebotは再びサイトマップやページを正常にクロールできるようになります。GSCの「URL検査ツール」で個別ページの再インデックスをリクエストし、サイトマップも再送信しておくとよいでしょう。ただし再クロール・再インデックスには一定の時間がかかるため、検索トラフィックの回復には数日〜数週間単位のタイムラグが生じる可能性がある点は踏まえておく必要があります。

関連記事

• Cloudflare、AIクローラーを「Search/Agent/Training」の3分類で個別制御可能に —— 今回の問題の前提となった、7月1日の3分類機能ローンチの詳報。
• Cloudflare、AIクローラー課金を「クロール単位」から「引用単位」へ転換 —— 同じ一連の流れで発表されたPay Per Useと既定ブロックの詳報。
• Cloudflareのrobots.txt / Content Signals Policy設定ガイド —— AIクローラー制御をrobots.txtレベルで宣言する具体的な設定方法。
• Cloudflare Pay Per Crawlの仕組みと2026年の動向 —— クロール課金モデルの基礎知識。
• LLMO完全ガイド —— LLMOの全体像を体系的に学ぶ。
• AI検索最適化ガイド —— AI検索での可視化を高める実践手法。
• Meta、独自AI検索エンジン構築か　クローラー急増で『脱Google』観測情報
• JavaScriptナビゲーションはAI検索から見えない——41日間の実験が実証

用語の詳細は、クローラー、robots.txt、インデックス、noindex、LLMO の各用語解説もあわせて参照してください。