調査対象の30のホームページのうち6つはニュース出版社で、サンプルの 20% にあたります。そしてそのすべてが、追跡対象のAIクローラーを少なくとも1つ拒否しています。6社のうち3社は robots.txt でクローラーを拒否しながらページ自体は配信しており、4社目はブラウザには同じURLを配信しつつエッジでクローラーを拒否しています。残る2社は、クローラーかブラウザかを問わず、すべてのリクエストに 401 または 403 を返します。
ニュースの6社は、より広い発見の中でも最も密度の高い部分でもあります。30サイトのうち 9サイト(30%)が追跡対象のクローラーを少なくとも1つブロックしており、ニュースサイト6社はすべてそこに含まれています。
興味深い問いは、彼らがブロックしているかどうか(明らかにブロックしています)ではなく、この測定においてそのブロックがどれだけのコストになっているか、そしてそのコストが誤りなのかどうかです。コンテンツライセンスを交渉している出版社にとっては、交渉の価格かもしれません。そうした交渉を一度もしたことのないサイトにとっては、たいてい誰も見ていない設定にすぎません。
6社とはどこで、それぞれ何を返しましたか?
3社は 200 を返し、robots.txt で追跡対象のクローラーを拒否していました。1社はクローラーに 403、ブラウザに 200 を返しました。2社はすべてのリクエストに 401 または 403 を返しました。
| ホームページ | 返したステータス | 追跡クローラーを許可しているか | スコア |
|---|---|---|---|
| bbc.com | 200 | いいえ — robots.txt | 61 |
| spiegel.de | 200 | いいえ — robots.txt | 56 |
| theguardian.com | 200 | いいえ — robots.txt | 47 |
| zeit.de | クローラーには 403、ブラウザには 200 | いいえ — エッジで拒否 | 26 |
| nytimes.com | 403 | いいえ — robots.txt | 12 |
| reuters.com | 401 | いいえ — robots.txt | 12 |
6社のうち3社は、ページを配信しながらポリシーの層で拒否しています。Zeit はエッジで拒否しており、こちらはより厄介な種類です。robots.txt の行では表現できず、クローラーが交渉することもできません。最後の2社は誰にもページを配信していないため、そのスコアはページではなく拒否を表しています。
ポリシーによるブロックと拒否は何が違いますか?
ポリシーによるブロックは宣言です。ページは配信され、robots.txt がどのエージェントに使わせないかを示し、行儀のよいクローラーはそれに従います。
拒否は壁です。サーバーはリクエスト自体に 401、403、429 を返すので、クローラーはコンテンツを見ることも、そのポリシーを検討することもできません。スキャナーがこれらを blocked と refused という2つのフィールドとして保持しているのは、必要な修正が正反対だからです。一方は編集する1行で、もう一方はCDNやWAFの設定にあるルールで、しかも別のチームが管理する別のシステムにあることがよくあります。
Zeit は後者のきれいな例です。同じURLが、ブラウザ形式のリクエストには 200 を、クローラー形式のリクエストには 403 を返しました。これは robots.txt が意味を持つ前に起きるブロックであり、サンプルの中で唯一、user-agent 以外に何も変えずに外部から証明できる設定です。
この測定で、ブロックは出版社にいくらのコストをもたらしますか?
追跡クローラーのルールは、スコアの 16% を占める最も重いディメンションであるAIクローラーアクセスの内側にあります。追跡対象のクローラーを1つ拒否したサイトは、このディメンションを満点で通過できないため、コンテンツが考慮される前に総スコアの上限が下がります。目安として、コンテンツの深さは 11%、信頼は 10% なので、1回のブロックのコストはコンテンツのディメンション全体を上回ります。
実測された効果は目に見えます。ページを配信した3社のスコアは 61、56、47 で、いずれも応答したサイトの調査平均 62 を下回っています。これは因果関係の証明ではありません。いずれも大きく複雑なホームページで、他のチェックでも失敗しています。しかし「編集上のものではなく構造上の減点」という見方とは整合しています。
これらのクローラーをブロックするのは誤りですか?
大手出版社にとっては、おそらく誤りではありませんし、それを誤りと断じるのはこのサイトの役割でもありません。6社中6社は6つの偶然ではなくパターンですが、1回のホームページスキャンでは、それがライセンス戦略なのか、ペイウォールなのか、bot対策ルールなのか、テンプレートからコピーした robots ファイルなのかを区別できません。
トレードオフは読み取れます。ChatGPT、Claude、Perplexity、Doubao に読まれることは、出版社が引用される方法であり、引用は配信チャネルです。クローラーを拒否することは、そのチャネルをライセンス交渉の材料と引き換えること、交渉が存在しなければ何もないものと引き換えることになります。あるサイトがどちらの状況にあるかは、スキャンには見えません。
そのほかのすべての人にとって重要な区別はこれです。これらのクローラーをブロックしている小さなサイトは、たいていライセンス戦略を実行しているわけではありません。テンプレートをコピーしたか、WAFルールを継承したか、あるスクレイピングの事故の際に「bot全般をブロック」するルールを追加して、user-agent のリストを見直さなかったのです。確認する価値があるのはこちらのケースで、それを順に説明しているのがrobots.txt と WAF のガイドです。
サイト所有者はまず何を確認すべきですか?
robots.txt でクローラーの名前を読み、次にエッジ側の設定がそれと一致しているかを確認してください。両者は食い違うことがあり、その食い違いはブラウザからは見えません。
robots.txtでGPTBot、ClaudeBot、PerplexityBot、Bytespiderを探します。そのいずれかの下にDisallow: /があれば、それはポリシーによるブロックです。- bot対策ルールがこれらの user-agent に 403 を返していないか確認します。スキャンはこれをポリシーによるブロックではなく拒否として報告します。外部から両者を見分ける唯一の方法です。
- 意図して決めてください。自分で選び、理由を言えるブロックと、継承して説明できないブロックは別物です。
どのように測定していて、この数字から分からないことは何ですか?
スキャナーは同じURLへの2つのリクエストを比較します。1つはクローラー形式、1つはブラウザ形式です。両者の差が拒否、robots.txt との一致がポリシーによるブロック、それ以外はすべてページとして採点されます。
見えないのは意図や契約です。出版社がライセンス契約を結んでいるかは分かりませんし、ブロックが守られているかを確かめるためにクローラー自身のログを取りに行くこともありません。測っているのは玄関の公開状態であり、あらゆるドメインに対して1回のリクエストで機能する必要のあるツールとしては、それが正しい範囲です。