Cloudflare KI-Crawler-Regeln: Sperrt dein Blocker bald Google aus?

Cloudflare nennt in seiner eigenen Ankündigung vom 1. Juli 2026 drei Bots namentlich, die ab dem 15. September von den eigenen Kunden ausgesperrt werden können: Googlebot, Applebot und Bingbot. Nicht von Angreifern. Nicht von Konkurrenten. Von den Website-Betreibern selbst – über einen Schalter, den viele vor Monaten gesetzt und längst vergessen haben.

Der Hintergrund: Cloudflare hat die Steuerung von KI-Crawlern grundlegend umgebaut. Statt der bisherigen Pauschal-Option „Block AI bots“ gibt es jetzt drei Kategorien – Search, Agent und Training. Und ab dem 15. September 2026 gilt laut Cloudflare für Mehrzweck-Crawler, die sowohl für die Suche als auch fürs KI-Training sammeln, die restriktivste zutreffende Regel. Googlebot nennt Cloudflare selbst als Beispiel für so einen Mehrzweck-Crawler.

Jedes Mal, wenn ein neuer KI-Bot durchs Netz geistert, sitzt kurz darauf ein Kunde bei mir und fragt, ob wir ihn wegsperren sollen – seit 2024 gehört diese Frage in jedes zweite technische Audit, das ich bei SEO Kreativ mache. Die Antwort war bisher relativ risikofrei: Der KI-Block traf GPTBot, ClaudeBot und Co., die Google-Suche blieb unberührt. Genau diese saubere Trennung hebt Cloudflare jetzt teilweise auf. Wer bei einem Cloudflare-Kunden pauschal „KI blockieren“ aktiviert hat, sollte vor dem 15. September wissen, was dieser Schalter ab dann bedeutet.

In diesem Beitrag zerlege ich die Ankündigung entlang der Primärquelle: was exakt neu ist, wer betroffen ist (und wer nicht – ein Punkt, der in ersten Meldungen leicht durcheinandergeht), wie du dein Setup in zehn Minuten prüfst und was der neue use=-Parameter in den Content Signals für deine robots.txt bedeutet.

Die Ankündigung lief unter dem Label „Content Independence Day“, Cloudflares jährlichem Termin für Crawler-Politik, ein Jahr nach der Einführung des Ein-Klick-Schalters „Block AI Bots“ und des Pay-per-Crawl-Programms. Die Kernaussage im offiziellen Blogpost (Jin-Hee Lee und Bryan Becker, 01.07.2026): Nicht jede KI-Nutzung ist gleich, also braucht es differenzierte Kontrollen.

Die drei Kategorien, wie Cloudflare sie definiert:

Wichtig für die Einordnung: Das ist eine Verhaltens-Taxonomie, keine Firmen-Taxonomie. Ein Bot kann in mehreren Kategorien gleichzeitig geführt werden – und genau dieses Detail wird ab September relevant. Cloudflare klassifiziert daneben noch weitere Verhaltensweisen, steuerbar für alle Kunden sind zunächst aber die drei KI-Kategorien.

Parallel hat Cloudflare die Bedeutung von „Verified Bots“ umdefiniert: Verifiziert zu sein heißt künftig nur noch, dass die Identität eines Bots bestätigt ist – nicht mehr, dass er automatisch durchgelassen wird. Ob ein verifizierter Bot Zugriff bekommt, entscheidet seine Kategorie plus deine Einstellungen.

Hier lohnt der genaue Blick in die Primärquelle, denn die beiden Änderungen haben komplett unterschiedliche Reichweiten:

Änderung 1 – die neuen Defaults (nur neue Domains): Für alle Domains, die ab dem 15. September 2026 neu zu Cloudflare onboarden, werden die Kategorien Training und Agent auf Seiten mit Werbung standardmäßig geblockt, Search bleibt erlaubt. Cloudflares Begründung: Werbung signalisiert, dass ein Mensch die Seite sehen soll – Bots, die diese menschliche Aufmerksamkeit ersetzen, werden dort ferngehalten. Bestehende Zonen mit unveränderten Einstellungen sind von diesem Default-Teil laut Blogpost nicht erfasst; die Formulierung lautet ausdrücklich „for all new domains onboarding to Cloudflare“.

Änderung 2 – die Mehrzweck-Regel (alle, die Training blocken): Ab demselben Stichtag werden Crawler, die Search und Training kombinieren, nach allen ihren Verhaltensweisen bewertet – und es greift die restriktivste zutreffende Regel. Cloudflare schreibt wörtlich, dass Mehrzweck-Crawler wie Googlebot, Applebot und Bingbot von Kunden geblockt werden, die Training blockieren – egal ob über die neuen Kategorien-Optionen oder über den Legacy-Schalter „Block AI bots“.

Das ist die eigentliche Nachricht für SEOs. Der alte Ein-Klick-Schalter war bisher die bequeme, risikoarme Empfehlung: KI-Trainings-Bots raus, Suche bleibt unberührt. Ab dem 15. September ändert derselbe Schalter seine Wirkung – ohne dass du ihn anfasst. Aus „blockt GPTBot und Co.“ wird potenziell „blockt auch Googlebot auf den konfigurierten Seiten“. Auch Search Engine Journal hebt genau diesen Punkt als zentrale SEO-Konsequenz hervor. Wie technisch granular Cloudflare Googlebot am Ende einordnet und wie scharf die Blockade tatsächlich greift – etwa nur auf bestimmten Seiten oder Signalen -, muss sich in der Praxis ab dem Stichtag erst zeigen.

Eine offene Flanke bleibt – und hier trenne ich sauber nach Evidenzstatus: Belegt ist, dass Cloudflare Bot-Betreiber auffordert, ihre Crawler nach Zwecken zu trennen. Spekulation ist, ob Google das tut. Google crawlt für Suche und KI-Features nach eigener Dokumentation seit jeher primär mit Googlebot; das separate Token Google-Extended steuert laut Google-Doku nur das Gemini-Training, nicht die Suche. Ob Google seine Crawler-Architektur wegen Cloudflare aufspaltet, ist offen – bereits bei den Content Signals im September 2025 hatte sich Google laut Search Engine Land nicht dazu bekannt, die Signale zu respektieren.

Die Matrix, die ich gerade für meine eigenen betreuten Cloudflare-Zonen durchgehe:

Ein Muster wird hier gefährlich, das ich aus meiner Arbeit als Product Developer bei iGaming.com genauso kenne wie aus kleinen WordPress-Setups: Security-Einstellungen werden einmal beim Setup gesetzt – oft von der IT, nicht vom SEO-Team – und danach nie wieder angefasst. Der „Block AI bots“-Schalter war 2025 in vielen Setups ein Selbstläufer, weil er risikofrei wirkte. Genau diese Setups sind jetzt die Kandidaten für unbeabsichtigte Googlebot-Blocks. Wenn SEO- und Security-Verantwortung in deinem Unternehmen getrennt sind: Dieser Stichtag ist der Anlass, beide an einen Tisch zu holen.

Zur Größenordnung: Cloudflare gibt an, vor mehr als 20 Prozent aller Web-Domains zu sitzen (laut Cloudflare-Angaben, nicht unabhängig verifiziert). Selbst wenn nur ein Bruchteil davon Training-Blocking aktiv hat, reden wir über eine relevante Menge an Domains, deren Google-Crawling sich am 15. September ändern kann.

Schritt 1 – Dashboard-Check. Laut Cloudflare-Doku findest du die Einstellung nach aktueller Cloudflare-Doku im Application-Security-Dashboard unter den Security Settings, Filter „Bot traffic“, Eintrag „Block AI bots“ (die genauen Bezeichnungen können sich im Dashboard kurzfristig ändern). Dort siehst du eine von mehreren Konfigurationen, unter anderem „Only block on hostnames with ads“, „Block on all pages“ oder den Aus-Zustand. Steht dort etwas anderes als „off“, bist du ab dem 15. September von der Mehrzweck-Regel betroffen. Prüfe außerdem die neuen Kategorie-Presets für Search, Agent und Training, die seit dem 1. Juli in denselben Settings verfügbar sind.

Schritt 2 – Entscheidung treffen. Du hast drei sinnvolle Optionen, je nach Content-Strategie:

• Option A – Opt-out setzen: Du willst weiterhin Trainings-Bots blocken, aber Googlebot und Co. unangetastet lassen. Dann setz vor dem 15. September das Opt-out in den Security Settings. Damit bestätigst du laut Cloudflare, dass sich für Trainings-Crawler mit Search-Funktion nichts ändert.
• Option B – die neue Logik bewusst akzeptieren: Wenn deine Inhalte primär über andere Kanäle monetarisieren und du die Verhandlungsposition gegenüber Google stärken willst, kannst du die Mehrzweck-Regel greifen lassen – im vollen Bewusstsein, dass das Google-Crawling der konfigurierten Seiten dann geblockt wird. Für die meisten Publisher- und E-Commerce-Setups, die ich betreue, ist das aktuell keine realistische Option.
• Option C – differenzieren: Training nur auf werbefinanzierten Seiten blocken („Only block on hostnames with ads“) und beobachten, wie sich das Crawling entwickelt.

Schritt 3 – robots.txt gegenprüfen. Wenn du Cloudflares Managed robots.txt nutzt, injiziert Cloudflare Direktiven vor deinen eigenen Inhalt. Ruf deine robots.txt einmal frisch ab (mit Cache-Buster) und prüfe, was tatsächlich ausgeliefert wird. Wie die Direktiven-Logik grundsätzlich funktioniert und welche Fehler du dabei vermeiden solltest, habe ich in meinem robots.txt-Guide ausführlich aufgeschrieben.

Schritt 4 – nach dem Stichtag messen. Beobachte ab Mitte September die Crawling-Statistiken in der Search Console (Einstellungen, Crawling-Statistiken) und deine Server-Logs auf Googlebot-Aktivität. Ein plötzlicher Einbruch der Crawl-Requests bei unverändertem Content ist das Warnsignal. Für die KI-Sichtbarkeits-Seite lohnt parallel der Blick in die neuen GenAI-Performance-Reports der Search Console, sofern deine Property den Rollout schon hat.

Neben der WAF-Ebene (echtes Blocking) baut Cloudflare die Signal-Ebene aus. Die Content Signals, im September 2025 eingeführt, kannten bisher drei Felder: search, ai-input und ai-train. Neu ist das Feld use mit drei Stufen, von restriktiv nach permissiv:

• use=immediate – interagieren, aber nichts speichern und wiederverwenden.
• use=reference – indexieren, Auszüge zeigen, zurückverlinken (der Default).
• use=full – zusammenfassen und reproduzieren erlaubt.

Kunden mit aktivierter Managed robots.txt bekommen die neue Präferenz nach Cloudflare-Angaben automatisch ergänzt. Die konkrete Ausgabe kann je nach Konfiguration variieren; nach aktueller Cloudflare-Dokumentation sieht die Direktive etwa so aus:

# Cloudflare Managed content mit dem neuen content-use Signal

User-agent: *
Content-Signal: search=yes,ai-train=no,use=reference
Allow: /

Zwei Einordnungen dazu. Erstens: Content Signals sind Präferenzen, keine Durchsetzung – Crawler können sie ignorieren. Cloudflare koppelt sie deshalb an ein Anreizsystem: Verhalten wird getrackt, und verifizierte Bots, die deklarierte Nutzungsregeln missachten oder Inhalte vollständig reproduzieren, sollen ihren Verified-Status verlieren – und damit den Zugang zu einem erheblichen Teil des Cloudflare-Netzwerks. Ob dieser Hebel in der Praxis diszipliniert, wird sich zeigen müssen.

Zweitens, ein Praxis-Detail: Die Google Search Console kann für Content Signals und neuere Direktiven gelegentlich „Syntax nicht verstanden“ melden. Laut Cloudflare wurde dadurch bisher kein Einfluss auf Crawling-Raten oder SEO beobachtet – das ist allerdings eine Eigenaussage des Anbieters, keine unabhängige Messung. Wenn dir die Meldung in der GSC begegnet: erst einordnen, dann handeln.

Wo sich das strategisch einsortiert – zwischen robots.txt, llms.txt und den KI-Sichtbarkeits-Disziplinen – habe ich im Pillar zu SEO, AIO, GEO und LLMO ausführlich behandelt. Kurzfassung: Die Signal-Ebene wächst, aber die Durchsetzungs-Ebene bleibt WAF und Bot-Management.

Cloudflares Argument fußt auf eigenen Netzwerkdaten: Nach der Cloudflare-Analyse vom Juli 2025 lag das Verhältnis von Crawls zu zurückgeschickten Besuchern bei Google bei rund 14:1, bei OpenAI bei etwa 1.700:1 und bei Anthropic bei rund 73.000:1 (Cloudflare-eigene Messung, Juli 2025). Der alte Deal „Crawling gegen Traffic“ trägt bei diesen Größenordnungen für KI-Antworten erkennbar nicht mehr. Die Mehrzweck-Regel ist Cloudflares Versuch, diesen Deal neu zu verhandeln: Wer als Bot-Betreiber weiter Zugang will, soll transparent machen, wofür er crawlt – idealerweise mit getrennten Crawlern pro Zweck.

Das Kalkül dahinter formuliert Cloudflare offen: Die Bündelung von Suche und Training im selben Bot verschafft etablierten Suchanbietern einen Vorteil, weil Website-Betreiber die Suche nicht opfern können, um das Training zu verweigern. Genau diese Zwangslage soll die Mehrzweck-Regel aufbrechen. Ob Google mitspielt, ist die offene Frage – eine kurzfristige Crawler-Trennung halte ich für unwahrscheinlich (Spekulation), weil Google damit ein zentrales Druckmittel aus der Hand geben würde. Realistischer erscheint mir ein längeres Patt, in dem einzelne Publisher-Gruppen die Blockade testen und Google die Auswirkungen zunächst aussitzt.

Meine Einschätzung dazu: „KI blockieren“ wird noch viel zu oft als rein defensive Security-Entscheidung behandelt. Das greift ab jetzt zu kurz – es ist eine Sichtbarkeits- und Monetarisierungs-Entscheidung. Wer blockt, verzichtet auf KI-Zitierungen und potenziell, ab dem Stichtag, auf Google-Crawling der betroffenen Seiten. Wer öffnet, liefert Trainingsdaten ohne direkte Vergütung, solange Systeme wie Cloudflares Pay-per-Crawl-Ansatz nicht breit greifen. Es gibt hier keine Default-Antwort, sondern nur eine bewusste Abwägung pro Geschäftsmodell.

Die Richtung stimmt: Search, Agent und Training getrennt steuern zu können ist genau die Granularität, die in meinen Audits seit zwei Jahren gefehlt hat. Dass Cloudflare die Kontrollen bis in den Free-Tarif ausrollt, macht sie zum neuen Standard-Werkzeug – auch für kleine Sites, die bisher nur die robots.txt hatten. Gleichzeitig ist der 15. September ein Stichtag, den du nicht dem Zufall überlassen solltest. Die Änderung an der Mehrzweck-Logik passiert serverseitig bei Cloudflare; dein Schalter bleibt gleich, seine Wirkung nicht.

Mein Vorgehen für die kommenden Wochen: Baseline dokumentieren, Dashboard-Check bei jeder betreuten Cloudflare-Zone, Entscheidung pro Projekt festhalten – und ab Mitte September die Crawling-Statistiken engmaschig beobachten. Sollte sich zeigen, dass Google auf die Zweck-Trennung reagiert, wäre das eine der größeren Verschiebungen im Crawler-Ökosystem seit Jahren. Bis dahin gilt: Präferenzen signalisieren, Durchsetzung konfigurieren, Wirkung messen.