Cloudflare crawlt das Web für dich. Bei 29% der eigenen Kunden kommt es nicht rein.

Cloudflares /crawl-Endpoint crawlt eine komplette Site für dich, und er spielt dabei per Design fair: Er ist, in Cloudflares Worten, „ein verifizierter Bot (Intermediary Agent), der robots.txt und AI Crawl Control standardmäßig respektiert". Wir haben unseren Top-1M-Anti-Bot-Zensus mit unserem Top-1M-robots.txt-Zensus verknüpft — 818.614 erreichbare Sites, beide offene Datensätze, ein exakter Domain-für-Domain-Join — um zu messen, was ihn diese Höflichkeit kostet. Eine Site hinter Cloudflare ist 2,6-mal häufiger für Cloudflares eigenen Crawler gesperrt als eine Site, die nicht dahinter liegt: 29,1% gegenüber 11,3%. Auf 60.528 dieser Sites hat Cloudflares eigenes Bot-Management uns aktiv abgewiesen. Webweit sind 12,8% der 100.000 größten Sites für ihn zu.

Zwei Tore, nicht eins

Fast alles, was seit dem Launch am 10. März 2026 über /crawl geschrieben wurde, behandelt die Grenze als Anti-Bot-Problem: Wie viel des Webs hat eine Wand, die ihn stoppt. Diese Rahmung ist falsch — und zwar auf eine Weise, die leicht zu übersehen ist.

Cloudflares Crawler identifiziert sich als CloudflareBrowserRenderingCrawler/1.0, und der User-Agent ist für /crawl nicht anpassbar. Er umgeht keine „CAPTCHAs, Turnstile-Challenges oder andere Bot-Schutzmechanismen", und Cloudflare bestätigt, dass Browser-Run-Requests „immer als Bot-Traffic identifiziert" werden. Eine Site ist also für ihn geschlossen, wenn eines von zwei unabhängigen Toren zu ist:

• Das technische Tor — die Site hat unseren Probe-Request aktiv abgewiesen oder blockiert. Das ist genau die Definition, die bereits in unserem Anti-Bot Adoption Index veröffentlicht ist: eine fingerprinted Vendor-Wand plus aktives Enforcement.
• Das Policy-Tor — robots.txt enthält User-agent: * / Disallow: /. Das ist keine Näherung von uns, sondern exakt die Regel, die Cloudflares eigene Dokumentation Site-Betreibern empfiehlt, beschrieben als „die restriktivste Konfiguration", die „alle konformen Bots blockiert, nicht nur Browser Run".

Die beiden Tore messen Verschiedenes — und, das ist der Punkt, sie überschneiden sich kaum. Zählt man nur Wände, fehlen 44,9% des geschlossenen Webs; zählt man nur robots.txt, fehlen 53,3%.

Show the flows

Erreichbar → Offen für /crawl	673,753 (69.9%)
Erreichbar → Geschlossen	144,861 (15%)
Geschlossen → Nur technisches Tor	77,214 (8%)
Geschlossen → Nur Policy-Tor	65,026 (6.7%)
Geschlossen → Beide Tore	2,621 (0.3%)

Tabelle der zwei Tore anzeigen (Anzahl und % der erreichbaren Sites)

Tor	Sites	% der erreichbaren
Nur Policy-Tor (robots.txt sagt nein; keine Wand)	65.026	7,94%
Nur technisches Tor (aktiv abgewiesen; kein Blanket-Disallow)	77.214	9,43%
Beide Tore	2.621	0,32%
Vereinigung — für /crawl geschlossen	144.861	17,70%
Auf beiden Achsen offen	673.753	82,30%

Die Zahl, mit der wir nicht aufmachen

Diese 17,70% stimmen wörtlich, und es ist die Zahl, die von dieser Studie erwartet wurde. Wir machen trotzdem nicht damit auf — weil wir nicht glauben, dass sie bedeutet, was Leserinnen und Leser darin lesen würden.

Teilt man das Policy-Tor nach Tranco-Rang auf, verhält es sich seltsam. Das technische Tor ist vom Kopf des Webs bis in den Schwanz nahezu flach — überall rund 10%. Das Policy-Tor bricht in der Mitte des Rankings ein und verdreifacht sich dann im Schwanz.

Technisches Tor (Wand)9.86% → 9.7%Policy-Tor (robots.txt)6.62% → 8.85%

Top 1.000

9.86%

6.62%

1k–10k

10.8%

2.86%

10k–100k

10.15%

2.93%

100k–1M

9.7%

8.85%

Schlüsselt man diesen Ausschlag nach Top-Level-Domain auf, sieht er nicht mehr nach Publisher-Verhalten aus:

TLD	Top 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 und .br sind über das gesamte Ranking flach — so sieht eine echte redaktionelle Entscheidung aus. .us springt über eine einzige Rang-Grenze von 4,7% auf 78,2%. .nl, .uk und .ca springen an derselben Stelle um den Faktor dreißig.

Ein Blick auf die Domains erklärt es sofort. Sie sind kombinatorisch erzeugt: brightblackjacklounge.nl, clearroulettedaily.nl, coreslotspro.nl, betrixslots.co.uk, blogculturehub.co.uk, smartpalace883.com. Massenregistrierte Glücksspiel- und SEO-Netzwerke aus einem gemeinsamen Template — und das Template liefert ein pauschales Disallow: / mit. Ihre robots.txt-Dateien sind echt (jede einzelne lieferte HTTP 200), aber sie kodieren einen Hosting-Default, keine Entscheidung eines Publishers darüber, wer seine Arbeit lesen darf.

Deshalb berichten wir drei Zahlen und führen mit der konservativsten:

Grundgesamtheit	Sites	Policy-Tor	Technisches Tor	Für /crawl geschlossen
Alle erreichbaren Top 1M (roh)	818.614	8,26%	9,75%	17,70%
Ohne die sechs betroffenen ccTLDs	753.939	5,57%	9,51%	14,74%
Top 100.000 (keine TLD zeigt die Anomalie)	81.577	2,96%	10,21%	12,79%

12,8% der 100.000 größten Sites sind für Cloudflares Crawler geschlossen. Das ist die Zahl, die wir verteidigen. Sie nutzt eine Standard-Grundgesamtheit ohne Ad-hoc-Ausschlüsse, und sie ist die einzige Stelle, an der sich jede TLD konsistent verhält. Sie ist außerdem die kleinste der drei — die richtige Richtung für eine Zahl, die ein Unternehmen veröffentlicht, das die Alternative verkauft.

Opfer dieser Korrektur ist ein Befund, den wir mochten. In den Rohdaten der Top 1M weisen Blanket-Disallow-Sites seltener aktiv ab (3,9% gegenüber 10,3%) — eine hübsche Geschichte darüber, dass Schild und Wache Substitute seien, dass Sites ein Hinweisschild statt einer Mauer aufstellen. Es ist ein Artefakt. Beschränkt man sich auf die Top 100.000, dreht sich die Korrelation um: Sites, die in robots.txt nein sagen, weisen etwas häufiger auch aktiv ab (Lift 1,26× gegenüber 0,40× in den Rohdaten). Wir berichten das, weil wir danach gesucht haben und es nicht da war.

Cloudflares eigener Fußabdruck ist sein schwierigstes Terrain

Cloudflare schützt in unserem Zensus 369.775 erreichbare Sites — 45,2%, mit Abstand der größte Anti-Bot-Fußabdruck im Web. (Das fasst Cloudflares WAF mit Turnstile zusammen; die WAF allein sind die auf dem Index veröffentlichten 45,0%.) Genau dort schneidet sein Crawler am schlechtesten ab.

Sites hinter Cloudflare29,1%

369.775 Sites — für Cloudflares eigenen Crawler geschlossen

Sites nicht hinter Cloudflare11,3%

448.839 Sites

Beide Tore drücken in dieselbe Richtung. Cloudflare-geschützte Sites weisen zu 16,4% aktiv ab und tragen zu 13,2% ein Blanket-Disallow; der Rest des Webs kommt auf 7,8% und 4,2%. Und der Abstand ist kein Artefakt des Schwanzes — er hält sich bei 1,76×–1,84× in jedem Band oberhalb von Rang 100k, wo die Domain-Netzwerk-Kontamination fehlt.

Tabelle Cloudflare gegen den Rest nach Rangband anzeigen

Rangband	CF-Sites	CF geschlossen	Nicht-CF-Sites	Nicht-CF geschlossen	Verhältnis
Top 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×
Alle erreichbaren	369.775	29,14%	448.839	11,34%	2,57×

Der Mechanismus ist kein Rätsel, und es geht dabei nicht wirklich um die Wand. Es ist Selektion. Cloudflare hat Bot-Abwehr genau an die Gruppe von Sites verkauft, die am wenigsten gecrawlt werden will — und verkauft nun einen Crawler, der deren Wünsche respektiert. Das Produkt ist auf der eigenen Kundenbasis strukturell am schwächsten.

Die wörtliche Fassung davon: 60.528 Sites betreiben Cloudflare-Bot-Management, das Cloudflares Crawler aktiv abweist.

Hier sollte man Cloudflare gegenüber fair bleiben, denn die naheliegende Lesart ist die falsche. Cloudflare blockiert seinen eigenen Crawler nicht im Auftrag der Kunden: Die FAQ hält fest, dass Cloudflare „Bot-Schutz nicht standardmäßig erzwingt — das ist die Entscheidung des Kunden", und 83,6% der geschützten Sites ließen unseren einfachen Request passiv durch. Das Unternehmen hat die Wand geliefert und ausgeschaltet gelassen. Eingeschaltet haben sie die Kunden.

Cloudflares Enforcement-Haltung über seine 369.775 geschützten Sites anzeigen

Haltung	Sites	% der Cloudflare-geschützten
Passive Edge (Wand vorhanden, ließ uns durch)	309.247	83,63%
Aktive Challenge	44.177	11,95%
Aktiver Block	16.351	4,42%
Aktiv gesamt	60.528	16,37%
Blanket-robots.txt-Disallow	48.926	13,23%
Für /crawl geschlossen (eines der Tore)	107.770	29,14%

Die Enterprise-Allowlist-Falle

Angenommen, du bist Cloudflare-Kunde und möchtest, dass Cloudflares Crawler deine eigene Site liest — etwa weil du einen RAG-Index über deine eigene Dokumentation baust. Du gehörst zu den 60.528. Cloudflares eigene Browser-Run-FAQ beantwortet das direkt: Das Allowlisting von Browser Run braucht eine WAF-Custom-Rule, und „du musst auf einem Enterprise-Plan sein, um Browser Run auf deiner eigenen Website auf die Allowlist zu setzen, weil WAF-Custom-Rules Zugriff auf Bot-Management-Felder erfordern".

Auf Aufrufer-Seite gibt es ebenfalls kein Schlupfloch. Es gibt keinen Parameter, um robots.txt zu ignorieren, der User-Agent lässt sich für /crawl nicht überschreiben, und Requests tragen einen Signature-agent-Header unter Web Bot Auth — sie sind also kryptografisch zurechenbar. Die Konformität ist wirklich nicht umgehbar, was eine Design-Tugend ist und kein Mangel.

Aber es bedeutet: Ein Free-, Pro- oder Business-Kunde bei Cloudflare hat keinen unterstützten Weg, Cloudflares Crawler durch Cloudflares Wand auf die eigene Website zu lassen. Cloudflare sitzt auf beiden Seiten des Geschäfts, und die Selbstbedienungs-Lösung existiert nur in der obersten Stufe.

Zwei Jahre GPTBot-Blocken haben hier nichts gebracht

11,12% der erreichbaren Sites (91.020) blockieren mindestens einen namentlich genannten AI-Crawler — GPTBot, CCBot, ClaudeBot und den Rest der Liste, die das Web sich in zwei Jahren angewöhnt hat. Nichts davon bindet Cloudflares Crawler. CloudflareBrowserRenderingCrawler steht auf keiner dieser Listen, er startete im März 2026, und unser Robots-Zensus lief im Juni. In der Breite bindet ihn nur die *-Gruppe.

Gleichzeitig liefern 26,58% der erreichbaren Sites (217.615) überhaupt keine robots.txt aus — keinerlei Policy-Einschränkung, für keinen Crawler.

Die angesammelte Crawler-Policy des Webs ist im Wesentlichen eine Liste von Eigennamen — und sie veraltet in dem Moment, in dem jemand einen neuen Crawler ausliefert.

Das stärkste Argument gegen diesen Beitrag

Wir sollten den naheliegenden Einwand in seiner stärksten Form aussprechen, denn er sitzt.

„12,8% geschlossen heißt 87,2% offen. Ihr habt gerade bewiesen, dass Cloudflares Crawler für die überwältigende Mehrheit des Webs bestens funktioniert — und ihr seid ein Scraping-Anbieter mit einem offensichtlichen Motiv, das Gegenteil zu behaupten."

Das ist fair, und die ehrliche Antwort lautet: ja. Für den größten Teil des Webs reicht /crawl wirklich aus. Wer Dokumentations-Sites, Blogs oder eigene Properties crawlt, kommt damit ans Ziel, es ist günstig, und während der Beta wird render: false gar nicht abgerechnet. Das sagen wir lieber deutlich, als so zu tun, als wäre es anders.

Die verteidigenswerte Aussage ist enger und übersteht den Einwand: Der geschlossene Anteil ist nicht zufällig verteilt. Er konzentriert sich auf Cloudflares eigene Kunden (29,1% gegenüber 11,3%) und auf Sites, die sich bewusst für Verteidigung entschieden haben. Sites, die sich verteidigen, sind überproportional jene mit verteidigenswerten Daten — Marktplätze, Immobilien, Foren, Kleinanzeigen. In unseren Kategorie-Schwierigkeitsdaten stehen diese vier oben im Schwierigkeits-Ranking. Die durchschnittliche Site ist offen. Die Site, die du eigentlich wolltest, eher nicht.

Es gibt eine unabhängige Bestätigung, und sie stammt nicht von uns. Als The Web Scraping Club im Mai 2026 /crawl von Hand gegen eine Reihe WAF-geschützter Sites testete, scheiterte es an jeder einzelnen, über Vendor-Grenzen hinweg. Das ist eine kleine Stichprobe, und wir zitieren sie als solche — aber sie passt zum Mechanismus: Ein fester, sich selbst ausweisender, nicht fälschbarer User-Agent ist das Einfachste, worauf ein Vendor filtern kann. Wir haben /crawl nicht selbst gegen eine Vendor-Matrix getestet und behaupten das auch nicht.

Ein zweiter Einwand: robots.txt ist beratend, also misst das Höflichkeit statt Fähigkeit. Stimmt — Cloudflare sagt das selbst und merkt an, der Standard sei „ein freiwilliges Protokoll", dem nur wohlerzogene Bots folgen. Aber genau das ist der Punkt und kein Mangel. Das gesamte Wertversprechen von /crawl besteht darin, der Höfliche zu sein. Für einen Crawler, dessen Verkaufsargument Konformität ist, ist ein beratendes Tor ein hartes Tor.

Was wir nicht messen konnten

Vier ehrliche Lücken, die alle in dieselbe Richtung wirken: Unsere Zahl ist eine Untergrenze.

1. star_disallow_root erfasst nur vollständige Sperren. Pfadbezogene Disallow:-Zeilen unter * — /search, /cart, /admin, /api — binden Cloudflares Crawler Seite für Seite und sind überhaupt nicht mitgezählt. Der Anteil der Inhalte, die er nicht holen wird, liegt deutlich über dem Anteil der Sites, die er nicht betreten wird.
2. AI Crawl Control ist für uns unsichtbar. Es ist ein Edge-seitiger Schalter; kein externer robots.txt-Scan kann ihn sehen. Er betrifft speziell Cloudflare-geschützte Sites, macht die 29,1% also zu einer Untertreibung. Cloudflares Ankündigung vom 1. Juli 2026 — dass ab dem 15. September neue werbefinanzierte Domains standardmäßig die Kategorien Agent und Training blockieren — wird diese Zahl bewegen, in eine Richtung, die wir derzeit nicht beobachten können. Diese Änderung haben wir separat behandelt.
3. Content Signals sind ungemessen. Unser Scanner parst keine Content-Signal:-Zeilen, und von Cloudflare verwaltete robots.txt liefert inzwischen standardmäßig ai-train=no aus.
4. Homepage-Ebene, Rechenzentrums-Vantage, zwei Scans im Abstand von sechs Tagen (Anti-Bot 14.06.2026, Robots 20.06.2026). Tiefe Seiten sind stärker ummauert als Homepages — 48,4% gegenüber 40,5% in unserem Deep-Page-Zensus — das technische Tor ist also ebenfalls eine Untergrenze.

Und ein Interessenkonflikt, klar benannt: Wir verkaufen eine API, die Sites erreicht, die Cloudflares Crawler nicht bekommt. Genau deshalb sind beide zugrundeliegenden Datensätze offen, der Join ist ein Inner Join auf einer gemeinsamen Seed-Liste, und das Reproduktions-Skript liegt neben diesem Beitrag im Repository. Rechne es nach und sag uns, wenn wir falsch liegen.

Wo das /crawl einordnet

Es ist ein gutes Produkt mit einer ehrlichen Einschränkung. Wenn deine Ziele offen sind — und die meisten sind es — nimm es. Es ist ein verifizierter, wohlerzogener Crawler mit großzügigen Limits: 100.000 Seiten pro Job, sieben Tage Laufzeit, Ausgabe als HTML, Markdown oder JSON, eine Standardverzögerung von 0,5 Sekunden, die Crawl-delay respektiert.

Wenn deine Ziele im verteidigten Teil des Webs liegen, ist seine Konformität keine Einstellung, die du ändern kannst, und die Abhilfe in Cloudflares eigenem Netz kostet einen Enterprise-Plan. Genau dort ist eine Managed-Unblocking-API ein anderes Werkzeug — kein konkurrierendes.

Drei Dinge folgen daraus, wenn du einen Crawler auswählst:

• Prüfe das Policy-Tor, nicht nur die Wand. Ein Anti-Bot-Check beantwortet kaum die halbe Frage. Eine Site kann ein sauberes 200 liefern und trotzdem für alles tabu sein, was robots.txt liest.
• Wisse, welche Art Crawler du betreibst. Ein konformer und ein robuster Crawler scheitern an unterschiedlichen Sites, und diese Daten sagen: Die beiden Mengen überschneiden sich weit weniger als man annimmt. Die Wahl zwischen ihnen ist eine Policy-Entscheidung, keine technische.
• Die beiden Fragen sind trennbar. Die Wand einer einzelnen URL prüfst du mit unserem kostenlosen Anti-Bot-Checker, das gesamte robots.txt-Bild im AI-Crawler Blocking Index.

Die 12,8% erreichen

Crawloras API übernimmt Transport, Fingerprinting und Zugriffsebene für öffentliche Daten auf Sites, die einen höflichen Crawler abweisen — mit denselben offenen Datensätzen, die hinter dieser Studie stehen.

Beliebige URL kostenlos prüfenAnti-Bot Index ansehen

Methode

Zwei Zensus, ein Inner Join auf der registrierbaren Domain, beschränkt auf die Sites, die der Anti-Bot-Scan erreicht hat.

• Anti-Bot-Zensus — Run top1m-20260614, 998.497 gescannte Sites aus der Tranco-Top-1M, 818.614 erreichbar. Offener Datensatz: anti-bot-adoption-index-data (CC BY 4.0). Technisches Tor = protected == true und enforcement ∈ {active_block, active_challenge} — die auf /anti-bot-index veröffentlichte Definition.
• Robots-Zensus — Run aicrawler-top1m-20260620, gleiche Seed-Liste. Offener Datensatz: ai-crawler-blocking-index-data (CC BY 4.0). Policy-Tor = star_disallow_root.
• Die Join-Abdeckung beträgt 100% — alle 818.614 erreichbaren Domains sind in beiden Datensätzen vorhanden. Der Join reproduziert die veröffentlichten Anti-Bot-Zahlen exakt (818.614 erreichbar, 437.857 ummauert, 79.835 aktiv abweisend, Cloudflare mit 45,0% Präsenz und 16,4% Active Rate) — das ist der Beleg, dass beide Datensätze gleich verschlüsselt sind.
• Eine definitorische Anmerkung. Der Vergleich Cloudflare gegen den Rest zählt aktives Enforcement auch dort, wo kein Vendor fingerprinted werden konnte. Die striktere veröffentlichte Definition verlangt einen Vendor-Fingerprint, den eine Cloudflare-Site immer hat und eine Nicht-Cloudflare-Site möglicherweise nicht — sie hätte das Verhältnis auf 3,5× statt 2,6× aufgebläht. Wir berichten den niedrigeren Wert.

Weiterlesen

• Wie viel des Webs betreibt Anti-Bot? Wir haben die Top 1.000.000 gescannt — das technische Tor in voller Breite.
• Der Anti-Bot Adoption Index — durchsuchbar, jede Site, filterbar nach Vendor und Schwierigkeit.
• Der AI-Crawler Blocking Index — das Policy-Tor: wer GPTBot, CCBot und ClaudeBot namentlich blockiert.
• Cloudflare blockiert AI-Crawler 2026 standardmäßig — die Änderung vom 15. September, die kein Zensus sehen kann.