Tony Wang18 分で読めますCloudflareがウェブをクロールしてくれる。ただし自社顧客の29%には入れない。
トップ100万件の調査を2つ結合:上位10万サイトの12.8%がCloudflareの/crawlに閉じており、Cloudflare自身の足場では29.1%に達します。
Cloudflareの/crawlエンドポイントは、サイト全体をまるごとクロールしてくれます。しかも設計上フェアに振る舞います——Cloudflareの言葉を借りれば「robots.txtとAI Crawl Controlをデフォルトで尊重する検証済みボット(仲介エージェント)」です。当社のトップ100万件アンチボット調査と、トップ100万件robots.txt調査を結合し——到達可能な818,614サイト、どちらもオープンデータセット、ドメイン単位の完全一致結合——その礼儀正しさが何を犠牲にしているかを測りました。Cloudflare配下のサイトは、そうでないサイトに比べてCloudflare自身のクローラーに対して閉じている確率が2.6倍:29.1%対11.3%。 そのうち60,528サイトでは、Cloudflare自身のボットマネジメントが当社を能動的にはじきました。ウェブ全体では、上位10万サイトの**12.8%**が閉じています。
門は1つではなく2つ
2026年3月10日のローンチ以降、/crawlについて書かれたもののほとんどは、その限界をアンチボットの問題として枠づけてきました——ウェブのどれだけが、それを止める壁を持っているか。この枠づけは誤りで、しかも見落としやすい形で誤っています。
CloudflareのクローラーはCloudflareBrowserRenderingCrawler/1.0と名乗り、/crawlではユーザーエージェントを変更できません。「CAPTCHA、Turnstileチャレンジ、その他いかなるボット保護機構」も迂回せず、Browser Runのリクエストは「常にボットトラフィックとして識別される」とCloudflare自身が明言しています。つまりサイトは、独立した2つの門のどちらかが閉じていれば、このクローラーに対して閉じています。
- 技術的な門 — サイトが当社のプローブを能動的にはじいた、またはブロックした。これはアンチボット採用インデックスですでに公開している定義そのものです:フィンガープリントされたベンダーの壁 かつ 能動的な執行。
- ポリシーの門 — robots.txtに
User-agent: */Disallow: /がある。これは当社が考えた近似ではありません。Cloudflare自身のドキュメントがサイト運営者に勧めている、まさにそのルールです。同社はこれを「最も制限の強い構成」であり「Browser Runだけでなく、準拠するすべてのボットをブロックする」と説明しています。
2つの門は別々のものを測っており——ここが肝心ですが——ほとんど重なりません。壁だけを数えると閉じたウェブの44.9%を見落とし、robots.txtだけを数えると53.3%を見落とします。
Show the flows
| 到達可能 → /crawlに開いている | 673,753 (69.9%) |
| 到達可能 → 閉じている | 144,861 (15%) |
| 閉じている → 技術的な門のみ | 77,214 (8%) |
| 閉じている → ポリシーの門のみ | 65,026 (6.7%) |
| 閉じている → 両方の門 | 2,621 (0.3%) |
2つの門の表を表示(件数と到達可能サイトに占める割合)
| 門 | サイト数 | 到達可能に占める割合 |
|---|---|---|
| ポリシーの門のみ(robots.txtが拒否、壁なし) | 65,026 | 7.94% |
| 技術的な門のみ(能動的にはじいた、包括的disallowなし) | 77,214 | 9.43% |
| 両方の門 | 2,621 | 0.32% |
| 和集合——/crawlに閉じている | 144,861 | 17.70% |
| 両軸とも開いている | 673,753 | 82.30% |
見出しに使わない数字
この17.70%は文字通りには正しく、この調査で出ると見込まれていた数字でもあります。それでも見出しには使いません。読者が受け取るであろう意味を、この数字は持っていないと考えるからです。
ポリシーの門をTrancoランクで分けると、奇妙な振る舞いをします。技術的な門はウェブの先頭から末尾までほぼ平坦——どこでも10%前後です。ポリシーの門はランキングの中盤で落ち込み、その後テールで3倍に跳ね上がります。
この跳ね上がりをトップレベルドメイン別に分解すると、もはや運営者の判断には見えなくなります。
| TLD | 上位1,000 | 1k–10k | 10k–100k | 100k–1M |
|---|---|---|---|---|
| .us | — | 0.0% | 4.7% | 78.2% |
| .nl | — | 0.0% | 1.5% | 40.8% |
| .uk | 0.0% | 7.3% | 1.1% | 39.2% |
| .ca | 0.0% | 0.0% | 1.3% | 39.1% |
| .xyz | — | 12.5% | 2.4% | 23.4% |
| .se | — | 0.0% | 1.1% | 17.2% |
| .de | 0.0% | 1.4% | 1.7% | 17.7% |
| .com | 7.0% | 2.9% | 3.2% | 7.4% |
| .net | 12.5% | 5.9% | 3.7% | 4.5% |
| .ru | 14.3% | 2.4% | 3.2% | 3.0% |
| .org | 0.0% | 1.5% | 1.9% | 2.3% |
| .br | 0.0% | 1.0% | 2.2% | 1.9% |
.com、.org、.net、.ru、.brはランキング全体を通じて平坦で、本物の編集判断とはこういう形をしています。.usはランクの境界ひとつを挟んで4.7%から**78.2%**へ跳ねます。.nl、.uk、.caも同じ場所で30倍に跳ね上がります。
該当ドメインを抜き出せば、理由は一目でわかります。組み合わせで機械生成されているのです:brightblackjacklounge.nl、clearroulettedaily.nl、coreslotspro.nl、betrixslots.co.uk、blogculturehub.co.uk、smartpalace883.com。共通テンプレートから作られた、大量登録のギャンブル・SEOネットワークであり、そのテンプレートが包括的なDisallow: /を同梱しています。robots.txt自体は本物です(すべてHTTP 200を返しました)が、それが符号化しているのはホスティングのデフォルトであって、誰に自分の仕事を読ませるかについての運営者の判断ではありません。
そこで3つの数字を報告し、最も保守的なものを前面に出します。
| 母集団 | サイト数 | ポリシーの門 | 技術的な門 | /crawlに閉じている |
|---|---|---|---|---|
| 到達可能なトップ100万すべて(生) | 818,614 | 8.26% | 9.75% | 17.70% |
| 該当する6つのccTLDを除外 | 753,939 | 5.57% | 9.51% | 14.74% |
| 上位10万(どのTLDにも異常なし) | 81,577 | 2.96% | 10.21% | 12.79% |
上位10万サイトの12.8%がCloudflareのクローラーに対して閉じています。 これが当社が擁護する数字です。恣意的な除外のない標準的な母集団を使っており、すべてのTLDが一貫した振る舞いを見せる唯一の領域です。しかも3つのうち最も小さい——代替手段を売っている会社が公表する数字としては、正しい方向です。
この訂正の犠牲になったのは、当社が気に入っていた発見です。トップ100万の生データでは、包括的disallowのサイトのほうが能動的にはじく割合が低い(3.9%対10.3%)——看板と門番は代替関係にあり、サイトは壁の代わりに掲示を出す、という小綺麗な物語です。これは人工物でした。上位10万に限ると相関は反転し、robots.txtで拒否するサイトはむしろわずかに多く能動的にもはじきます(生データの0.40倍に対し1.26倍のリフト)。探しにいって見つからなかったので、そのまま報告します。
Cloudflare自身の足場こそ最も苦手な領域
Cloudflareは当社の調査で369,775件の到達可能サイトを保護しています——45.2%で、ウェブ最大のアンチボット足場です(これはCloudflareのWAFとTurnstileを合わせた数字で、WAF単独ではインデックスで公開している45.0%です)。そのクローラーは、まさにそこで最も成績が悪いのです。
369,775サイト——Cloudflare自身のクローラーに閉じている
448,839サイト
両方の門が同じ方向に働いています。Cloudflare配下のサイトは16.4%が能動的にはじき、13.2%が包括的disallowを持ちます。それ以外のウェブは7.8%と4.2%です。しかもこの差はテール由来の人工物ではありません——ドメインネットワークの混入がないランク10万位より上のどの帯域でも、1.76〜1.84倍で保たれます。
Cloudflare対それ以外の表をランク帯域別に表示
| ランク帯域 | CFサイト数 | CF閉鎖率 | 非CFサイト数 | 非CF閉鎖率 | 比 |
|---|---|---|---|---|---|
| 上位1,000 | 175 | 25.71% | 565 | 14.34% | 1.79× |
| 1k–10k | 2,492 | 20.99% | 4,807 | 11.90% | 1.76× |
| 10k–100k | 29,690 | 19.83% | 43,848 | 10.77% | 1.84× |
| 100k–1M | 337,418 | 30.03% | 399,619 | 11.39% | 2.64× |
| 到達可能全体 | 369,775 | 29.14% | 448,839 | 11.34% | 2.57× |
この仕組みは不可解なものではなく、実のところ壁の話ですらありません。選択(セレクション)です。Cloudflareは、最もクロールされたくない層にこそボット防御を売り、いまその層の意向を尊重するクローラーを売っています。この製品は自社の顧客基盤の上で構造的に最も弱いのです。
その文字通りの姿:60,528サイトが、Cloudflareのクローラーを能動的にはじくCloudflareのボットマネジメントを運用しています。
ここはCloudflareに対して公平であるべきで、直感的な読み方はむしろ誤りです。Cloudflareが顧客に代わって自社クローラーを止めているのではありません。FAQは「ボット保護をデフォルトでは強制しない——それは顧客の選択だ」と明記しており、実際に保護下サイトの83.6%は当社の素のリクエストを受動的に通しました。会社は壁を用意し、オフのままにしていた。オンにしたのは顧客です。
Cloudflare保護下の369,775サイトにおける執行姿勢を表示
| 姿勢 | サイト数 | Cloudflare保護下に占める割合 |
|---|---|---|
| パッシブエッジ(壁はあるが通した) | 309,247 | 83.63% |
| 能動的チャレンジ | 44,177 | 11.95% |
| 能動的ブロック | 16,351 | 4.42% |
| 能動的合計 | 60,528 | 16.37% |
| 包括的robots.txt disallow | 48,926 | 13.23% |
| /crawlに閉じている(いずれかの門) | 107,770 | 29.14% |
Enterprise許可リストの罠
あなたがCloudflareの顧客で、自社サイトをCloudflareのクローラーに読ませたいとしましょう——たとえば自社ドキュメントのRAGインデックスを作るために。あなたは60,528件のうちの一つです。Cloudflare自身のBrowser Run FAQはこれに直接答えています。Browser Runの許可リスト登録にはWAFカスタムルールが必要で、「WAFカスタムルールはBot Managementフィールドへのアクセスを必要とするため、自分のウェブサイトでBrowser Runを許可リストに登録するにはEnterpriseプランでなければならない」。
呼び出し側にも抜け道はありません。robots.txtを無視するパラメータはなく、/crawlではユーザーエージェントを上書きできず、リクエストはWeb Bot AuthのSignature-agentヘッダーを伴うため暗号学的に帰属可能です。この準拠性は本当に迂回できません——それは欠陥ではなく設計上の美点です。
しかしそれは、CloudflareのFree・Pro・Businessの顧客には、自分のウェブサイトでCloudflareの壁を越えてCloudflareのクローラーを通す、サポートされた手段がないことを意味します。Cloudflareは取引の両側に座っており、セルフサービスの解決策は最上位ティアにしか存在しません。
2年間のGPTBotブロックはここでは無意味だった
到達可能サイトの11.12%(91,020件)が、少なくとも1つの名前つきAIクローラーをブロックしています——GPTBot、CCBot、ClaudeBot、そしてウェブが2年かけて追加を覚えたリストの残り。そのどれもCloudflareのクローラーを拘束しません。CloudflareBrowserRenderingCrawlerはどのリストにも載っておらず、2026年3月に登場し、当社のrobots調査は6月に実施されました。ウェブ規模でこれを拘束するのは*グループだけです。
一方で、到達可能サイトの26.58%(217,615件)はrobots.txtをまったく配信していません——どのクローラーに対しても、いかなるポリシー制限もありません。
ウェブに蓄積されたクローラーポリシーは、ほとんどが固有名詞のリストです。そして誰かが新しいクローラーを出した瞬間に陳腐化します。
この記事に対する最も強い反論
明白な反論は、最も強い形で自分から述べておくべきです。実際、これは効きます。
「12.8%が閉じているなら87.2%は開いている。あなた方はCloudflareのクローラーがウェブの圧倒的大多数で問題なく動くことを証明しただけだ——しかも反対のことを言う明白な動機を持つスクレイピング事業者だ。」
もっともな指摘で、正直な答えは「はい」です。ウェブの大部分にとって/crawlは本当に十分です。ドキュメントサイト、ブログ、自社プロパティをクロールするなら、これで用は足りますし、安価で、ベータ期間中はrender: falseは課金すらされません。そうでないふりをするより、はっきりそう言うほうがましです。
擁護に値する主張はもっと狭く、この反論に耐えます:閉じている部分はランダムに分布していない。 それはCloudflare自身の顧客に集中し(29.1%対11.3%)、自らを守る意思決定をしたサイトに集中しています。自らを守るサイトは、守る価値のあるデータを持つサイトに偏っています——マーケットプレイス、不動産、フォーラム、クラシファイド。当社のカテゴリ別難易度データでは、この4つが難易度ランキングの上位に並びます。平均的なサイトは開いています。あなたが本当に欲しかったサイトは、そうでない可能性が高いのです。
当社以外による独立した裏づけがひとつあります。The Web Scraping Clubが2026年5月にWAF保護下のサイト群に対して/crawlを手作業で試したところ、ベンダーを問わずそのすべてに失敗しました。標本は小さく、そのようなものとして引用しますが、機構とは整合します——固定で自己申告する偽装不能なユーザーエージェントは、どのベンダーにとっても最も簡単なフィルタ対象だからです。当社自身がベンダー横断で/crawlを試したわけではなく、そう主張してもいません。
第二の反論:robots.txtは勧告的であり、これは能力ではなく礼儀を測っているにすぎない。その通りで、Cloudflare自身がそう述べています——この標準は「自発的なプロトコル」であり、行儀の良いボットだけが従う、と。しかしそれは欠陥ではなく、まさに要点です。/crawlの価値提案そのものが「礼儀正しい側であること」なのですから。準拠性を売りにするクローラーにとって、勧告的な門は硬い門です。
測れなかったこと
正直な穴が4つ。いずれも同じ方向に働きます——当社の数字は下限です。
star_disallow_rootはサイト全体のブロックしか捉えません。*配下のパス指定Disallow:行——/search、/cart、/admin、/api——はCloudflareのクローラーをページ単位で拘束しますが、まったく数えられていません。取得されないコンテンツの割合は、立ち入られないサイトの割合より実質的に高くなります。- AI Crawl Controlは当社からは見えません。 これはエッジ側のトグルであり、外部からのrobots.txtスキャンでは観測できません。これはCloudflare配下のサイトに固有に適用されるため、29.1%はむしろ過小評価になります。Cloudflareの2026年7月1日の発表——9月15日から新規の広告掲載ドメインでAgentおよびTrainingカテゴリをデフォルトでブロックする——はこの数字を動かしますが、その方向を当社は現時点で観測できません。この変更については別途取り上げました。
- Content Signalsは未測定です。 当社のスキャナーは
Content-Signal:行を解析せず、Cloudflare管理のrobots.txtは現在デフォルトでai-train=noを配信しています。 - ホームページ単位、データセンターからの観測、6日離れた2回のスキャン(アンチボット2026-06-14、robots 2026-06-20)。深いページはホームページより壁が多く——当社の深層ページ調査では48.4%対40.5%——技術的な門もまた下限です。
そして利益相反をはっきり述べておきます:当社はCloudflareのクローラーが到達しないサイトに到達するAPIを売っています。だからこそ、基礎となる両データセットはオープンで、結合は共通シードリスト上の内部結合であり、再現スクリプトはこの記事と並んでリポジトリにコミットされています。再計算して、間違っていたら教えてください。
/crawlの位置づけ
正直な制約を持つ、良い製品です。対象が開いているなら——そして大半は開いています——使えばいい。寛容な上限を備えた、検証済みで行儀の良いクローラーです:1ジョブあたり10万ページ、実行7日間、HTML・Markdown・JSON出力、Crawl-delayを尊重する0.5秒のデフォルト遅延。
対象がウェブの防御された部分にあるなら、その準拠性は変更できる設定ではなく、Cloudflare自身のネットワーク上での回避策はEnterpriseプランを要します。マネージドなアンブロッキングAPIが競合ではなく別の道具になるのは、まさにそこです。
クローラーを選ぶなら、ここから3つのことが導かれます。
- 壁だけでなくポリシーの門も確認する。 アンチボットチェックだけでは問いの半分にも答えられません。サイトはきれいな
200を返しながら、robots.txtを読むものすべてに対して立入禁止でありえます。 - 自分がどちらのクローラーを動かしているか把握する。 準拠クローラーと強行クローラーは別々のサイトで失敗し、このデータによればその集合は想像よりはるかに重なりません。どちらを選ぶかは技術ではなくポリシーの判断です。
- 2つの問いは分離できる。 個別URLの壁は無料のアンチボットチェッカーで、robots.txt全体像はAIクローラーブロッキングインデックスで確認できます。
12.8%に到達する
CrawloraのAPIは、礼儀正しいクローラーをはじくサイト上の公開データについて、トランスポート・フィンガープリント・アクセス層を引き受けます——この調査の裏にあるのと同じオープンデータセットとともに。
手法
2つの調査を、登録可能ドメインで内部結合し、アンチボットスキャンが到達したサイトに限定しました。
- アンチボット調査 — run
top1m-20260614、Trancoトップ100万から998,497サイトをスキャン、818,614件が到達可能。オープンデータセット:anti-bot-adoption-index-data(CC BY 4.0)。技術的な門 =protected == trueかつenforcement ∈ {active_block, active_challenge}— /anti-bot-indexで公開している定義です。 - robots調査 — run
aicrawler-top1m-20260620、同一シードリスト。オープンデータセット:ai-crawler-blocking-index-data(CC BY 4.0)。ポリシーの門 =star_disallow_root。 - 結合カバー率は100% — 到達可能な818,614ドメインすべてが両方に存在します。この結合は公開済みのアンチボット数値を正確に再現し(到達可能818,614、壁あり437,857、能動的にはじいた79,835、Cloudflareは存在率45.0%・アクティブ率16.4%)、これが両データセットが同じキーで並んでいることの検証になります。
- 定義についての注記。 Cloudflare対それ以外の比較では、ベンダーをフィンガープリントできなかった場合も能動的執行として数えています。公開済みの厳密な定義はベンダーのフィンガープリントを要求しますが、これはCloudflareのサイトなら必ず存在し、非Cloudflareのサイトでは存在しないことがあります——そちらを使えば比は2.6倍ではなく3.5倍に膨らんでいました。低いほうの数字を報告します。
関連記事
- ウェブのどれだけがアンチボットを使っているか:トップ100万サイトを調査 — 技術的な門の全体像。
- アンチボット採用インデックス — 全サイト検索可能、ベンダーと難易度で絞り込み。
- AIクローラーブロッキングインデックス — ポリシーの門:GPTBot、CCBot、ClaudeBotを名指しでブロックしているのは誰か。
- Cloudflareが2026年にAIクローラーをデフォルトでブロック — どちらの調査からも見えない9月15日の変更。
よくある質問
Cloudflareの/crawlエンドポイントは実際にウェブのどれだけをクロールできますか?
上位10万サイトのうち12.8%が閉じています——リクエストを能動的にはじくアンチボットの壁が10.2%、Cloudflareのクローラーが設計上従う包括的なDisallow: /が3.0%、両方が0.4%です。到達可能なトップ100万全体では生の数値は17.7%ですが、これはTrancoのテールにある大量登録のドメインスパムネットワークがテンプレート化されたrobots.txtを配信しているため膨らんでおり、擁護できる数字として上位10万の値を報告しています。
なぜアンチボットスキャンだけではこの問いに答えられないのですか?
Cloudflareのクローラーは1つではなく2つの独立した門によって制約されるからです。アンチボットスキャンで見えるのは技術的な門——サイトがリクエストをはじくかどうか——だけです。技術的には完全に開いているサイトでも準拠クローラーを止めるポリシーの門、すなわち包括的なDisallow: /は見えません。到達可能なトップ100万では65,026サイトがrobots.txtのみによって閉じており、どのアンチボット測定でも「開いている」と数えられてしまいます。
Cloudflareを使っているサイトのほうがCloudflareのクローラーをブロックしがちですか?
はい、約2.6倍です。Cloudflare配下の到達可能な369,775サイトのうち29.1%がCloudflare自身の/crawlエンドポイントに閉じているのに対し、Cloudflare配下でない448,839サイトでは11.3%です。この差はランク10万位より上のどの帯域でも1.76〜1.84倍で保たれます。60,528サイトでは、CloudflareのボットマネジメントがCloudflare自身のクローラーを能動的にはじきました。
Cloudflareの/crawlエンドポイントにrobots.txtを無視させることはできますか?
できません。robots.txtを無視するパラメータはなく、ユーザーエージェント(CloudflareBrowserRenderingCrawler/1.0)は/crawlでは上書きできず、リクエストはWeb Bot Authの Signature-agent ヘッダーを伴うため暗号学的に帰属可能です。サイト運営者が許可リストに登録することはできますが、CloudflareのBrowser Run FAQによれば、自分のウェブサイトでBrowser Runを許可リストに登録するにはWAFカスタムルール、ひいてはEnterpriseプランが必要です。
robots.txtでGPTBotやCCBotをブロックすればCloudflareのクローラーも止まりますか?
止まりません。到達可能なトップ100万サイトの11.12%(91,020件)が少なくとも1つの名前つきAIクローラーをブロックしていますが、CloudflareBrowserRenderingCrawlerはどのリストにも載っていません——2026年3月に登場したばかりだからです。ウェブ規模でこれを拘束するのは User-agent: * グループだけです。また別途、到達可能サイトの26.58%(217,615件)はrobots.txtをまったく配信していません。
自分のサイトでCloudflareのクローラーをブロックするには?
Cloudflareはrobots.txtでの方法を3つ文書化しています。包括的な 'User-agent: * / Disallow: /' はBrowser Runを含むすべての準拠ボットをブロックします。クロールエンドポイントだけを止めるには 'User-agent: CloudflareBrowserRenderingCrawler' に 'Disallow: /' を指定し、他は許可します。特定の領域だけなら同じユーザーエージェントにパス指定のDisallow行を与えます。robots.txtは勧告的である(Cloudflare自身が、行儀の良いボットだけが従う自発的なプロトコルだと述べています)ため、実際の強制にはWAFルールが必要です。Cloudflareのリファレンスはクロールエンドポイント用のボット検出ID 128292352 を、Quick Actions・Puppeteer・Playwright・CDP用の 119853733 とは別に文書化しています。
Cloudflareの/crawlエンドポイントはrobots.txtを尊重しますか?
はい。設計上そうであり、呼び出し側から上書きする手段はありません。2026年3月10日のローンチに関するCloudflareのチェンジログは、このエンドポイントをrobots.txtとAI Crawl Controlをデフォルトで尊重する検証済みボット(仲介エージェント)と説明しています。Crawl-delayに従い、/crawlでは変更できない固定のユーザーエージェント CloudflareBrowserRenderingCrawler/1.0 を送り、Web Bot Authの Signature-agent ヘッダーを付けるため暗号学的に帰属可能で、Cloudflareのドキュメントによればアクセス CAPTCHA、Turnstileチャレンジ、その他のボット保護機構を迂回しません。