Ihre Seite, Ihre Regeln: neue KI-Traffic-Optionen für alle Kunden

Vor einem Jahr haben wir den ersten Content Independence Day ausgerufen und Website-Betreibern ermöglicht, die Kontrolle über ihre Inhalte zurückzugewinnen. Das jahrzehntealte Modell zwischen Crawlern und Website-Betreibern – wir crawlen, und dafür kommt Referral-Traffic zurück – funktionierte nicht mehr. KI nahm alles auf, ohne etwas an die Website-Betreiber zurückzugeben, was eine existenzielle Bedrohung für Website-Betreiber darstellte. Deshalb haben wir eine Ein-Klick-Option „KI-Bots blockieren“ zusammen mit einem Pay-per-Crawl-Marketplace eingeführt.

In einem Jahr hat sich viel verändert. Letzten Juli standen Gespräche über „KI-Bots“ noch stark im Zeichen der Blockierung von KI-Training ohne Vergütung – und damit eines Win-Lose-Deals, bei dem Content für Modelltraining genutzt wurde, ohne den Website-Betreibern einen Gegenwert zu liefern. Inzwischen ist der Wunsch nach mehr Differenzierung deutlich geworden: Content-Inhaber wollen ihre Inhalte weiterhin schützen können und für die Originalinhalte vergütet werden, die sie mit viel Aufwand erstellen, kuratieren und teilen. Gleichzeitig ist klar, dass das vollständige Abschotten von Content keine Lösung für jeden Fall ist; Website-Betreiber wollen mehr Optionen als pauschal „alle Automatisierung immer blockieren“.

Für Betreiber kleiner Websites liegt das Problem nicht nur darin, dass andere Ihre Inhalte für Modelltraining verwenden könnten – sondern darin, dass Sie zunächst überhaupt sichtbar werden müssen. Sie werden also zu einem unfairen Tausch gezwungen: Entweder Sie bleiben in der Suche auffindbar und akzeptieren KI-Training auf Ihren Inhalten, oder Sie riskieren, Sichtbarkeit zu verlieren. Das spielt etablierten Suchanbietern unfair in die Hände, wenn sie dieselben Bots für Suche und Training verwenden; dieser unfaire Vorteil schafft wiederum Anreize für neue Anbieter, weniger transparent vorzugehen, um den Wettbewerbsrückstand aufzuholen.

Heute kann KI in allem stecken. Die Google-Suche hat sich von einer durch KI sortierten Suche zu einer vollwertigen Antwortmaschine entwickelt, die Ihre Frage direkt auf der Ergebnisseite beantwortet. Und Google ist damit kein Sonderfall – das ist die Richtung, in die sich „Suche“ entwickelt.

Wir könnten lange darüber sprechen, was heute noch als „KI“ zählt und was nicht – nur um festzustellen, dass sich der Maßstab morgen wieder geändert hat. Deshalb setzen wir bei der Klassifizierung künftig weniger bei der Frage an, ob ein Bot „KI“ ist, und stärker bei seinem Verhalten als Bot oder Agent: Was macht er auf meiner Website? Welche Informationen speichert er? Und wie wird er meine Inhalte weiterverwenden oder erneut ausspielen?

Um diese Fragen anzugehen, benötigen wir mehr Nuance – eine praxisnahe Taxonomie, die zu den KI-Anwendungsfällen passt, die unseren Kunden wichtig sind. Deshalb öffnen wir die Diskussion über KI-Training hinaus und richten den Fokus auf drei KI-Anwendungsfälle, die alle Kunden steuern können sollten.

• Search (Suche): jedes Verhalten, bei dem Ihre Inhalte gesammelt oder indexiert werden, damit später Fragen dazu beantwortet werden können. Entscheidend ist, dass „Search“ proaktiv eine Datenbank Ihrer Website aufbaut, um später auf Anfragen zu reagieren. Website-Betreiber sollten dafür Referral-Traffic oder eine andere angemessene Vergütung erwarten können.

• Agent: automatisiertes Verhalten, das in der Regel in Echtzeit für eine Person tätig wird, um jetzt etwas zu erledigen. Das umfasst Chat-Fetch-Bots, zum Beispiel ChatGPT-User, und Browser-Use-Agents, etwa Gemini oder Claude beim Steuern von Chrome. Entscheidend ist, dass der Agent Ihre Webanwendung besucht, um eine Aufgabe abzuschließen, während am anderen Ende oft ein Mensch auf das Ergebnis wartet.

• Training: wenn ein Crawler Ihre Inhalte nutzt, um ein Modell zu trainieren oder per Fine-Tuning weiterzuentwickeln. Entscheidend ist, dass Ihre Daten dauerhaft in die zugrunde liegende Architektur der KI aufgenommen werden, um deren Fähigkeiten zu verbessern.

Viele gängige Crawler im Web fallen in eine der oben genannten Kategorien; manche fallen in mehrere zugleich. Wir klassifizieren darüber hinaus zahlreiche weitere Verhaltensweisen – darunter Anzeigenverifizierung, Feed-Abrufe und agentische Transaktionen, auf die wir weiter unten näher eingehen. Dennoch sollte es aus unserer Sicht für alle Website-Betreiber einfach sein, den Zugriff für diese drei KI-zentrierten Anwendungsfälle zu steuern. Wir glauben, dass Bot-Betreiber ihre Crawler trennen sollten, weil das Website-Betreibern mehr Transparenz gibt: Sie können besser verstehen, warum ein bestimmter Crawler ihre Website besucht, und den Zugriff, den sie diesem Crawler gewähren, gezielter steuern. Wenn ein Unternehmen Automatisierung betreibt, die Such-Indizes aufbaut, als Agent handelt und Daten sammelt, um Modelle zu trainieren, dann empfehlen wir diesem Unternehmen ausdrücklich, diese Automatisierung auf drei separate Crawler aufzuteilen.

Wir möchten ein Klassifizierungssystem schaffen, das skalierbar ist und die sich wandelnde Welt des automatisierten Traffics realistisch abbildet. Dass man die Zwecke eines Bots verfolgt, ist nicht neu. Neu an unserer Taxonomie sind jedoch einige Updates, die den aktuellen Zustand des Bot-Traffics besser erfassen. Besonders wichtig ist uns: Bots mit mehreren Zwecken sollten auch entsprechend mehrfach klassifiziert werden, statt nur einem einzigen Zweck zugeordnet zu sein.

Wir möchten allen Website-Betreibern im Cloudflare-Netzwerk mehr Optionen zur Verwaltung verschiedener Arten von KI-Traffic bereitstellen.

Die verwaltete Voreinstellung „KI-Bots blockieren“, die wir in der Vergangenheit angekündigt haben, umfasste Einzweck-Bots, die Daten für das Modelltraining crawlen, wie unten gezeigt: 

^{Screenshot der bestehenden Einstellung zur Verwaltung von AI-Bot-Traffic am 1. Juli 2025.}

Doch nicht jede KI-Nutzung folgt demselben Muster, und unsere Kunden sollen genau die Steuerungsmöglichkeiten erhalten, die sie benötigen. Deshalb starten wir die Möglichkeit, KI-Traffic anhand von drei zentralen Anwendungsfällen zu verwalten: Such-, Agent- und Training-Crawler. Diese neuen Optionen erlauben es unseren Kunden, den Umgang mit KI-Bot-Traffic deutlich feiner abzustimmen – auch im Free-Tarif.

^{Screenshot der neuen Optionen zur Verwaltung von KI-Bot-Traffic am 1. Juli 2026.}

Ab dem 15. September 2026 gelten neue Standardeinstellungen für diese drei Klassifizierungen. Für alle neuen Domains, die zu Cloudflare wechseln, werden die Kategorien Training und Agent standardmäßig auf Seiten, auf denen Anzeigen eingeblendet werden, blockiert, während Suche standardmäßig erlaubt bleibt. 

Eine Anzeige macht deutlich, dass eine Seite nicht nur abgerufen, sondern von Menschen gesehen werden soll. Diese menschliche Aufmerksamkeit ist monetarisierbar und finanziert das Geschäft. Deshalb behandeln wir sie auf solchen Seiten als das Ziel, das geschützt werden muss, und schließen Bots aus, die dieses Ziel unterlaufen könnten – etwa Training- und Agent-Bots. Search hingegen leitet Besucher am ehesten wieder zur Website zurück, und wir glauben, dass die meisten Website-Betreiber davon profitieren, Search zuzulassen.

Eine weitere Änderung, die am 15. September in Kraft tritt: Mehrzweck-Crawler – insbesondere solche, die Suche mit Training kombinieren – werden entsprechend aller ihrer Verhaltensweisen zugelassen oder blockiert, ganz im Sinne unseres Aufrufs zu mehr Transparenz für Website-Betreiber. Da die Standardeinstellungen nach den jeweils restriktivsten anwendbaren Regeln durchgesetzt werden, werden Mehrzweck-Crawler wie Googlebot, Applebot und BingBot bei Kunden blockiert, die Training blockieren möchten – entweder über die neuen Optionen zum Verwalten von KI-Traffic oder über den bisherigen Dienst „KI-Bots blockieren“.

Natürlich bleibt die Wahlfreiheit der Kunden entscheidend: Wenn ein Website-Inhaber diese neuen Standardeinstellungen nicht übernehmen möchte, kann er dies jederzeit vor dem 15. September problemlos in seinen Sicherheitseinstellungen vermerken. Damit wird bestätigt, dass er für Training-Crawler, die auch für Suchzwecke crawlen, keine Änderungen möchte. Darüber hinaus informieren wir Kunden weiterhin über die bevorstehende Änderung der Standardeinstellungen, damit diejenigen, die andere Einstellungen bevorzugen, dies rechtzeitig festlegen können.

Wir freuen uns auch, ein großes Update für mehr Transparenz als neue Funktion von Enterprise Bot Management zu starten. Mit dem Wachstum des Cloudflare-Verzeichnisses getrackter Bots ist auch der Wunsch gewachsen, diese Bots in sinnvollen Gruppen zu verwalten und mehr Details zu einzelnen Bots einzusehen. 

Wir präsentieren: BotBase. BotBase ist unsere neue Datenbank, in der alle bekannten Bots erfasst werden, einschließlich verifizierter Bots und Agenten. Diese Datenbank bietet eine umfassende, durchsuchbare Ansicht unseres gesamten Bot-Verzeichnisses direkt auf dem Cloudflare-Dashboard. Wir legen zuerst den Fokus auf Sichtbarkeit, aber später dieses Jahr werden wir BotBase erweitern, um ein direktes Kontrollzentrum für bekannte automatisierte Zugriffe auf Ihrer Website bereitzustellen.

Mit dieser neuen Ansicht können Enterprise Bot Management-Kunden den vollständigen Katalog aller verifizierten Bots/Agenten und deren Klassifizierung in dieser aktualisierten Taxonomie sehen — eine Ansicht, die wir bisher noch nie dynamisch auf dem Cloudflare-Dashboard gezeigt haben. Wer einen bestimmten Bot präzise ins Visier nehmen möchte, kann zudem problemlos nach dem gesamten Traffic dieses Bots filtern und die Detection-ID kopieren, um sie in Security-Regeln zu nutzen. Diese Funktionen sind ab sofort auf einer eigenen Seite verfügbar, erreichbar über die Bot-Management-Konfigurationskarte. 

Als wir BotBase aufgebaut haben, wollten wir sämtliche Informationen erfassen, die skalierbare und aussagekräftige Erkenntnisse über verschiedene Bots hinweg ermöglichen. Ein zentraler Baustein dafür ist unsere aktualisierte Taxonomie, die sich danach richtet, was ein Bot auf Ihrer Website tun kann – seinem Verhalten. Die Klassifizierungen trennen wir wie unten beschrieben, wobei jeder Bot einer oder mehreren dieser Verhaltensweisen zugeordnet wird.

^{Fett-kursiv geschriebene Zeilen kennzeichnen die neuen konfigurierbaren Optionen, die allen Kunden zur Verfügung stehen.}

Eine weitere wichtige Information für unsere Kunden ist die Content-Nutzung eines Bots – also was ein Bot behalten und weitergeben kann, nachdem er Ihre Inhalte gecrawlt hat. Dafür entwickeln wir Funktionen, mit denen Bot-Management-Kunden auf Grundlage der „Content-Nutzung“ auswählen und blockieren können. Diese Einstellung kann eine von drei Stufen annehmen – von der strengsten bis zur offensten:

• immediate — interagieren, aber nichts speichern oder wiederverwenden

• reference (Standard) – indizieren, ausschnittsweise darstellen und zurückverlinken

• full — zusammenfassen und reproduzieren

Diese Werte können mit Bot-Klassifizierungen kombiniert werden, um nuancierte Regeln auszudrücken, wie zum Beispiel „alle Bots zuzulassen, die für Suche, SEO und Anzeigenprüfung verwendet werden, jedoch nur bis zur Nutzungsebene reference.“ So können Website-Betreiber Entscheidungen in sinnvollen Gruppen treffen, statt einzelne Regeln Bot für Bot verwalten zu müssen.

Um dies weiter zu unterstützen, testen wir ab heute ein neues Signal namens use, das Content Signals erweitert und in Ihrer robots.txt hinterlegt ist. Damit werden die drei Felder der ersten Version von Content Signals um ein viertes, optionales Feld ergänzt, das dieselbe Präferenz wie oben ausdrückt:

• use=immediate

• use=reference

• use=full

Wie bei allen anderen Einträgen, die in der robots.txt-Datei aufgeführt sind, signalisieren die Werte des Content-Use-Signals die Präferenz eines Website-Betreibers, anstatt direkt Blockierungen auszugeben. Wir ergänzen jetzt die Unterstützung für diese Erweiterung: Bei allen Kunden, die bereits das verwaltete robots.txt aktiviert haben – wodurch robots.txt die Präferenz vorangestellt wird, dass Crawling für Suche in Ordnung ist, Crawling für Training jedoch nicht –, wird jetzt zusätzlich die Präferenz use=reference in ihre robots.txt aufgenommen.

# Cloudflare Managed content with original Content Signals

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

^{Der Inhalt der von Cloudflare verwalteten robots.txt mit den ursprünglichen Content Signals-Werten.}

# Cloudflare Managed content with the new content-use signal

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

^{Der Inhalt der von Cloudflare verwalteten robots.txt mit dem hinzugefügten Parameter.}

Wir beginnen außerdem damit, die Content-Nutzung für jeden Bot in BotBase zu erfassen. Wenn wir feststellen, dass ein Bot diese Signale missbraucht, verliert er den Status „Verifiziert“ und wird infolgedessen nicht mehr zugelassen. Bots, die Inhalte vollständig reproduzieren, können schon heute keinen „Verifiziert“-Status erhalten.

Apropos „Verifiziert“, die Definition von Verifiziert wird aktualisiert, um die bevorstehenden Änderungen an den Standardwerten für Zulassen und Blockieren zu berücksichtigen. Bisher waren alle „verifizierten“ Bots standardmäßig erlaubt. Das spiegelte sich sowohl in unserem grundlegenden Bot Fight Mode-Angebot zum Blockieren unerwünschten automatisierten Traffics als auch in unseren Regelvorlagen für Kunden von Enterprise Bot Management wider. 

Ab heute passen wir dies an, um mehr Differenzierung zu ermöglichen: Nicht verifizierte Bots werden weiterhin standardmäßig blockiert, aber wir betrachten „verifiziert“ nicht mehr als „standardmäßig erlaubt“. Stattdessen macht das Label „Verifiziert“ einen Bot innerhalb seiner jeweiligen Kategorie zulassungsfähig. Das bedeutet: Die zugelassene Kategorie, zum Beispiel Suche, bestimmt, was auf eine Website zugreifen darf.

Um diese Veränderung auszugleichen, öffnen wir den Prozess zur Verifizierung von Bots und machen ihn ebenfalls transparenter. Um einen Bot zu „verifizieren“, muss ein Bot-Betreiber zwei Dinge nachweisen: dass er sich ehrlich präsentiert und dass er den Zugang, den diese Ehrlichkeit ermöglicht, nicht missbraucht. Und um es Bot-Betreibern einfacher zu machen, entwickeln wir derzeit Management-Tools, mit denen sie besser sicherstellen können, dass sie im Klassifizierungssystem von Cloudflare korrekt dargestellt werden. Diese Tools werden in naher Zukunft angekündigt. 

^{Ein Vorschau-Screenshot der neuen Plattform, die speziell für Bot-Betreiber entsteht, die bereits zu BotBase gehören oder Teil davon werden möchten – der nächsten Generation des Cloudflare Bots Directory.}

Ein weiterer Punkt kommt hinzu: Der Bot oder Agent, der bei Ihnen anklopft, wird immer häufiger nicht von der Firma betrieben, die ihn gebaut hat. Eine Plattform wie die Entwicklerplattform (Developer Platform) von Cloudflare lässt Automatisierungen für Tausende verschiedene Betreiber parallel laufen – vom Enterprise-Kunden bis zu einem unbekannten Entwickler. Stripe vertrauen Sie vielleicht; das heißt aber nicht, dass Sie automatisch jedem vertrauen, der Stripe-Tools in ein Nebenprojekt integriert hat.

Wir nennen den Fall (Seiteninhaber → Unternehmen, dem der Bot gehört → Endbenutzer) eine Frage des transitiven Vertrauens und schlagen vor, den existierenden Forwarded-Header zu nutzen, wie er in RFC 7239 definiert ist, der mit der Anfrage gesendet wird und es „Proxy-Komponenten ermöglicht, Informationen offenzulegen, die im Proxying-Prozess verloren gehen.“ 

Es funktioniert ähnlich wie X-Forwarded-For bei IP-Adressen oder X-Forwarded-Host beim Erhalt des ursprünglichen Host-Headers. Sagt ein Website-Betreiber also „Diesen Operator erlauben“, bleibt diese Präferenz bestehen – egal, ob der Operator direkt zugreift oder über drei Schichten vertrauenswürdiger Zwischenstellen kommt. Weitere Informationen finden Sie in unserer Dokumentation, zusammen mit einem kurzen Beispiel zum Format unten.

Forwarded: for="openai"

Mit der oben besprochenen Content-Use-Erweiterung würde der Header-Zusatz etwa wie folgt aussehen, wobei angegeben wird, wie der Betreiber nach eigener Aussage die von ihm abgerufenen Inhalte verwenden wird:

Forwarded: for="openai";use="reference"

Das passt auch zu dem Anreizmodell, das wir fördern wollen. Den vertrauenswürdigen Status über mehr als 20 % der Webdomains zu verlieren, die hinter Cloudflare liegen, ist ein wirksames Abschreckungsmittel. Vertrauen wird zu etwas, das man mitbringt – und zu etwas, das man verspielen kann.

Wenn sich Bot-Traffic mit menschlichem Traffic vermischt, ist es jedoch möglich, dass dieses Modell des transitiven Vertrauens nur für Nutzer funktioniert, die identifizierbar sein können oder wollen. Die heute vorgeschlagenen Maßnahmen tragen dazu bei, Vertrauen zu vermitteln, aber sie werden nicht dauerhaft für das gesamte Web geeignet sein. Kleine Traffic-Quellen benötigen Privatsphäre, und Unternehmen, die ihre Datenschutzverpflichtungen schützen wollen, sollten faire Grundlagen für ein zukünftiges agentisches Internet prüfen können, zum Beispiel privates Rate Limiting.

Es handelt sich um kleine Änderungen, die gemeinsam in dieselbe Richtung gehen: Website-Betreiber bekommen mehr Kontrolle darüber, wer ihre Inhalte verwendet und auf welche Weise. Aus unserer Sicht fördern die neuen Standardeinstellungen, die wir heute besprochen haben und bald implementieren, mehr Transparenz und passen besser zu der Entwicklung, die wir weltweit sehen.

Natürlich wird das Web weiter in Bewegung bleiben, und seine Dynamiken werden sich auch künftig verändern. Wir werden uns entsprechend weiter anpassen. Aber die grundlegende Richtung ändert sich nicht: Sie entspricht dem, wofür Cloudflare von Anfang an stand – einem Web-Ökosystem auf Basis von Vertrauen. Einem Web, in dem diejenigen, die Inhalte schaffen, bestimmen können, wie diese verwendet werden, und in dem transparente Absichten mehr Zugang eröffnen, nicht weniger.

Diese neuen Optionen zur Verwaltung von KI-Traffic sind ab sofort live und können von allen bestehenden Kunden in ihren Zone-Einstellungen konfiguriert werden. Sie nutzen Cloudflare noch nicht? Starten Sie kostenlos, um die gewünschten Traffic-Kontrollen noch heute einzurichten.

Einen schönen Content Independence Day.