これが起こる理由
- ステージング用の
Disallow: /が本番環境にまで反映されてしまう。 公開前のサイトを検索エンジンから隠すための包括的なブロックが、公開後も削除されずに残ってしまうケースです。 - 1つの悪質なスクレイパー向けのルールが、すべてに適用されてしまう。 チームが1つの悪質なボットを止めるためにすべてのクローラーをブロックし、正当なAIエージェントまで巻き込んでしまうケースです。
- 古いブロックリストが、今日のAIクローラーを想定していない。 何年も前に固定の「悪質なボット」のリストに基づいて書かれたrobots.txtが、誰も例外を追加しようとは考えなかった新しいAIユーザーエージェントを意図せず巻き込んでしまうケースです。
- 機密パスが、アクセス制御であるかのようにrobots.txtに列挙されてしまう。 チームがディレクトリを隠す意図で
Disallow: /admin-backup/を追加しますが、そのファイル自体が公開されており、まさにどこを見ればよいかを公開してしまっていることに気づいていないケースです。
問題の特定方法
Scanverraは、robots.txtを一般的な構文チェックから、AI時代特有の2つの具体的な失敗パターンまで、3つの方法でチェックします。
- 構文と到達可能性。 Website AuditのSEOスコアには、Lighthouseの標準的なrobots.txtチェックが含まれます。ファイルが実際に到達可能であること(4xx/5xxレスポンスでないこと)、含まれるすべてのディレクティブがクローラーに認識される形式であることを確認し、不正な形式のルールをSEO上の問題としてフラグします。
- AIクローラーの包括的ブロック。 Scanverra独自の別チェックが、GPTBot、ClaudeBot、CCBot、Google-Extended、PerplexityBotといった既知のAIクローラーを狙った包括的な
Disallow: /やDisallow: /*を検出し、Website AuditのAgent Readinessスコア内の問題として提起します。 - howToRobotsTxt.identifyItem3
実際に残るギャップがひとつあります。3つのチェックのいずれも、Sitemap:ディレクティブが実際に稼働しているサイトマップを指しているかどうかまでは確認しません。あくまで、その行自体が構文として認識されているかどうかだけです。
修正方法
1. どうしてもブロックするなら、包括的なAIブロックをターゲットを絞ったルールに置き換える
そもそもどのAIクローラーを実際に締め出したいのかを意図的に決め、サイト全体ではなく、本当に重要な特定のパスだけを制限してください。
1User-agent: GPTBot
2Disallow: /
3
4User-agent: ClaudeBot
5Disallow: /
6
7User-agent: CCBot
8Disallow: /1User-agent: *
2Allow: /
3Disallow: /internal-search/
4
5Sitemap: https://example.com/sitemap.xml2. 機密パスを隠すためにrobots.txtを使わない
あるパスが本当に非公開である必要があるなら、そのパス自体に認証やnoindexメタタグをかけて保護してください。単にその存在を公表してしまうだけの公開されたrobots.txtルールで対応してはいけません。管理画面やバックアップ、ステージング用ディレクトリを指すDisallowエントリはすべて削除してください。
3. 修正が反映されたことを確認する
robots.txtを編集したら、Website Auditを再実行してください。Agent Readinessスコアの「AI crawlers not blocked」チェックは、スキャンのたびに稼働中のファイルを読み取るため、変更が即座に反映されます。
Scanverraがこれをどう検出するか
Website AuditのSEOスコアは、すべてのスキャンで標準的なrobots.txtの構文と到達可能性のチェックを実行します。それに加えて、専用のAIクローラーチェックが同じ稼働中のファイルを読み取り、既知のAIユーザーエージェントを狙った包括的なDisallowを特に探し、その結果をAgent Readinessスコアの一部として表面化させます。さらに、セキュリティスキャン内の別のチェックが、Disallowルールに記載された機密性の高そうなパスにフラグを立てます。それぞれ異なる失敗パターンを探す、3つのチェックです。