AIクローラーのアクセスを監査する方法
GPTBot、OAI-SearchBot、ClaudeBot、PerplexityBotがサイトを取得できるかをテスト。ブロックの原因を特定し、各修正の効果を安全に検証する方法を解説します。
クイックアンサー
AIクローラーのアクセス監査では、robots.txtを確認し、重要なURLに各公式ユーザーエージェントでリクエストを送ります。返されたステータスとHTMLを通常のブラウザーリクエストと比較し、CDNやファイアウォールのログでブロックの有無も確認します。robots.txtにAllowルールがあっても、サーバーがチャレンジ画面、403、内容のないアプリの枠組み、または異なるコンテンツを返していれば、アクセスを許可できているとはいえません。
主要なポイント
- 情報取得用クローラーと学習用クローラーは役割も制御方法も異なるため、個別にテストします。
- robots.txtやHTTPステータスだけでなく、最終的なレスポンス本文を確認します。
- トップページ、記事、商品、ドキュメント、深い階層のURLなど、代表的なページ種別を監査します。
- コンテンツを書き直す前に、CDNとファイアウォールのルールを修正します。アクセスできないページは引用につながりません。
- デプロイ後も確認を繰り返し、サーバーログで実際のクローラーのアクセスを監視します。
AIクローラーのアクセス監査では何を確認するべきか？
アクセスを漏れなく監査するには、4つの層を順番に確認します。robots.txtでの許可の記述、CDNやファイアウォールを経由したネットワークアクセス、リダイレクト後の最終的なHTTPレスポンス、そしてブラウザー側のJavaScriptなしで取得できる有用なHTMLです。1つの層で問題がなくても、次の層が正常に機能するとは限りません。
| 確認する層 | 合格条件 | よくある問題 |
|---|---|---|
| robots.txt | 対象のユーザーエージェントが禁止されていない | ワイルドカードのルールが、意図した許可ルールより優先される |
| ネットワークエッジ | ボットが一般の訪問者と同じオリジンに到達できる | ボット対策が403、429、またはチャレンジ画面を返す |
| HTTP | 適切なリダイレクトを経て、正規URLで単一の200レスポンスが返る | リダイレクトループ、ソフト404、言語・地域設定による行き詰まり |
| 表示コンテンツ | タイトル、回答、リンク、構造化データが初期HTMLに含まれている | アプリの枠組みしか返されず、内容の表示がクライアント側のJavaScriptに依存している |
どのクローラーを個別に確認する必要があるか？
AIのユーザーエージェントをすべて同じものとして扱ってはいけません。検索向けの情報取得、ユーザー操作をきっかけとする取得、モデルの学習では、クローラーも制御方法も異なる場合があります。まず用途ごとに方針を決め、各提供元のドキュメントに記載された正確な公式ユーザーエージェントトークンでテストします。
- OpenAI：検索での発見についてはOAI-SearchBot、ユーザー操作による取得についてはChatGPT-Userをテストし、GPTBotは学習利用に関する方針に沿って確認します。
- Anthropic：ClaudeBotと、最新のドキュメントに記載されている情報取得用エージェントを個別に確認します。
- Perplexity：最新のドキュメントに従い、PerplexityBotとユーザー操作による取得をテストします。
- Google：Googlebotによる検索向けアクセスと、生成AIの学習およびグラウンディングに関するGoogle-Extendedの制御を区別します。
再現可能なクローラーテストを実施するには？
- 代表的なURLを5つ選びます。トップページからリンクされていない、深い階層のページを1つ含めます。
- robots.txtを取得し、各ユーザーエージェントに適用されるルールを記録します。
- 公式のユーザーエージェント文字列を使って各URLにリクエストを送り、ステータス、最終URL、コンテンツタイプ、レスポンスサイズ、応答時間を記録します。
- 返されたHTMLに、canonical、H1、問いへの直接的な回答、主要なリンク、JSON-LDが含まれているか確認します。
- ボット向けのレスポンスを通常のブラウザー向けレスポンスと比較し、重要な差異があれば調査します。
- エッジとオリジンのログで、チャレンジ、レート制限、繰り返し失敗しているリクエストを確認します。
curl -L -A 'OAI-SearchBot' -D headers.txt https://example.com/ -o page.html
grep -Ei '<title|<h1|application/ld\+json|rel="canonical"' page.htmlクローラーのリクエストが失敗した原因を特定するには？
| 確認された結果 | 考えられる原因 | 次に確認すること |
|---|---|---|
| 403またはチャレンジ画面 | CDN、WAF、またはボット管理のルール | 該当するエッジイベントとルールIDを確認する |
| 429 | 自動化されたトラフィック全体で共有されるレート制限 | ボット固有の制限と再試行に関する案内を確認する |
| 200だがHTMLが極端に小さい | クライアント側のみでのレンダリング、またはデータ取得リクエストのブロック | 初期HTMLのソースとサーバーログを確認する |
| ログイン画面や言語・地域の選択画面にリダイレクトされる | ミドルウェアまたは位置情報に基づくルール | Cookie、Accept-Language、canonicalの挙動をテストする |
| 正しいページが返るがスキーマがない | 構造化データがブラウザー内でのみ挿入されている | 重要なマークアップをサーバー側で生成するHTMLに含める |
アクセスの問題が修正されたと判断するには？
修正を検証できたといえるのは、問題のあったユーザーエージェントに対し、一般の訪問者が見るものと実質的に同じ回答を含む正規ページが200で返されたときだけです。コマンド、タイムスタンプ、ヘッダー、本文のハッシュまたは抜粋を保存します。そのうえで、サーバーログで実際のアクセスを確認してください。模擬リクエストで確認できるのはアクセスの可能性であり、実際にクロールされた証拠はログに残ります。
- トップページだけでなく、影響を受けたすべてのテンプレートを再テストします。
- robots.txtとサイトマップの参照に引き続き整合性があることを確認します。
- ブロックされていたときの古いレスポンスがキャッシュから返されていないか確認します。
- CDN、ファイアウォール、レンダリングを変更した際のリリース確認項目に、この監査を追加します。
ステップ・バイ・ステップ
- 1代表的なページを選ぶ
各テンプレートから重要なURLを選び、深い階層のページも少なくとも1つ含めます。
- 2適用されるrobots.txtのルールを確認する
ワイルドカードのルールも含め、各公式AIユーザーエージェントへの適用を個別に確認します。
- 3レスポンスを取得して比較する
リダイレクト、ステータス、ヘッダー、本文サイズ、表示されるコンテンツ、構造化データを記録します。
- 4ブロックの原因を追跡する
エッジとオリジンのログを使い、原因となる具体的なルールやレンダリングの依存関係を特定します。
- 5再テストして監視する
修正後のレスポンスを検証し、実際のクローラーによるアクセスを継続的に確認します。
よくある質問
- GPTBotを許可すれば、ChatGPT Searchも許可されますか？
- 必ずしもそうではありません。OpenAIは、学習、検索での発見、ユーザー操作による取得にそれぞれ別のエージェントを定義しています。許可したいアクセスの範囲に応じて、現在の公式エージェントを個別に監査・設定してください。
- robots.txtで許可しているのに、AIクローラーに403が返るのはなぜですか？
- robots.txtはクロールに関する意向を示すもので、CDN、ファイアウォール、認証層、ボット向けチャレンジを迂回させるものではありません。エッジイベントとオリジンのログを確認し、どの層で拒否されたかを特定してください。
- 200レスポンスが返れば十分ですか？
- いいえ。200でも、チャレンジ画面、内容のないアプリの枠組み、ソフト404、不完全な言語・地域別ページが返されることがあります。返されたHTMLに、実際の回答、canonical、リンク、構造化データが含まれているか確認してください。
- クローラーのアクセス監査はどのくらいの頻度で行うべきですか？
- ホスティング、CDNルール、レンダリング、リダイレクト、認証、robots.txtを変更した後は再テストしてください。構成が安定しているサイトでは、毎月の定期確認とログ監視を組み合わせることで、変更に伴う不具合の再発をほとんど検出できます。
- すべてのAIクローラーを許可するべきですか？
- サイトの運用方針によります。ユーザー操作による取得や検索での発見と、モデルの学習を分けて考えてください。一律のルールを使うのではなく、ドキュメントに記載された各エージェントを、目的に応じて意図的に許可またはブロックします。