30. Juli 2026
Der Schalter, der Google aussperrt: was am 15. September 2026 bei Cloudflare passiert
Cloudflare trennt KI-Crawler seit dem 1. Juli in Search, Agent und Training. Ab dem 15. September gilt für Bots mit mehreren Zwecken die schärfste Regel — und Googlebot ist so ein Bot.
Es gibt eine Sorte Konfiguration, die man einmal setzt und dann vergisst: einen Haken in einem Security-Dashboard. Genau so einer wird am 15. September 2026 seine Wirkung ändern, ohne dass ihn jemand anfasst. Wer bei Cloudflare irgendwann «Block AI bots» eingeschaltet hat, sollte vor diesem Datum nachsehen — sonst sperrt er unter Umständen Googlebot aus.
Das ist die Schlagzeile, und sie ist nicht falsch. Sie ist nur die kleinere Hälfte der Geschichte. Die grössere ist, dass die meisten Anleitungen zu diesem Thema an vier Stellen sachlich nicht stimmen — und dass ein guter Teil der Massnahmen, die dort empfohlen werden, überhaupt nichts bewirkt.
Was Cloudflare am 1. Juli geändert hat
Die pauschale Option «Block AI bots» ist durch drei Kategorien ersetzt worden, verfügbar auf allen Tarifen einschliesslich dem kostenlosen. Cloudflare definiert sie so: Search ist jedes Verhalten, das Inhalte sammelt oder indexiert, um später Fragen darüber zu beantworten. Agent ist automatisiertes Handeln in Echtzeit im Auftrag einer Person. Training ist ein Crawler, der Inhalte holt, um ein Modell zu trainieren oder nachzujustieren. Je Kategorie gibt es drei Optionen: auf allen Seiten blocken, nur auf Seiten mit Anzeigen blocken, oder nicht blocken.
Das ist ein echter Fortschritt gegenüber einem Sammelschalter. Wer bisher «KI-Bots» blockte, blockte pauschal etwas, das er nie sauber trennen konnte. Jetzt geht die Trennung — im Bot-Management.
Was am 15. September passiert — und was daran unklar ist
Zwei Dinge ändern sich, und sie werden regelmässig in einen Topf geworfen. Erstens gelten für neu aufgenommene Domains neue Voreinstellungen: Search erlaubt, Training und Agent auf Seiten mit Anzeigen geblockt. Zweitens werden Bots mit mehreren Zwecken nach der schärfsten zutreffenden Regel behandelt.
Der zweite Punkt ist der brisante. Googlebot, Applebot und Bingbot crawlen jeweils für die Suche und für das Training — mit demselben Bot, unter demselben Namen. Wer Training sperrt, kann sie damit mittreffen.
Und hier ist die Stelle, an der ich ehrlicher sein muss als die meisten Artikel zu diesem Thema: wie weit diese Regel reicht, ist offen. Cloudflares Formulierung lautet, die Voreinstellungen würden nach den restriktivsten zutreffenden Regeln durchgesetzt — und dieser Satz steht im Zusammenhang der Voreinstellungen für neu aufgenommene Domains. Ein Teil der Berichterstattung liest daraus eine Regel, die jeden trifft, der Training sperrt, auch in Bestandszonen und auch über den alten Sammelschalter. Beide Lesarten sind vertretbar. Die Dokumentation zu AI Crawl Control führt weder den alten Schalter noch die Behandlung von Mehrzweck-Crawlern und entscheidet die Frage damit auch nicht.
Praktisch macht das keinen Unterschied, und genau darin liegt die Handlungsanweisung: nachsehen statt verlassen. Wer die schärfere Lesart annimmt und im Dashboard nachschaut, verliert nichts. Wer die mildere annimmt und nicht nachschaut, erfährt es am Traffic.
Warum der Schalter überhaupt etwas anderes tun kann als gedacht
Der Mechanismus dahinter ist der eigentliche Grund, warum dieses Thema so viele Fehlkonfigurationen produziert. Es gibt drei verschiedene Schichten, auf denen man KI-Crawler steuern kann, und sie werden dauernd verwechselt. - Zugriff — die robots.txt, geregelt in RFC 9309. Wirkt vor dem Abruf, und sie ist eine Bitte. Die RFC sagt es selbst: diese Regeln sind keine Form der Zugriffsautorisierung. - Nutzung — Content-Signal beziehungsweise das AIPREF-Vokabular. Sagt, was nach dem Abruf mit dem Inhalt erlaubt ist. Ebenfalls eine Bitte, und noch nicht standardisiert. - Durchsetzung — WAF und Bot-Management. Wirkt vor dem Abruf und wirkt wirklich.
Cloudflare bindet am 15. September einen Schalter der dritten Schicht an eine Kategorisierung, die die meisten Leute mit dem Denken der ersten bedient haben. «Ich sperre Training» hiess in der robots.txt immer nur: ich bitte darum. Im Bot-Management heisst es: ich lasse nicht durch. Wenn der Bot, den man nicht durchlässt, zwei Zwecke bündelt, trifft man beide.
Vier Angaben, die in verbreiteten Anleitungen nicht stimmen
Dieser Teil bleibt relevant, wenn der Stichtag längst vorbei ist. Ich habe die Bot-Tokens Ende Juli gegen die Dokumentation ihrer Betreiber geprüft — OpenAI, Anthropic, Perplexity, Google, Apple, Meta. Vier Dinge kommen dabei immer wieder falsch vor.
Erstens: drei Tokens existieren nicht.
Claude-Web und anthropic-ai hat Anthropic zurückgezogen; sie stehen nicht mehr in der Doku. OpenAI-SearchBot hat es nie gegeben — korrekt ist OAI-SearchBot. Wer diese Namen in seine robots.txt schreibt, schreibt Regeln für Bots, die niemand liest.
Zweitens: ClaudeBot ist der Trainings-Crawler, nicht der Retrieval-Bot.
Verbreitete Tabellen führen ihn als «Training und Retrieval». Anthropics Doku trennt das: Retrieval läuft über Claude-SearchBot. Die Verwechslung stammt aus der Zeit, als ClaudeBot der einzige Claude-Bot war — und sie hat eine unangenehme Folge, weil sie die Entscheidung verwischt, um die es eigentlich geht.
Drittens: Google-Extended und Applebot-Extended sind gar keine Crawler.
Google schreibt zu Google-Extended wörtlich, das Token habe keinen eigenen HTTP-User-Agent-String, es werde in steuernder Funktion verwendet. Apple hält zu Applebot-Extended fest, es crawle keine Webseiten. Beide regeln nachträglich, was der jeweilige echte Crawler mit dem bereits Geholten tun darf. In einer Retrieval-Klasse sind sie wirkungslose Deko — und wer Google-Extended sperrt, um aus den AI Overviews zu verschwinden, erreicht das nicht: Google dokumentiert, dass das Token weder Aufnahme noch Ranking in der Suche beeinflusst, und die AI Overviews laufen über Googlebot.
Viertens: mehrere Tokens stehen in der falschen Klasse.
Diffbot wird als Training geführt, ist aber Retrieval — der Betreiber schreibt ausdrücklich, man crawle Seiten nicht, um generative Foundation-Models zu trainieren, sondern damit Seiten gefunden und zitiert werden. cohere-ai wird als Training geführt, ist aber nutzerinitiiert; Coheres echtes Trainings-Token heisst cohere-training-data-crawler und fehlt fast überall. Und FacebookBot ist in Metas aktueller Doku nicht auffindbar — der KI-Trainings-Crawler heisst dort meta-externalagent.
Die praktische Folge ist unangenehm konkret: wer Training mit einer solchen Liste sperrt, sperrt einen Discovery-Crawler aus, verfehlt das echte Trainings-Token und verlässt sich auf zwei Einträge, deren Existenz ungeklärt ist.
Die wichtigste Aussage in diesem Feld
Und sie wird am häufigsten missverstanden: Training sperren kostet keine Zitierbarkeit. Training und Retrieval laufen über verschiedene Bots. Wer GPTBot und ClaudeBot sperrt, aber OAI-SearchBot und Claude-SearchBot offen lässt, verschwindet nicht aus KI-Antworten — er verschwindet aus den Trainingsdaten. Das ist eine Geschäftsentscheidung und keine technische.
Zwei Ausnahmen sind allerdings belegt. Bei Bing sind Retrieval und Training über robots.txt gar nicht trennbar; es gibt kein separates Trainings-Token, und der einzige Hebel ist das Meta-Tag <meta name="bingbot" content="noarchive">. Bei Apple existiert der Hebel, wird aber übersehen: wer nur die üblichen Trainings-Tokens sperrt und Applebot-Extended vergisst, trainiert weiter.
Und was ist mit use=?
Auf der zweiten Schicht — Nutzung statt Zugriff — begegnet man inzwischen einer Zeile wie Content-Signal: search=yes, ai-train=no, use=reference. Die drei Signale stammen aus Cloudflares Content Signals Policy, veröffentlicht Ende September 2025 unter CC0. Der Parameter use= mit den Werten immediate, reference und full wird häufig mitzitiert, als gehörte er zum Standard.
Er gehört nicht dazu. use= ist eine Cloudflare-Erweiterung. Die IETF-Arbeitsgruppe AIPREF arbeitet parallel an einem eigenen Vokabular; der Draft vom 28. April 2026 kennt genau zwei Kategorien — train-ai und search — mit den Werten y und n, und trägt an mehreren Stellen den Vermerk, dass noch kein Konsens besteht. Wer die Zeile setzt, sollte wissen, dass zwei verschiedene Fassungen im Umlauf sind und keine davon technisch durchsetzt.
Ein Fall, den man nachlesen kann
Wie unfertig diese Schicht ist, lässt sich an einer Datei zeigen, die gerade ausgeliefert wird. Patreons robots.txt — von Cloudflare verwaltet, 94 Zeilen, abgerufen am 30. Juli 2026 — trägt drei Content-Signal-Zeilen mit zwei verschiedenen Vokabularen. Die Sternchen-Gruppe in Zeile 30 führt search=yes,ai-train=no,use=reference und äussert gar keine Präferenz zu ai-input. Die Gruppen für PetalBot und TikTokSpider in Zeile 89 und 92 führen search=yes, ai-input=yes, ai-train=no und kein use=. Eine Datei, ein Generator, zwei Fassungen. Warum sie abweichen, ist nicht dokumentiert — ich beschreibe hier nur, was drinsteht.
Nebenbei zeigt der Fall die Regel, an der die meisten robots.txt-Dateien scheitern: Gruppen vererben nicht. PetalBot und TikTokSpider haben eigene Gruppen, also gelten die Signale aus der Sternchen-Gruppe für sie nicht. Die Wiederholung je Gruppe ist keine Redundanz, sondern Voraussetzung dafür, dass die Aussage überhaupt greift. Wer eine Spezialgruppe anlegt und die Disallow-Zeilen nur oben stehen lässt, gibt diesem einen Bot mehr Rechte als allen anderen.
Was jetzt zu tun ist
Vier Schritte, keine davon dauert lange. - Nachsehen. Cloudflare-Dashboard, AI Crawl Control, Security, Crawlers. Notieren, was pro Kategorie eingestellt ist — auch wenn du glaubst, es zu wissen. - Baseline dokumentieren, solange sie noch gilt. Screenshot der Einstellungen, Export der Crawling-Statistiken, aktuelle robots.txt archivieren. Jeweils mit Datum. Nach dem Stichtag ist das nicht mehr nachholbar. - Entscheiden und begründen. Je Domain, nicht einmal für alle. Kundeninventar und eigener Marken-Content vertragen unterschiedliche Antworten. - Danach messen. Crawling-Statistiken in der Search Console und die Server-Logs beobachten. Ein grüner Build sagt nichts darüber, was ausgeliefert wird.
Und ein Schritt, der vor allen anderen kommt, wenn du Training sperren willst: prüfe, wo der schützenswerte Inhalt tatsächlich steht. Wenn derselbe Kern auf einer Partnerseite, in einem Feed oder in einer eigenen llms-full.txt offen daneben liegt, entfernt deine Sperre nur die Attributionsspur, während der Trainings-Crawler den Inhalt am Ursprung holt. Dann entsteht ein Artefakt, das eine Zusicherung stützt, die materiell nicht trägt — und das ist schlechter als ein offener Widerspruch, weil sich irgendwann jemand darauf verlässt.
Was wir selbst gemacht haben
Wir liefern acht Domains aus einem Deployment aus. Die robots.txt entsteht pro Domain im Code, mit den vier Wirkungsklassen als Gruppen. Unser Entscheid: Training erlaubt. Alle acht Sites tragen Inhalte, die für uns werben, kein Kundeninventar — sie sollen in das Wissen eingehen, aus dem Modelle über Schweizer KI-Anbieter sprechen. Bei Kundendaten oder bezahltem Inventar fiele die Entscheidung anders aus.
Seit dieser Woche sprechen wir es zusätzlich als Nutzungspräferenz aus: Content-Signal: search=yes, ai-input=yes, ai-train=yes. Vorher war die Erlaubnis nur die Abwesenheit einer Sperre. Cloudflares use= setzen wir nicht — es ist kein Standard, und die eigene Datei soll dem nicht widersprechen, was wir schreiben.
Der teuerste Fehler der Vorversion unserer eigenen Datei war übrigens ein anderer: /_next/ stand auf Disallow. Von dort liefert Next.js CSS und JavaScript aus. Googlebot konnte die Seiten nicht rendern und sah unformatierte Skelette. Ein Test hält diesen Fall jetzt fest — samt einer Kontrolle, die absichtlich eine kaputte Variante durch dieselbe Prüfung schickt und rot werden muss. Eine Prüfung, die nie etwas findet, belegt nämlich nichts.
Wer das für die eigene Domain durchgehen will: unser Guide zur KI-Crawler-Steuerung führt alle vier Wirkungsklassen mit Primärquelle je Token, und der Check beantwortet in sechs Fragen, in welcher Lage du bist — die Antworten verlassen deinen Browser nicht, und am Ende steht eine robots.txt zum Kopieren.
Quellen: Cloudflare, «Your site, your rules: new AI traffic options for all customers», 1. Juli 2026 (blog.cloudflare.com/content-independence-day-ai-options). Cloudflare Changelog, «New options to manage AI traffic», 1. Juli 2026. Cloudflare Docs, «robots.txt setting» und «Manage AI crawlers» (developers.cloudflare.com). RFC 9309, Robots Exclusion Protocol, Koster/Illyes/Zeller/Sassman, September 2022 (rfc-editor.org/rfc/rfc9309.html). IETF AIPREF, «A Vocabulary For Expressing AI Usage Preferences», Internet-Draft, Keller/Thomson, 28. April 2026. Bot-Tokens geprüft am 29. Juli 2026 gegen die Dokumentation der Betreiber: developers.openai.com/api/docs/bots, support.claude.com/en/articles/8896518, docs.perplexity.ai/guides/bots, developers.google.com/search/docs/crawling-indexing/google-common-crawlers. Patreons robots.txt abgerufen am 30. Juli 2026.