多くの中小企業はrobots.txtファイルを絶対的な基準として扱っている——「GPTBotを許可したから、ChatGPTで表示されるはずだ」という具合だ。しかし2026年7月の調査によれば、この前提はかなりの割合のサイトで成立していない。
HasDataのAI Crawler Block Indexは、宣言されたポリシーではなく実際のクローラー挙動を10,894ドメイン(Trancoトップサイト9,746件+ニュースメディア1,148件)で測定した。主要な発見:robots.txtで宣言されたGPTBotの「Disallow」ルールのうち39.5%が実際には一切適用されていなかった。サイトはブロックを宣言しているが、前段のCDNやファイアウォールがそのポリシーに合わせて設定されていないため、GPTBotはそのままクロールしていた。
逆方向の問題も同様に起きている
robots.txtでAIクローラーを明示的に許可しているサイトも、ネットワークの境界で静かに拒否されることがある。CDNのボット管理ルール、WAFの検証ページ、ホスティング管理画面の包括的な「AIボットをブロック」スイッチは、いずれもrobots.txtが読まれる前に動作する。HasDataによれば、プロバイダーごとに実際の運用は異なる:Fastlyは即座にブロックする傾向があり、Cloudflareは検証ページを表示し、CloudFrontは概ねトラフィックを通過させる——同じ宣言ポリシーでも、インフラによって結果はまったく異なる。
ブロックしても期待通りの効果が得られるとは限らない
調査チームはGoogle AI Modeで10件のテストクエリを実行し、引用された52ドメインを特定した。そのうち27件(51.9%)がrobots.txtで少なくとも1つのAIクローラーをブロックしていた——サンプル全体のブロック率の約3倍だ。robots.txtでブロックを宣言しても、Google AI Modeの引用から確実に除外されるわけではない。
推測ではなく実際に確認する方法
- アクセスログを確認する。GPTBot、ClaudeBot、PerplexityBot、Google-Extendedなど実際のユーザーエージェントと、それぞれが受け取ったHTTPステータスコードを調べる。
- 実際にリクエストを送信してみる。外部サーバーからAIクローラーのユーザーエージェントでリクエストを送り、実際のレスポンスを確認する。
- CDNのボット管理ダッシュボードを直接確認する——Cloudflare AI Crawl Control、Fastlyのボットルール、WAFの管理ルールなど。
- CDN、ホスティング、セキュリティプラグインを変更するたびに再テストする。