Am 15. September 2026 ändert Cloudflare seine Standardeinstellungen für KI-Bots. Der Haken: Googlebot, BingBot und Applebot gelten bei Cloudflare gleichzeitig als Such- und als Trainings-Crawler. Wer Trainings-Bots blockt, blockt sie mit. In den Audits, die ich durchführe, ist das die stillste Art, aus Google zu verschwinden.
Die September-Frist, die die meisten Cloudflare-Nutzer übersehen haben
Seit dem 1. Juli 2026 gibt es bei Cloudflare keinen einfachen KI-an-oder-aus-Schalter mehr. An seine Stelle sind drei getrennt konfigurierbare Verhaltenskategorien getreten: Search, Agent und Training. Das klingt nach mehr Kontrolle – und ist es auch. Nur trägt diese Kontrolle eine Nebenwirkung, die viele erst bemerken, wenn Rankings bereits fallen.
Der eigentliche Stichtag ist der 15. September 2026. Cloudflare formuliert es so: „On September 15, 2026, we’ll be setting new defaults for each of these three classifications.“ Auf Seiten, die Werbung ausspielen, werden Training und Agent dann standardmäßig blockiert, während Search erlaubt bleibt.
Wichtig ist, für wen das automatisch gilt. Diese neuen Standards greifen ohne Zutun nur bei neuen Domains und bei neuen Sites, die bestehende Kunden hinzufügen. The Register fasst es identisch zusammen: „Starting September 15, 2026, new Cloudflare customers and new sites for existing customers will default to allowing search crawling but blocking training and agents from pages with ads.“ Wer heute schon Kunde ist, muss also aktiv etwas einstellen – und genau in diesem aktiven Eingreifen passieren die Fehler, die ich in Audits sehe.
Warum jetzt und nicht später? Cloudflare-CEO Matthew Prince begründet den Schritt offensiv: „Now that the majority of traffic on the Internet is non-human, we must go further and act faster so that a sustainable ecosystem can emerge.“ Das ist eine Positionsaussage, kein unabhängig geprüfter Messwert – aber sie erklärt, warum das Zeitfenster real und kurz ist.
Die drei Kategorien – und warum die Grenzen unschärfer sind als die Namen
Cloudflare definiert die drei Klassen nach Verhalten, nicht nach Firmennamen. Das ist der entscheidende Denkfehler, den es zu vermeiden gilt: Es geht nicht darum, welches Unternehmen crawlt, sondern was der Crawler mit Ihren Inhalten tut.
- Search – „any behavior that collects or indexes your content, so it can answer questions about it later.“ Das klassische Indexieren für Suchergebnisse.
- Agent – „automated behavior that is acting, usually in real time, on a person’s behalf, to get something done right now.“ Ein Assistent, der jetzt gerade in Ihrem Auftrag etwas nachschlägt.
- Training – „a crawler taking your content to train or fine-tune models. The key is that your data is permanently absorbed.“ Ihre Inhalte werden dauerhaft ins Modell aufgenommen.
Auf dem Papier saubere Trennlinien. In der Praxis nicht. Denn ein einzelner Bot kann mehrere dieser Verhalten in sich vereinen – und dann muss Cloudflare entscheiden, in welchen Topf er fällt, wenn Sie eine ganze Kategorie blocken.
Noch feiner wird es in Cloudflares eigener Bot-Referenz, die vier Buckets kennt. GPTBot, ClaudeBot, CCBot und Google-CloudVertexBot stehen unter „AI Crawlers“ (Training). OAI-SearchBot, Claude-SearchBot, PerplexityBot und Applebot stehen unter „AI Search“. ChatGPT-User, Claude-User und Perplexity-User laufen als „AI Assistant“. Und Googlebot sowie BingBot stehen separat unter „Traditional Search Engines“. Wer pauschal „KI-Bots“ blockt, greift schnell in alle vier Töpfe gleichzeitig.
Die Mixed-Purpose-Falle: Googlebot sitzt gefährlich in der Mitte
Hier liegt der Kern des Problems. Cloudflare benennt Googlebot, Applebot und BingBot ausdrücklich als Crawler mit gemischtem Zweck – sie indexieren für die Suche und sammeln zugleich Daten, die ins KI-Training fließen können. In Cloudflares Worten: Solche Crawler „will be blocked by customers who have selected to block Training“. Konkret heißt es im Post, dass unter diesen Bedingungen „Googlebot, Applebot, and BingBot will be blocked“.
Lesen Sie den Satz zweimal. Wenn Sie die Kategorie Training blockieren – aus dem völlig nachvollziehbaren Wunsch, Ihre Inhalte nicht ins nächste Sprachmodell einzuspeisen –, blockieren Sie mit derselben Einstellung den wichtigsten Suchmaschinen-Crawler der Welt. The Register beschreibt das Dilemma treffend: Publisher dulden Googlebot, „because they fear blocking could mean they disappear from Google Search results“.
„Verified Bot“ ist nicht mehr gleich „erlaubt“
Viele verlassen sich auf das „Verified bot“-Label und nehmen an, damit sei Googlebot sicher. Das galt früher: „all Verified bots were allowed by default.“ Cloudflare hat das strukturell geändert – „we are no longer viewing Verified as ‚default allowed.‘“ Verifiziert bedeutet jetzt nur noch, dass ein Bot innerhalb seiner Kategorie erlaubt werden darf: „the Verified label makes a bot allowable with its relevant category.“ Ein verifizierter Bot, dessen Kategorie Sie blocken, bleibt blockiert. Das ist die für Betreiber folgenreichste Änderung dieses Updates.
Wie eine WAF-Regel Ihren Crawl stumm abwürgt – noch vor robots.txt
Der zweite Grund, warum das so leicht unbemerkt bleibt, ist architektonisch. Eine Cloudflare-Sperre – ob per WAF-Regel oder Super Bot Fight Mode – feuert am Netzwerk-Rand, bevor der Crawler den Origin-Server erreicht. Das Search Engine Journal formuliert es klar: „a Cloudflare block operates at the network level, making it harder to bypass than a simple robots.txt line that Google can ignore.“
Der entscheidende Punkt: Die WAF-Regel greift, bevor robots.txt überhaupt gelesen wird. Nytro SEO bringt es auf den Punkt: „WAF rules are enforced before robots.txt is even accessed, so a WAF block overrides any robots.txt Allow directive.“ Ihre robots.txt kann Googlebot ausdrücklich einladen – wenn die WAF ihn vorher wegschickt, kommt diese Einladung nie an. Und in der Google Search Console erscheint kein robots.txt-Fehler, denn robots.txt war gar nicht die Ursache.
Zur Einordnung der Größenordnung: Cloudflare blockt nach eigenen Angaben (Stand des zitierten Blogposts) im Schnitt 336 Millionen Anfragen pro Tag allein für Self-Service-Kunden über Super Bot Fight Mode. Das ist keine Nischenfunktion, die selten zuschlägt – das ist eine Maschine, die permanent Traffic filtert. Wenn sie einen legitimen Such-Crawler erwischt, tut sie das leise.
Zwei getrennte Sperr-Ebenen, die sich widersprechen können
In Audits treffe ich immer wieder auf dieselbe Fehlannahme: dass robots.txt und Cloudflare irgendwie „miteinander reden“. Tun sie nicht. Es sind zwei unabhängige Ebenen, und eine Änderung an der einen berührt die andere nicht.
robots.txt ist ein Ehrensystem. Cloudflare sagt das selbst: „Adding an entry to your robots.txt file is the first step to telling AI bots not to crawl you. But robots.txt is an honor system. Nothing forces bots to follow it.“ Genau deshalb existiert die WAF-Ebene als härtere, technisch durchgesetzte Sperre. Pontara ergänzt für die neueren Content Signals: „Signals ≠ blocks … Combine signals with WAF/Bot Management or the AI Crawl Control feature to block, allow, or even return 402.“
Die praktische Konsequenz: Ihre robots.txt kann „Allow: Googlebot“ sagen, während eine WAF-Regel denselben Googlebot mit HTTP 1020 abweist. Beide Aussagen stehen nebeneinander, keine erzeugt eine Warnung, und keine korrigiert die andere. Der Widerspruch bleibt unsichtbar, bis Sie ihn gezielt suchen.
Das September-Audit in fünf Schritten
So gehe ich eine Cloudflare-Site durch, um festzustellen, ob Such-Crawler herausgefordert oder gedrosselt werden. Die Menüpfade sind Stand Juli 2026 – Cloudflare benennt Dashboard-Bereiche gelegentlich um, prüfen Sie also nach Funktion, nicht nur nach Beschriftung.
- Super Bot Fight Mode prüfen. Sehen Sie nach, ob „Definitely automated“ oder „Verified Bots“ auf Block oder Challenge stehen. Ein Challenge (CAPTCHA/JS) ist für einen Crawler faktisch eine Sperre – er löst es nicht.
- AI Crawl Control / Bot-Kategorien öffnen. Kontrollieren Sie, ob die Kategorie Training pauschal blockiert ist. Wenn ja, prüfen Sie, ob Googlebot, BingBot und Applebot als Mixed-Purpose mit erfasst werden.
- WAF Custom Rules durchgehen. Suchen Sie nach Regeln, die auf User-Agents oder Bot-Scores zielen. Achten Sie besonders auf breite Ausdrücke wie „alle Bots blocken außer …“, die Such-Crawler unbeabsichtigt einschließen.
- robots.txt gegen die WAF spiegeln. Vergleichen Sie, was robots.txt erlaubt, mit dem, was die WAF durchlässt. Widersprüche sind hier die Regel, nicht die Ausnahme.
- Mit dem echten User-Agent testen. Nutzen Sie die URL-Prüfung in der Search Console (Live-Test) und beobachten Sie, ob die Seite tatsächlich abgerufen wird – nicht nur, ob das Crawlen erlaubt wäre.
Die richtige Konfiguration: Training blocken, Suche schonen
Das Ziel ist präzise: reine Trainings-Crawler abweisen, ohne die gemischten Such-Crawler zu treffen. Auf robots.txt-Ebene sieht eine praxisnahe Trennung (angelehnt an eine Empfehlung aus dem Nytro-SEO-Leitfaden) so aus – wohlgemerkt als Signal, nicht als Durchsetzung:
# Erlauben – Suche und AI-Search-Retrieval
User-agent: Googlebot
User-agent: BingBot
User-agent: OAI-SearchBot
User-agent: PerplexityBot
User-agent: ChatGPT-User
Allow: /
# Blocken – reines Trainings-Sammeln
User-agent: GPTBot
User-agent: CCBot
User-agent: Google-Extended
User-agent: Applebot-Extended
Disallow: /Beachten Sie den Trick bei Google und Apple: Google-Extended und Applebot-Extended sind die reinen Trainings-Tokens. Über sie sagen Sie „kein Training“, ohne den Such-Crawler Googlebot beziehungsweise Applebot anzurühren. Das ist genau die Trennung, die die Mixed-Purpose-Falle entschärft.
Weil robots.txt nur ein Signal ist, gehört auf der WAF-Ebene die eigentliche Durchsetzung dazu. Eine illustrative Trennung (Ausdrücke Stand Juli 2026, Feldnamen im Dashboard verifizieren):
# Regel 1 (höhere Priorität): Such-Crawler durchlassen
# Action: Skip (überspringt weitere Custom Rules + Cloudflare-Dienste)
(http.user_agent contains „Googlebot“)
or (http.user_agent contains „bingbot“)
or (http.user_agent contains „OAI-SearchBot“)
or (http.user_agent contains „PerplexityBot“)
# Regel 2 (niedrigere Priorität): reine Trainings-Crawler blocken
# Action: Block
(http.user_agent contains „GPTBot“)
or (http.user_agent contains „CCBot“)
or (http.user_agent contains „ClaudeBot“)
or (http.user_agent contains „Bytespider“)Wichtig zum Super Bot Fight Mode: Sie können ihn nicht per WAF-Ausdruck umkonfigurieren – „the mode itself cannot be customized or reconfigured via WAF custom rules.“ Der dokumentierte Weg ist eine höher priorisierte Skip-Regel. Cloudflare beschreibt die Skip-Aktion so: „Rules that ‚skip‘ traffic can skip the rest of your custom rules (just like an ‚allow‘ rule would) and other Cloudflare services.“ Genau deshalb steht die Such-Crawler-Regel oben.
Die GEO- und AEO-Dimension: blockieren Sie gerade Ihre KI-Zitate weg?
Es gibt eine zweite, gegenläufige Falle. Wer aus Reflex „alle KI-Bots“ blockt, trifft nicht nur Trainings-Crawler, sondern auch die AI-Search- und Agent-Bots – und die sind die Pipeline in KI-Antworten. OAI-SearchBot, Claude-SearchBot und PerplexityBot speisen die Live-Recherche von ChatGPT Search, Claude und Perplexity. Fallen sie weg, verschwindet Ihre Chance, in KI-generierten Antworten zitiert zu werden.
ALM Corp beschreibt das für Anthropics Crawler konkret: „blocking Claude-SearchBot prevents Anthropic from indexing your content for this search optimization system“, und die „visibility and accuracy in user search results“ nehme ab. Das ist die Kehrseite der Trainings-Sperre: Training-Blocken schützt Ihre Inhalte, Agent-Blocken schneidet Sie von der KI-Zitierbarkeit ab. Beides sind Entscheidungen, keine Standardeinstellungen, die man laufen lässt.
Die Abwägung ist keine Ideologie, sondern eine Datenfrage: Wenn Sie nicht messen, welche KI-Systeme Ihre Marke heute zitieren, entscheiden Sie im Blindflug. Wir haben Cited genau dafür gebaut – es verfolgt in Echtzeit, wie ChatGPT, Claude, Perplexity, Gemini und die Google AI Overviews eine Marke und ihre Wettbewerber beschreiben, und macht sichtbar, ob eine Bot-Sperre Ihre Zitierhäufigkeit gerade nach unten zieht.
Diese Woche: was Sie auf jeder Cloudflare-Site prüfen sollten
Wenn Sie mehrere Sites betreuen, ist das eine Aufgabe von wenigen Minuten pro Domain – und sie lohnt sich vor dem 15. September. Der Grund, warum es dringt: Der Schaden kommt nicht als lauter Alarm. TechSEO Vitals beschreibt den Verlauf: „Once Cloudflare starts blocking or challenging requests from Google, it will slowly begin deindexing your pages one by one.“ Seite für Seite, nicht über Nacht. Bis Rankings fallen, ist oft schon einiges weg.
Die eine Metrik, die verrät, ob Sie bereits ein Problem haben: In der URL-Prüfung der Search Console ist es die Kombination „Crawling zulässig? Ja“ gemeinsam mit „Seitenabruf fehlgeschlagen“. Kwebby beschreibt dasselbe Muster: „URL Inspection shows Crawl allowed? Yes but Page fetch failed.“ Das bedeutet: robots.txt hat den Crawl erlaubt (Status 200), aber der eigentliche Seitenabruf scheiterte – der Fingerabdruck einer Sperre auf Firewall-Ebene, nicht per Direktive.
Ergänzend achten Sie auf diese Signale, die auf eine Cloudflare-Sperre statt auf robots.txt deuten:
- In der GSC-Abdeckung: „Blockiert wegen Zugriffsverbot (403)“ oder „Blockiert wegen eines anderen 4xx-Problems“.
- Von Cloudflare zurückgegebene Codes: HTTP 1020 (Access Denied, meist eine Firewall-Regel) oder 403 (meist WAF/Bot).
- Ein robots.txt-Status „Nicht abgerufen“ (kein 404) – laut IndexMachine ein Hinweis, dass Cloudflare schon den Zugriff auf die robots.txt selbst sperrt.
- Der Erfolgsindikator nach der Korrektur: „a decrease in 403 errors and an increase in 200 responses“.
Wenn Sie den Verdacht haben, dass eine Ihrer Sites betroffen ist, aber die Log- und WAF-Analyse nicht selbst stemmen wollen: Unser KI-Sichtbarkeits-Audit prüft genau diese Ebenen – Netzwerk-Sperre, robots.txt-Widerspruch und KI-Zitierbarkeit – als Festpreisleistung. Und wenn Sie lieber vorher sprechen möchten, erreichen Sie uns über Kontakt.