Cloudflare blockiert AI-Crawler 2026 standardmäßig: Was sich ändert und was du tun kannst

Cloudflare sitzt vor rund einem Fünftel des Webs. Am 1. Juli 2026 kündigte das Unternehmen den nächsten Schritt einer Policy an, die es ein Jahr zuvor gestartet hatte: AI-Crawler bekommen kein pauschales „block oder allow“ mehr — sie werden in Kategorien sortiert, und zwei der drei sind auf Seiten, die einer Site Geld einbringen, jetzt standardmäßig blockiert.

Wenn du irgendeine Art von Scraper, Datenpipeline oder AI-Agent betreibst, der das offene Web berührt, solltest du das verstehen — nicht weil es gezielt bösartiges Scraping angeht, sondern weil die neuen Defaults nicht zwischen „AI-Unternehmen trainiert ein Modell“ und „Entwickler betreibt einen legitimen Research- oder Monitoring-Job“ unterscheiden, solange du nicht nachweisen kannst, welches von beidem du bist.

Was sich konkret geändert hat

Cloudflares Post — Content Independence Day: the next chapter — teilt AI-Bot-Traffic in drei Kategorien mit jeweils präziser Definition:

• Search — „jedes Verhalten, das deine Inhalte sammelt oder indexiert, um später Fragen dazu zu beantworten.“ Der klassische Deal: Ein Index entsteht, die Site bekommt Referral-Traffic zurück. Bleibt standardmäßig erlaubt.
• Agent — „automatisiertes Verhalten, das üblicherweise in Echtzeit im Auftrag einer Person handelt, um gerade jetzt etwas zu erledigen“ — ein Fetch im ChatGPT-User-Stil oder ein Browser-Use-Agent wie Gemini oder Claude, der mitten in einer Session im Auftrag von jemandem agiert.
• Training — ein Crawler, der Inhalte sammelt, um ein Modell zu trainieren oder zu fine-tunen, wobei „deine Daten dauerhaft in die zugrunde liegende Architektur absorbiert werden“, statt nur transient referenziert zu werden.

Ab dem 15. September 2026 sind Agent- und Training-Bots auf werbefinanzierten Seiten — Seiten, die ein Site-Betreiber gebaut hat, um von einem menschlichen Besucher gesehen und monetarisiert zu werden — standardmäßig blockiert. Search-Bots sind davon nicht betroffen. Entscheidend: Dieser Default gilt für:

• Domains, die neu bei Cloudflare sind nach diesem Datum,
• neue Sites, die bestehende Kunden hinzufügen, und
• Free-Tier-Accounts, die die Einstellung nicht angefasst haben.

Bestehende zahlende Kunden behalten, was auch immer sie bereits konfiguriert haben — das ist ein Default für Neuanmeldungen, keine rückwirkende Blockade über Cloudflares gesamten Fußabdruck. Multi-Purpose-Crawler (Googlebot, Bingbot, Applebot — die inzwischen alle als Search- und AI-Training-Crawler doppelt fungieren) werden nach der restriktivsten anwendbaren Regel über alle kombinierten Funktionen hinweg behandelt.

Es gibt auch ein genuin nützliches neues Stück Infrastruktur für alle, die eine Datennutzungs-Präferenz ausdrücken wollen, statt nur als Kategorie geblockt oder erlaubt zu werden: eine erweiterte Content-Signal-robots.txt-Direktive, jetzt standardmäßig in Cloudflares gemanagter robots.txt enthalten:

Content-Signal: search=yes,ai-train=no,use=reference

Der neue use=-Parameter ist die interessante Ergänzung — use=immediate („interagieren, aber nichts speichern oder wiederverwenden“), use=reference (der Default — „indexieren, exzerpieren und zurückverlinken“) oder use=full („zusammenfassen und reproduzieren“). Es ist eine deklarierte Präferenz, kein erzwungener Block — Enforcement passiert an Cloudflares Edge, nicht über robots.txt-Compliance —, aber es ist das bislang klarste öffentliche Signal dafür, wie Site-Betreiber ihre Inhalte genutzt sehen wollen.

Warum Cloudflare das gemacht hat

Die technische Änderung ist klein; die Zahlen dahinter erklären die Motivation. Cloudflares zeitgleich veröffentlichter Begleitreport, Agentic internet: one year of bot report data, legt den Trend dar, auf den reagiert wird:

• 52% der Crawler-Requests sind inzwischen AI-Training, gegenüber 22% im Frühjahr 2025.
• Mehr als die Hälfte des gesamten Internet-Traffics ist inzwischen nicht menschlich.
• Bei einigen der am stärksten gecrawlten Content-Kategorien ist menschlicher Traffic in weniger als einem Jahr um bis zu 40% zurückgegangen.
• Google treibt weiterhin ~88% des Referral-Traffics an und hält etwa 2x mehr Informationen als jeder einzelne AI-Konkurrent — das „Google Zero“-Szenario (eine Welt, in der Suche Publishern kaum bis keinen Traffic mehr schickt) ist das, worauf sich Publisher Berichten zufolge einstellen.

Das baut auf Cloudflares erstem Content Independence Day (1. Juli 2025) auf, als das Unternehmen „AI-Bots blockieren“ zum Default für neue Domains machte und Pay Per Crawl einführte — eine HTTP 402 Payment Required-Mechanik, bei der ein unbezahlter Crawler einen 402 mit einem crawler-price-Header bekommt, gegenbieten oder akzeptieren kann, und ein erfolgreicher bezahlter Fetch einen 200 mit crawler-charged zurückgibt. Cloudflare fungiert als Merchant of Record und zahlt Publisher monatlich aus. Ein Jahr später sagt Cloudflare, das habe sich zu einem breiteren Pay-Per-Use-Marktplatz entwickelt (Launch-Partner Ceramic.ai und You.com), wobei weder Cloudflares Post noch die Berichterstattung Preise oder Cloudflares Anteil offenlegen.

Du wirst auch eine vielzitierte Zahl sehen — „416 Milliarden blockierte AI-Bot-Requests“ —, die in manchen Berichten mit dieser Story verknüpft wird. Diese Zahl ist real, stammt aber aus einem Interview mit Cloudflare-CEO Matthew Prince im Dezember 2025, das die ersten sechs Monate nach dem 2025-Launch beschreibt — nicht eine Statistik aus der Ankündigung vom Juli 2026 selbst. Gut zu wissen, damit du nicht durcheinanderbringst, welche Policy-Generation welche Zahl produziert hat.

Der Teil, der zählt, wenn du nicht die Zielgruppe bist

Cloudflares Framing richtet sich an AI-Unternehmen, die Modelle trainieren, und an Agents, die im Autopilot-Modus Seiten abrufen. Aber der Enforcement-Mechanismus liest keine Absicht — er liest Identität, und Identität nachzuweisen ist jetzt ein genehmigungspflichtiger Prozess, kein Header, den du selbst setzen kannst:

• Verified-Bot-Programm — Bot-Betreiber melden sich an und verpflichten sich zu „ehrlicher Selbstdarstellung“ ihrer Identität und ihres Zwecks. Das ist der primäre Weg, um als spezifische, vertrauenswürdige Kategorie erkannt zu werden, statt als unverifizierter Traffic zusammengeworfen zu werden.
• BotBase — ein neues öffentliches, durchsuchbares Verzeichnis bekannter Bots und Agents, auf das Site-Betreiber direkt in ihren eigenen Custom-Security-Regeln verweisen können.
• Forwarded-Header-Selbstdeklaration (Forwarded: for="openai";use="reference", nach RFC 7239) — erlaubt einem Intermediär zu deklarieren, in wessen Auftrag und warum er handelt, was „transitives Vertrauen“ durch Proxys oder Agent-Frameworks hindurch ermöglicht.

Nichts davon ist eine statische Allowlist, die ein Drittanbieter-Scraper einfach übernehmen kann. Wenn dein Traffic nicht individuell verifiziert ist und du nach dem 15. September eine neue Cloudflare-Site oder einen unberührten Free-Tier-Account triffst, ist die ehrliche Lesart: Dein legitimer Research-, Preismonitoring- oder Datensatz-Job riskiert denselben Default-Block wie ein tatsächlicher AI-Training-Crawler — es sei denn, du respektierst das deklarierte Content-Signal der Site und bleibst innerhalb davon, oder du läufst über Infrastruktur, die die Identitätsebene bereits für dich abdeckt.

Für die tieferen Mechanismen, wie Cloudflare (und DataDome, PerimeterX/HUMAN) Requests überhaupt fingerprinten und blockieren — IP-Reputation, TLS-/HTTP-Fingerprinting und die JS-Sensor-Ebene — siehe Scraping von Sites, die Bots blockieren; dieser Beitrag handelt von der Policy-Ebene, die darüber sitzt.

Wie du weiterhin öffentliche Daten sammelst

Sortiert nach Praxistauglichkeit für die meisten Teams:

1. Halte dich an das deklarierte Content-Signal der Site, wo du es lesen kannst

Wenn eine Site ai-train=no oder use=immediate publiziert, ist das eine explizite Absichtserklärung des Betreibers — ein Good-Faith-Scraper sollte sie respektieren, sowohl weil es das Richtige ist als auch weil es der klarste Beweis dafür ist, dass du nicht der Traffic bist, auf den diese Policy zielt.

2. Registriere dich als Verified Bot, wenn du in echtem Umfang arbeitest

Lohnt sich, wenn du eine große, identifizierbare Crawling-Operation betreibst und erstklassige Anerkennung willst statt dich auf generisches Unblocking zu verlassen. Es ist ein echtes Commitment (akkurate Selbstdarstellung, laufende Compliance), keine Checkbox — die meisten kleinen Teams und einmaligen Research-Jobs werden die Messlatte nicht erreichen, damit sich der Prozess lohnt.

3. Eine gemanagte Unblocking-API (Crawlora)

Für den Standardfall — du brauchst öffentliche Daten von Sites, die zunehmend standardmäßig unverifizierten Traffic blockieren, und willst nicht selbst die Proxy-Rotation, das Fingerprinting und die Identitäts-Verhandlungsebene bauen und pflegen — decken Crawloras Web Scraping API und der /web/scrape-Endpoint die Zugriffsebene hinter einem Key ab:

curl -X POST "https://api.crawlora.net/api/v1/web/scrape" \
  -H "x-api-key: $CRAWLORA_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"url": "https://example.com", "formats": ["markdown"], "render": "auto"}'

import requests

resp = requests.post(
    "https://api.crawlora.net/api/v1/web/scrape",
    headers={"x-api-key": "YOUR_API_KEY"},
    json={"url": "https://example.com", "formats": ["markdown"], "render": "auto"},
)
print(resp.json()["data"]["markdown"][:500])

render: "auto" eskaliert von einem einfachen Fetch zu einem echten Browser nur dann, wenn eine Site es verlangt — dasselbe Eskalationsmuster, das heute durch Cloudflare, DataDome und PerimeterX kommt. Das gibt dir keinen Verified-Bot-Status; es ist die praktische Alternative für Teams, die öffentliche Daten in einem Umfang sammeln, der zu klein ist, um ein eigenes Verifizierungsprogramm zu rechtfertigen, aber real genug, dass „einfach von einer anderen IP nochmal versuchen“ nicht mehr funktioniert.

Ein Hinweis zur Compliance

Nichts davon ändert die zugrunde liegenden Regeln, es hebt nur die technische und identitätsbezogene Messlatte für ihre Durchsetzung. Egal welchen Weg du wählst:

• Sammle nur öffentliche Daten, zu deren Zugriff du autorisiert bist — das Content-Signal und die Nutzungsbedingungen einer Site gelten unabhängig davon, ob du technisch am Block vorbeikommst.
• Behandle gescrapte personenbezogene Daten (Namen, Reviews, Profile) unter DSGVO/CCPA genauso wie aus jeder anderen Quelle — minimiere, was du speicherst, und habe eine Rechtsgrundlage.
• Wenn dein Use Case speziell AI-Training ist, zielt diese Policy direkt auf dich — Lizenzierung oder ein deklarierter, konformer Weg ist die dauerhafte Antwort, nicht das Umgehen eines Blocks.

Das ist keine Rechtsberatung — siehe Ist Web Scraping 2026 legal? für die breitere Behandlung von öffentlichen vs. personenbezogenen Daten.

Quellen

Wo das reinpasst

Das ist die Policy-Ebene; für die Mechanik, wie man tatsächlich durch Cloudflare, DataDome und PerimeterX/HUMAN kommt — die Fingerprinting-Signale und das Eskalationsmuster, das zuverlässig funktioniert — siehe Scraping von Sites, die Bots blockieren. Für den Umfang dessen, was im Web bereits blockiert ist, siehe den Anti-Bot Index, Crawloras offenen Datensatz, der die Verbreitung von Bot-Abwehr über die Top-Sites hinweg trackt. Um ein breiteres Toolkit auszuwählen, siehe wie man eine Web Scraping API auswählt.

Zuerst kostenlos ausprobieren: Teste jede öffentliche URL mit dem Free Web Scraper, oder prüfe mit dem Anti-Bot Checker, ob eine Site Bots blockiert — ohne Anmeldung. Teste den Endpoint im Playground und wirf einen Blick auf die Preise.