Cloudflare führt für KI-Webzugriffe eine neue Trennung zwischen Search, Agent und Training ein. Ab dem 15. September 2026 sollen bei bestimmten Cloudflare-Konfigurationen Agenten- und Trainingscrawler auf Seiten mit Werbung standardmäßig blockiert werden, während Suchcrawler erlaubt bleiben. Für Entwickler von Research-Agenten, Browser-Automationen und KI-Suchdiensten ist das relevant, weil der Zugriff nicht mehr nur vom Zielserver oder von robots.txt abhängt, sondern bereits auf Cloudflares Netzwerkebene scheitern kann.
Die Ankündigung selbst stammt vom 1. Juli 2026 und ist damit keine Meldung vom heutigen Tag. Durch die feste Umstellung im September wird sie jetzt jedoch operativ wichtig: Betreiber von Agenten müssen ihre Crawler klassifizieren und verifizieren lassen, während Website-Betreiber prüfen müssen, ob die neuen Voreinstellungen zu ihrer gewünschten Sichtbarkeit passen.
Was Cloudflare konkret ändert
Cloudflare ersetzt die bisher grobe Unterscheidung zwischen normalen Bots und KI-Bots durch eine verhaltensbezogene Taxonomie. Entscheidend ist nicht mehr nur, welches Unternehmen einen Bot betreibt, sondern wofür der Bot Inhalte abruft.
Cloudflare unterscheidet drei zentrale Kategorien:
- Search: Ein Crawler sammelt oder indexiert Inhalte, damit später Suchanfragen beantwortet werden können. Cloudflare verbindet diese Kategorie mit der Erwartung, dass die Website dafür Verweise, Reichweite oder eine andere Form des Ausgleichs erhält.
- Agent: Ein automatisiertes System greift meist in Echtzeit im Auftrag eines Nutzers auf eine Website zu. Dazu zählen laut Cloudflare Chat-Fetch-Bots wie ChatGPT-User und Browser-Agenten, die Webseiten bedienen, um eine konkrete Aufgabe zu erledigen.
- Training: Ein Crawler lädt Inhalte, um ein Modell zu trainieren oder nachzutrainieren. Die Daten fließen damit nicht nur in eine aktuelle Antwort ein, sondern sollen die Modellgewichte oder das dauerhafte Verhalten des Systems beeinflussen.
Diese Trennung ist technisch sinnvoll, weil ein Suchindex, ein interaktiver Agent und ein Trainingsdatensatz unterschiedliche Zwecke erfüllen. Bisher wurden diese Nutzungsarten häufig über denselben Crawler oder dieselbe Bot-Familie abgewickelt. Für Website-Betreiber war deshalb kaum erkennbar, ob ein Abruf später Besucher bringt, eine aktuelle Nutzeraufgabe ausführt oder das eigene Material dauerhaft in ein Modell einfließt.
Was ab dem 15. September 2026 gilt
Die neuen Einstellmöglichkeiten sind laut Cloudflare bereits seit dem 1. Juli verfügbar. Am 15. September 2026 ändern sich zusätzlich die Voreinstellungen für mehrere Gruppen von Websites.
Für neue Domains bei Cloudflare und neue Websites bestehender Kunden sollen dann auf Seiten mit Werbung die Kategorien Agent und Training standardmäßig blockiert werden. Search bleibt standardmäßig erlaubt. Die gleiche Änderung ist für bestehende Kunden im kostenlosen Tarif vorgesehen, sofern sie die Einstellungen vorher nicht ausdrücklich angepasst haben.
Wichtig ist die Einschränkung auf Werbeseiten. Cloudflare blockiert damit nicht pauschal jeden KI-Agenten auf jeder Website. Das Unternehmen verwendet sichtbare Werbung als Signal dafür, dass der Betreiber menschliche Besucher auf der Seite erwartet und über deren Aufmerksamkeit Einnahmen erzielt. Ein Agent, der den Inhalt abruft und die Antwort außerhalb der Seite präsentiert, unterläuft dieses Modell eher als ein Suchcrawler, der einen Besuch vermitteln kann.
Website-Betreiber können die Vorgaben im Cloudflare-Dashboard ändern. Die Umstellung ist also ein Standardwert, kein unumkehrbares Verbot. Trotzdem sind Standardwerte relevant: Viele Betreiber übernehmen sie unverändert, und bestehende kostenlose Accounts können ab dem Stichtag automatisch in die neue Konfiguration fallen.
Die neue Cloudflare-Oberfläche im Original
Die offizielle Produktansicht zeigt, dass sich die drei Kategorien getrennt steuern lassen. Besonders wichtig sind dabei diese Punkte:
- Search kann erlaubt bleiben, während Training und Agent auf Werbeseiten blockiert werden.
- Die Regeln greifen nicht nur über freiwillige Hinweise in robots.txt, sondern können als Cloudflare-Sicherheitsregel durchgesetzt werden.
- Ein Bot kann mehreren Kategorien gleichzeitig zugeordnet sein.
- Bei gemischten Crawlern entscheidet künftig die strengste passende Regel.
- Der Betreiber einer Website kann die empfohlenen Standardwerte jederzeit überschreiben.
Das Problem gemischter Crawler
Der technisch heikelste Teil betrifft Crawler mit mehreren Aufgaben. Cloudflare nennt unter anderem Googlebot, Applebot und BingBot als Beispiele für Systeme, die Search mit weiteren Verwendungsarten verbinden können. Ab dem 15. September sollen solche Bots nach allen erkannten Verhaltenskategorien behandelt werden.
Wenn eine Website Training blockiert, ein Bot aber gleichzeitig als Search und Training klassifiziert ist, greift die strengere Sperre. Der Website-Betreiber gewinnt damit Kontrolle über Trainingszugriffe, riskiert aber zugleich Reichweite in der klassischen Suche. Cloudflare will mit dieser Konstruktion ausdrücklich Druck auf Anbieter ausüben, getrennte Crawler für Suche, Agentenabrufe und Training zu verwenden.
Für Google ist das besonders relevant, weil Cloudflare dem Konzern vorwirft, Suche und KI-Nutzung nicht sauber genug zu trennen. Cloudflare behauptet auf Basis eigener Netzwerkdaten, der größte Suchanbieter könne dadurch auf ungefähr doppelt so viele Informationen zugreifen wie führende reine KI-Anbieter. Diese Zahl ist eine Cloudflare-Angabe und keine unabhängige Marktanalyse. Die strukturelle Frage dahinter bleibt dennoch berechtigt: Ein Betreiber kann nur dann differenziert zustimmen, wenn der Crawler seinen Zweck technisch erkennbar macht.
Warum robots.txt allein nicht mehr genügt
robots.txt ist traditionell eine freiwillig beachtete Anweisung an Crawler. Seriöse Bots lesen die Datei und folgen den Regeln, technisch erzwingen kann die Datei den Ausschluss aber nicht. Ein Bot kann sie ignorieren oder seinen Zweck falsch deklarieren.
Cloudflares Ansatz verlagert die Kontrolle an den Netzwerkrand. Wenn eine Regel dort einen Agenten blockiert, erreicht dessen Anfrage die eigentliche Website nicht mehr. Für Agentenentwickler bedeutet das, dass ein korrekt formulierter User-Agent und die Beachtung von robots.txt zwar notwendig, aber nicht mehr ausreichend sind.
Cloudflare erweitert zugleich die sogenannten Content Signals in robots.txt. Ein zusätzlicher Hinweis soll ausdrücken können, ob Inhalte nur als Referenz verwendet oder in größerem Umfang reproduziert werden dürfen. Cloudflare betont selbst, dass diese Signale eine Präferenz des Website-Betreibers darstellen und keine technische Sperre sind. Die harte Durchsetzung erfolgt weiterhin über Cloudflare-Regeln und die Bot-Klassifizierung.
Die Architektur besteht damit aus zwei Ebenen:
- Deklaration: Der Website-Betreiber beschreibt seine gewünschte Nutzung über Dashboard-Einstellungen und Content Signals.
- Durchsetzung: Cloudflare bewertet Bot-Verhalten, Verifizierungsstatus und Kategorien und kann den Zugriff bereits an der Edge blockieren.
Was Entwickler von KI-Agenten jetzt testen sollten
Research-Agenten, Monitoring-Systeme und Browser-Automationen werden nicht zwangsläufig komplett ausfallen. Wahrscheinlicher sind Lücken in der Abdeckung. Ein Agent erreicht weiterhin viele Seiten, erhält bei bestimmten Cloudflare-geschützten Werbeseiten aber einen Fehler oder eine Sicherheitsantwort. Das Ergebnis kann gefährlicher sein als ein vollständiger Ausfall: Die Anwendung liefert eine scheinbar vollständige Recherche, obwohl wichtige Quellen fehlen.
Entwickler sollten deshalb vor September mindestens fünf Punkte prüfen:
- Fehler sichtbar machen: Ein blockierter Abruf darf nicht still als leere Seite oder nicht vorhandene Information behandelt werden.
- Quellenabdeckung messen: Tests sollten dokumentieren, welcher Anteil einer bekannten Quellenliste erreichbar ist und welche Domains wiederholt blockieren.
- Bot-Identität stabil halten: Wechselnde oder irreführende User-Agents können kurzfristig Sperren umgehen, zerstören aber Vertrauen und erschweren eine offizielle Verifizierung.
- Berechtigten Zugriff vorsehen: Für Premium-Inhalte, Datenbanken und häufig benötigte Quellen werden APIs, Lizenzen oder bezahlte Abrufe wichtiger.
- Antworten kennzeichnen: Wenn Quellen nicht erreichbar waren, sollte die Anwendung das offen anzeigen statt aus verbleibenden Treffern eine übertriebene Sicherheit abzuleiten.
Diese Anforderungen betreffen nicht nur große Suchanbieter. Auch lokale Agenten, selbst gehostete Recherchetools und Browser-Workflows können betroffen sein, sobald sie automatisiert durch Cloudflare geschützte Seiten navigieren. Wer etwa einen Safari MCP Server für Browser-Agenten oder Managed Agents mit Remote MCP in der Gemini API einsetzt, muss neben Tool-Rechten künftig stärker mit Zugriffsregeln des offenen Webs rechnen.
BotBase und die Verifizierung von Agenten
Cloudflare baut mit BotBase ein Verzeichnis bekannter Bots und Agenten auf. Enterprise-Kunden mit Bot Management können dort nach Bots suchen, deren Verhaltenskategorien einsehen und Erkennungs-IDs für eigene Sicherheitsregeln übernehmen.
Der Status „Verified“ bedeutet künftig nicht automatisch, dass ein Bot überall erlaubt wird. Er zeigt vielmehr, dass der Betreiber seine Identität nachvollziehbar macht und den dadurch erhaltenen Zugriff nicht missbrauchen soll. Ob der Bot eine Website erreichen darf, hängt zusätzlich von der erlaubten Kategorie ab.
Cloudflare beschreibt zwei Grundbedingungen für die Verifizierung:
- Der Bot muss sich ehrlich repräsentieren.
- Der Betreiber darf den mit dieser Identität verbundenen Zugang nicht missbrauchen.
Bots, die Inhalte vollständig reproduzieren, können laut Cloudflare derzeit keinen Verified-Status erhalten. Zudem will das Unternehmen den Verifizierungsprozess öffnen und Werkzeuge für Bot-Betreiber bereitstellen. Konkrete, allgemein verfügbare Selbstbedienungsabläufe sind in der Ankündigung jedoch noch nicht vollständig beschrieben. Entwickler sollten deshalb nicht so planen, als sei eine Verifizierung bereits ein garantierter oder sofortiger Freifahrtschein.
Transitives Vertrauen für Agentenplattformen
Ein weiteres Problem entsteht, wenn ein Agent nicht direkt vom eigentlichen Betreiber auf eine Website zugreift. Cloud-Plattformen, Browser-Dienste oder Agenten-Infrastrukturen führen Anfragen für viele unterschiedliche Kunden aus. Eine Website kann der Plattform vertrauen, aber nicht automatisch jedem Nutzer dieser Plattform.
Cloudflare schlägt dafür ein Modell des transitiven Vertrauens vor. Informationen über den ursprünglichen Betreiber und den beabsichtigten Verwendungszweck sollen über standardisierte Weiterleitungsinformationen entlang der Anfragekette erhalten bleiben. Als technische Basis nennt Cloudflare den Forwarded-Header nach RFC 7239 und die eigene Web-Bot-Auth-Architektur.
Das ist noch kein universeller Webstandard für Agentenberechtigungen. Es zeigt aber die Richtung: Künftige Agenten müssen nicht nur eine Browser-Sitzung simulieren, sondern ihre Identität und ihren Auftrag über mehrere Infrastrukturstufen nachvollziehbar transportieren.
Von Pay Per Crawl zu Pay Per Use
Cloudflare will nicht nur blockieren. Das Unternehmen entwickelt sein experimentelles Modell Pay Per Crawl zu Pay Per Use weiter. Publisher sollen nicht einfach für jeden Abruf bezahlt werden, sondern dann, wenn ihr Inhalt tatsächlich in einer KI-Antwort oder einem Agentenergebnis verwendet wird.
Als Partner nennt Cloudflare Ceramic.ai und You.com. Ceramic.ai soll Publisher vergüten können, wenn deren Inhalte in KI-Suchergebnissen erscheinen. Bei You.com ist ein Modell vorgesehen, bei dem ein Agent bei Bedarf für einen konkreten Premium-Inhalt bezahlt. Cloudflare beschreibt beide Ansätze ausdrücklich als Experimente, nicht als allgemein verfügbaren Standardmarkt.
Auch die Effizienz spielt eine Rolle. Laut Cloudflare entfällt mehr als die Hälfte des Crawl-Traffics seriöser Bots auf Seiten, die sich seit dem letzten Abruf nicht verändert haben. Das Unternehmen testet deshalb Aktualitätssignale, mit denen Suchdienste unnötige Abrufe vermeiden könnten. Diese Angaben stammen aus Cloudflares eigener Netzwerksicht und sind nicht unabhängig verifiziert.
Für Agentenentwickler entsteht damit eine neue Kostenebene. Neben Modell-Token, Browser-Laufzeit und API-Gebühren könnten künftig Lizenz- oder Nutzungsentgelte für Quellen anfallen. Dafür wäre der Zugriff stabiler und rechtlich wie technisch klarer als ein permanentes Wettrennen um Sperren.
Grenzen und offene Fragen
Cloudflares Modell löst nicht alle Probleme. Die Kategorien Search, Agent und Training sind klarer als ein einzelner KI-Bot-Schalter, aber reale Systeme überschneiden sich. Ein Agent kann eine Seite in Echtzeit lesen, das Ergebnis zwischenspeichern und die Daten später zur Verbesserung eines Modells verwenden. Die Zuordnung hängt dann von technischen Signalen, Angaben des Betreibers und Cloudflares eigener Erkennung ab.
Offen bleiben vor allem diese Fragen:
- Wie zuverlässig erkennt Cloudflare falsch deklarierte oder häufig wechselnde Bots?
- Wie schnell können kleinere Agentenprojekte einen verifizierten Status erhalten?
- Wie werden legitime Monitoring- und Archivierungsdienste klassifiziert?
- Wie transparent sind Fehlentscheidungen und Einspruchsmöglichkeiten?
- Welche Preise und Abrechnungsnachweise entstehen bei Pay Per Use?
Außerdem erhöht Cloudflare seine Rolle als Vermittler zwischen Publishern und KI-Anbietern. Das kann ein fragmentiertes Web ordnen, konzentriert aber zugleich Kontrolle über Sichtbarkeit, Identität und Monetarisierung bei einem großen Infrastrukturbetreiber. Entwickler sollten die neuen Regeln deshalb weder als bloße Sicherheitsfunktion noch als neutrale technische Norm behandeln.
Checkliste für Website-Betreiber
Website-Betreiber sollten vor dem 15. September nicht blind den Standardwert übernehmen. Sinnvoll ist eine bewusste Entscheidung pro Nutzungsart:
- Soll die Seite in klassischen und KI-gestützten Suchsystemen auffindbar bleiben?
- Dürfen Echtzeit-Agenten Inhalte lesen, Preise vergleichen oder Formulare bedienen?
- Ist Training mit den veröffentlichten Inhalten akzeptiert?
- Enthält die Website Werbeseiten, auf denen die neuen Standards greifen könnten?
- Wird Googlebot durch eine Training-Sperre unbeabsichtigt mit blockiert?
- Sind robots.txt, Content Signals und Cloudflare-Sicherheitsregeln konsistent?
Wer Reichweite priorisiert, wird Search meist erlauben. Bei Agent und Training hängt die Entscheidung stärker vom Geschäftsmodell, vom Inhalt und von vorhandenen Lizenzvereinbarungen ab.
Fazit: Agentenzugriff wird zu einer Berechtigungsfrage
Cloudflares neue KI-Crawler-Regeln markieren einen Wechsel: Der offene Webzugriff für Agenten wird von einer stillschweigenden Annahme zu einer expliziten Berechtigungsfrage. Ab dem 15. September können Agenten- und Trainingscrawler auf werbefinanzierten Seiten standardmäßig an Cloudflares Edge scheitern, während Search erlaubt bleibt.
Für Builder ist die wichtigste Konsequenz nicht ein einzelner neuer Schalter, sondern die Pflicht zu sauberer Identität, transparenter Fehlerbehandlung und messbarer Quellenabdeckung. Wer Agenten für Recherche, Monitoring oder Browser-Automation entwickelt, sollte diese Tests vor dem Stichtag durchführen. Wer Websites betreibt, sollte die Cloudflare-Voreinstellungen aktiv prüfen, weil eine zu strenge Training-Sperre bei gemischten Crawlern auch die gewünschte Suchsichtbarkeit treffen kann.
Häufige Fragen zu Cloudflares KI-Crawler-Regeln
Blockiert Cloudflare ab September alle KI-Agenten?
Nein. Die angekündigten Standardwerte betreffen Agent- und Trainingscrawler auf Seiten mit Werbung sowie bestimmte neue oder kostenlose Cloudflare-Konfigurationen. Website-Betreiber können die Regeln im Dashboard ändern.
Was ist der Unterschied zwischen Search, Agent und Training?
Search indexiert Inhalte für spätere Suchanfragen, Agent greift meist in Echtzeit im Auftrag eines Nutzers zu und Training verwendet Inhalte zur Verbesserung oder zum Nachtraining eines Modells. Ein Bot kann mehreren Kategorien gleichzeitig zugeordnet sein.
Können KI-Agenten eine Sperre durch einen anderen User-Agent umgehen?
Ein irreführender User-Agent kann kurzfristig einzelne Erkennungen beeinflussen, ist aber keine belastbare Strategie. Cloudflare kombiniert Bot-Identität, Verifizierung und Verhaltenskategorien; absichtliche Täuschung erschwert zudem legitimen Zugang.
Kann eine Training-Sperre auch Google Search treffen?
Ja. Cloudflare erklärt, dass gemischte Crawler künftig nach der strengsten zutreffenden Regel behandelt werden. Wenn ein Crawler Search und Training verbindet, kann eine Training-Sperre deshalb auch dessen Suchzugriff blockieren.
Ist Pay Per Use bereits ein allgemein verfügbarer Standard?
Nein. Cloudflare testet das Modell mit Partnern wie Ceramic.ai und You.com. Preise, Abdeckung und technische Abrechnung sind noch keine allgemein etablierte Infrastruktur für das gesamte Web.
Primärquellen: Cloudflare Pressemitteilung vom 1. Juli 2026 und technische Produktbeschreibung der neuen AI Bot Controls.