Cloudflare blockiert KI-Crawler standardmäßig: Was das für deine Website bedeutet
Cloudflare hat KI-Crawler im Juli 2025 auf deny-by-default umgestellt und setzt am 15. September 2026 neue Standards für Werbeseiten. Was sich geändert hat, was es dich an KI-Zitationen kostet und wie du die Crawler erlaubst und verifizierst, die du wirklich willst.
Wenn deine Domain nach dem 1. Juli 2025 zu Cloudflare gekommen ist, sind KI-Crawler sehr wahrscheinlich blockiert, und niemand hat dir eine Benachrichtigung geschickt. Cloudflare stellte neue Domains an diesem Tag auf deny-by-default um, ergänzte im September 2025 ein robots.txt-Vokabular für die Nutzung von Inhalten, und ab dem 15. September 2026 blockiert es Training- und Agent-Traffic standardmäßig auf Seiten mit Werbung. Die richtige Reaktion ist nicht, alles wieder einzuschalten. Sie besteht darin, die gewünschten Crawler namentlich auszuwählen und anschließend zu prüfen, ob die Requests, die diese Namen tragen, echt sind.
Was Cloudflare wirklich geändert hat, und wann
1. Juli 2025. Cloudflare rief den Content Independence Day aus und wurde der erste große Infrastrukturanbieter, der KI-Crawler standardmäßig blockiert. Die Pressemitteilung dieses Tages beschrieb die Umstellung nüchtern: Neue Domains im Netzwerk verweigern den Zugriff von KI-Crawlern, sofern der Inhaber ihn nicht ausdrücklich freigibt. Aus Opt-out wurde Opt-in. Cloudflare beziffert seinen eigenen Anteil am Web-Traffic auf rund 20 Prozent, eine einzige Standardänderung bewegte also einen großen Teil des Webs auf einmal. Mehr als eine Million bestehender Kunden hatten die Ein-Klick-Blockade seit September 2024 ohnehin schon aktiviert. Parallel startete Pay Per Crawl als Beta, womit Inhaber einem Crawler statt Inhalten ein HTTP 402 Payment Required zurückgeben können.
Cloudflares Argument war ein Verhältnis. Gemessen am Traffic im Juni 2025 lag das Verhältnis von Crawls zu Referrals bei 1.700:1 für OpenAI und 73.000:1 für Anthropic, gegenüber 14:1 bei der Google-Suche. Enorm viel Abrufen, sehr wenig Traffic zurück.
28. August 2025. Aus der AI-Audit-Beta wurde AI Crawl Control mit allgemeiner Verfügbarkeit: eine Ansicht pro Crawler, wer was abgerufen hat, Allow- und Block-Schalter je Betreiber und eigene 402-Antworten in kostenpflichtigen Tarifen.
24. September 2025. Cloudflare veröffentlichte die Content Signals Policy unter CC0, mit einem Generator auf ContentSignals.org. Sie ergänzt die robots.txt um eine Zeile, die beschreibt, wie Inhalte nach dem Abruf verwendet werden dürfen, was robots.txt nie abgedeckt hat. Drei Signale, jeweils auf yes, no oder ohne Angabe:
User-Agent: *
Content-Signal: search=yes, ai-train=no
Allow: /
Cloudflare schrieb diese Policy für mehr als 3,8 Millionen Domains in die verwaltete robots.txt. Wo
Training bereits blockiert war, lautete der veröffentlichte Standard search=yes, ai-train=no, wobei
ai-input bewusst offen gelassen und nicht verweigert wurde.
1. Juli 2026. Cloudflare teilte Bot-Verhalten in drei Klassifizierungen auf und machte sie allen
Kunden inklusive Free-Tier zugänglich: Search (Inhalte sammeln und indexieren, um später Fragen zu
beantworten), Agent (in Echtzeit im Auftrag einer Person handeln) und Training (Inhalte übernehmen,
um ein Modell zu trainieren oder feinzutunen). Dazu kam ein Datum. Am 15. September 2026 bleibt
Search standardmäßig erlaubt, während Training und Agent auf Seiten mit Werbung standardmäßig
blockiert werden. Diese Standards gelten für Neukunden, für neue Sites bestehender Kunden und für
Free-Plan-Konten, die die Einstellung bis zum Stichtag nicht geändert haben. Ein Crawler, der
mehrere Zwecke vermischt, ohne sie zu trennen, wird nach der restriktivsten Regel behandelt, die auf
eines seiner Verhalten zutrifft. Content Signals erhielt einen vierten Parameter, use=, mit den
Werten immediate, reference und full. Und aus Pay Per Crawl wurde Pay Per Use, das bezahlt,
wenn Inhalte tatsächlich in einer Antwort auftauchen, statt wenn ein Bot eine Seite abruft. Erste
Partner sind Ceramic.ai und You.com.
| Steuerung | Wo sie sitzt | Was sie tatsächlich tut |
|---|---|---|
| Verwaltete robots.txt | Cloudflare-Dashboard, kostenlos | Veröffentlicht eine Bitte. Konforme Crawler befolgen sie, andere ignorieren sie |
Content Signals (search, ai-input, ai-train, use) | Zeile in der robots.txt | Nennt erlaubte Verwendungen nach dem Abruf. Weiterhin eine Bitte, keine Sperre |
| Block-AI-Bots-Schalter | Security-Einstellungen | Durchsetzung an der Edge. Breit und grob |
| AI Crawl Control | Eigenes Dashboard | Allow, Block oder 402 pro Crawler, durchgesetzt bevor dein Origin den Request sieht |
| Standards für Search / Agent / Training | Gilt ab 15. September 2026 | Durchsetzung auf Kategorieebene, zuerst auf Werbeseiten |
| Pay Per Use | Opt-in-Programm | Bezahlung, wenn deine Inhalte in einer Antwort erscheinen |
Die Kosten, die in deiner Analytics nie auftauchen
Ein blockierter Crawler erzeugt keine Fehlerseite, die du je ansehen würdest. Keine Bounce, kein 500, kein Support-Ticket. Der Assistent antwortet einfach aus der Seite von jemand anderem, und du merkst es Monate später, wenn ein Wettbewerber zitiert wird.
Das wiegt jedes Quartal schwerer. Cloudflares eigener Beitrag zur Answer Engine Optimisation vom 6. August 2026 hielt fest, dass weniger als die Hälfte aller HTML-Seitenaufrufe noch von einem Menschen stammt. Wenn Retrieval-Bots deine Dokumentation, deine Preisseite oder deine Vergleichsinhalte nicht erreichen, fehlst du in dem Quellenpool, aus dem Antwortmaschinen schöpfen. Einen Training-Crawler zu blockieren und einen Retrieval-Crawler zu blockieren fühlt sich im Dashboard wie derselbe Schalter an. Es ist nicht dieselbe Entscheidung, und nur eine davon schützt etwas, das dir wichtig ist.
Der Unterschied, den man verinnerlichen sollte: Training-Crawler nehmen deine Inhalte einmal mit und geben pro Request nichts zurück. Retrieval- und Agent-Traffic ist ein Leser, der gerade jetzt mit einer Frage ankommt. GPTBot trainiert. OAI-SearchBot indexiert für Antworten. ChatGPT-User ruft eine Seite ab, weil vor dreißig Sekunden eine Person danach gefragt hat. Dasselbe Unternehmen, drei Tokens, drei sehr unterschiedliche Geschäfte.
robots.txt ist eine Bitte. Die Edge ist eine Entscheidung.
Diese Grenze verwischen die meisten Website-Betreiber. Disallow: / in der robots.txt ist ein Hinweis
an der Tür. Seriöse Betreiber lesen ihn und drehen um. Alle anderen lesen ihn als Liste interessanter
Pfade, oder lesen ihn gar nicht. Content Signals gehört in dieselbe Kategorie: eine klare,
maschinenlesbare Absichtserklärung, deren Wert eher juristisch und sozial als technisch ist.
Cloudflares Steuerung sitzt eine Ebene tiefer. Der Request wird an der Edge abgelehnt, bevor dein Origin ihn sieht, unabhängig davon, was der Client über robots.txt dachte. Das ist wirklich nützlich, und genau deshalb wiegt der Standard so schwer. Eine Präferenz, die du nie geäußert hast, wird jetzt in deinem Namen durchgesetzt.
Die praktische Konsequenz: Deine robots.txt und deine Edge-Regeln müssen dasselbe sagen. Eine Site,
die Allow: / für PerplexityBot veröffentlicht, während Cloudflare ihn an der Edge blockiert, sendet
einem Betreiber, der Compliance misst, eine widersprüchliche Botschaft.
Prüfe, zu welchem Netzwerk eine Crawler-IP wirklich gehört
Erlaube die gewünschten Crawler über den exakten Token
Matche nicht auf den Teilstring "bot". Matche nicht auf "GPT". Erlaube konkrete Tokens, denn die Tokens tragen den Zweck:
| Crawler | Zweck | Wie er sich verifizieren lässt | Unter den Werbeseiten-Standards ab 15. September |
|---|---|---|---|
| GPTBot | Modelltraining für OpenAI | Veröffentlichte IP-Range-Datei | Training-Verhalten, blockiert auf Werbeseiten |
| OAI-SearchBot | Indexierung für ChatGPT-Suchergebnisse | Veröffentlichte IP-Range-Datei | Search-Verhalten, bleibt erlaubt |
| ChatGPT-User | Live-Abruf, ausgelöst durch einen Nutzer-Prompt | Veröffentlichte IP-Range-Datei | Agent-Verhalten, blockiert auf Werbeseiten |
| PerplexityBot | Indexierung für Perplexity-Antworten | Veröffentlichte IP-Range-Datei | Search-Verhalten, bleibt erlaubt |
| Perplexity-User | Live-Abruf im Auftrag einer Person | Veröffentlichte IP-Range-Datei | Agent-Verhalten, blockiert auf Werbeseiten |
| ClaudeBot | Modelltraining für Anthropic | Veröffentlichte IP-Range-Datei | Training-Verhalten, blockiert auf Werbeseiten |
| Google-Extended | Nur Opt-out-Token fürs Training, crawlt nie | robots.txt-Token, kein eigener Traffic | Steuert Trainingsnutzung, nicht den Zugriff |
| CCBot | Datensammlung für Common Crawl | Keine veröffentlichten Ranges oder DNS-Konvention | Training-Verhalten, blockiert auf Werbeseiten |
| Bytespider | Sammlung durch ByteDance | Keine veröffentlichte Verifizierungsmethode | Training-Verhalten, blockiert auf Werbeseiten |
Cloudflares eigene Klassifizierung pro Bot ist das, was seine Durchsetzung verwendet. Prüfe also AI Crawl Control, bevor du eine Zuordnung annimmst. Unser KI-Crawler-Verzeichnis führt die exakten User-Agent-Tokens, Betreiber, veröffentlichten IP-Range-Dateien und das robots.txt-Verhalten von 150 Agents, und genau das brauchst du, um Regeln zu schreiben, die nicht versehentlich den falschen Bot treffen.
Google-Extended ist das klarste Beispiel dafür, warum Tokens zählen. Es sendet nie einen Request. Es existiert nur, damit du der Trainingsnutzung widersprechen kannst, während Googlebot dich normal weiter indexiert. An der Edge zu blockieren bringt hier nichts, weil es dort nichts zu blockieren gibt.
Danach prüfen, was tatsächlich ankommt
GPTBot per User-Agent zu erlauben heißt, alles zu erlauben, was GPTBot in einen Header tippt.
Scraper wissen das seit Jahren, und eine Allowlist auf Basis von Strings ist eine Einladung. Hinter
jeder Allow-Regel braucht es einen Verifizierungsschritt.
Die meisten großen KI-Betreiber veröffentlichen inzwischen JSON-Dateien mit IP-Ranges, und die älteren Suchcrawler unterstützen forward-confirmed Reverse DNS. Die Methode unterscheidet sich je Betreiber, was genau der lästige Teil ist: Googlebot und Bingbot lösen auf, GPTBot und PerplexityBot veröffentlichen Ranges, Bytespider und CCBot veröffentlichen nichts Prüfbares. Siehe Googlebot verifizieren für das Reverse-DNS-Muster im Detail.
Wo sich ein behaupteter Crawler nicht verifizieren lässt, greifen die üblichen Ersatzsignale: Ist die Adresse eine Datacenter-Range, die nicht dem angeblichen Betreiber gehört, passt der TLS-Fingerprint zum behaupteten Client, sind die Header konsistent. Agentscan macht das pro Request, bestätigt verifizierte Crawler forward-confirmed, gleicht veröffentlichte Ranges ab und verbindet IP-Herkunft mit JA4 und Headless-Merkmalen, um Mensch, bekannten Bot, KI-Agent oder schädliche Automatisierung zurückzugeben. Verdicts werden gecacht, wiederholte Prüfungen kommen in unter 50ms zurück.
Fazit
Cloudflare hat den Standard zweimal verschoben, und die zweite Verschiebung greift am 15. September 2026. Prüfe, worauf deine Zone jetzt eingestellt ist, statt anzunehmen, wie sie eingestellt sein müsste. Entscheide getrennt über Training, Retrieval und Agent-Traffic, denn diese drei in einen Schalter zu pressen ist genau das, was dich unbemerkt aus KI-Antworten entfernt. Veröffentliche deine Absicht mit Content Signals in der robots.txt, setze die passende Policy an der Edge durch, erlaube die gewünschten Crawler über den exakten Token und verifiziere jeden einzelnen gegen veröffentlichte Ranges oder Reverse DNS statt gegen einen Header, den jeder tippen kann.
FAQ