Cloudflare Disallow AI Training trennt Suchsichtbarkeit von Modelltraining

Cloudflare hat Disallow AI Training eingeführt, eine neue Steuerungsmöglichkeit, die die Indexierung für Suchmaschinen erhalten und zugleich Modelltraining durch denselben Crawler ablehnen soll. Bisher standen Publisher bei Bots mit gemischter Nutzung oft vor einer groben Wahl: beide Zwecke akzeptieren oder den Crawler vollständig blockieren.

Die Änderung betrifft Applebot, Googlebot und Bingbot, die Cloudflare als Crawler mit gemischter Nutzung einstuft, weil jeder von ihnen sowohl Suche als auch KI-bezogene Anwendungen unterstützen kann. Cloudflare bezeichnet diese Bots nun als „Accountable“, wenn ihre Betreiber Steuerungsmöglichkeiten, Reporting und Zusicherungen bieten, dass ein Opt-out für Training die herkömmliche Suchsichtbarkeit nicht verringert.

Diese Einstufung etabliert ein gemeinsames Betriebsmodell zwischen Cloudflare, Apple, Google und Microsoft. Sie schafft jedoch keinen verbindlichen technischen Standard. Das neue System kombiniert Dashboard-Steuerungen, Anweisungen in robots.txt, Unternehmenszusagen und Cloudflares Durchsetzung gegenüber anderen Training-Crawlern.

Das ist der zentrale Zielkonflikt. Publisher erhalten eine einfachere Möglichkeit, ihre Zustimmung auszudrücken, ohne aus der Suche zu verschwinden. Ein Großteil des Schutzes hängt jedoch weiterhin davon ab, dass Crawler-Betreiber diese Entscheidung respektieren.

Cloudflare Disallow AI Training verändert die Standardentscheidung

Cloudflare verwandelt eine überladene Blockierungsentscheidung in getrennte Optionen für Suche, Training und nutzergesteuerte Agents.

Cloudflares KI-Crawler-Steuerungen klassifizieren automatisierte Aktivitäten nach ihrem Verhalten, statt jede KI-bezogene Anfrage gleich zu behandeln. Such-Crawler erstellen Indizes, Training-Crawler sammeln Material für die Modellentwicklung, und Agents rufen Seiten im Auftrag eines Nutzers ab.

Diese Kategorien sind wichtig, weil sich ihre wirtschaftlichen Auswirkungen unterscheiden. Eine Suchmaschine zeigt normalerweise Links an, die Menschen auf die ursprüngliche Website führen können. Ein Trainingsprozess kann Informationen aufnehmen, ohne unmittelbar einen Besuch zu erzeugen. Ein Agent kann eine Seite abrufen und ihren Inhalt liefern, ohne dass der Nutzer sie jemals öffnet.

Ein Crawler kann mehr als einer Kategorie angehören. Googlebot, Applebot und Bingbot sind wichtige Beispiele, weil ihre Suchfunktionen es Publishern schwer machen, sie zu blockieren. Das Entziehen ihres Zugriffs kann sich letztlich auf Indexierung, Aktualität und Auffindbarkeit auswirken.

Cloudflares frühere Steuerungen berücksichtigten dieses Problem, indem sie Crawler mit gemischter Nutzung von einigen Trainingsblockierungen ausnahmen. Das schützte die Suchsichtbarkeit, ließ Publishern aber keine direkte Möglichkeit, die Trainingskomponente über dieselbe Einstellung abzulehnen.

Das neue Crawler-Steuerungsmodell führt Disallow AI Training als Zwischenoption ein. Es veröffentlicht eine Präferenz gegen Training über robots.txt, hält Accountable-Crawler mit gemischter Nutzung für die Suche verfügbar und blockiert andere mit Training verbundene Crawler.

Cloudflare zufolge können reine Training-Crawler von Amazon, Anthropic, Meta und OpenAI blockiert werden, ohne deren getrennte Such-Crawler zu beeinträchtigen. Diese Unternehmen verwenden für unterschiedliche Zwecke verschiedene Bots, was die Durchsetzung auf Netzwerkebene vereinfacht.

Cloudflare ändert außerdem die Bedeutung seiner strengeren Einstellungen. „Block“ und „Block on pages with ads“ gelten nun für Crawler mit gemischter Nutzung, einschließlich Googlebot, Applebot und Bingbot. Die Auswahl einer dieser Optionen kann daher sowohl die Suche als auch das Training beeinträchtigen.

Diese Unterscheidung macht die Konfiguration folgenreicher. Disallow AI Training kommuniziert eine begrenzte Präferenz und erhält zugleich den Suchzugriff. Block verweigert dem Crawler selbst den Zugriff, unabhängig davon, ob eine bestimmte Anfrage der Suche oder dem Training dient.

Bestehende Konfigurationen werden auf die neuen Steuerungen migriert. Eine Domain, die zuvor eine allgemeine KI-Blockierungsoption nutzte, behält in der Regel den Suchzugriff bei und verschiebt ihre Trainingspräferenz zu Disallow AI Training. Domains mit bestehenden granularen Richtlinien behalten ebenfalls ihre praktischen Auswahlentscheidungen.

Für neue werbefinanzierte Domains empfiehlt Cloudflare, die Suche zuzulassen, Training abzulehnen und Agents auf Seiten mit Werbung zu blockieren. Neue Domains ohne Werbung erhalten eine weniger restriktive Empfehlung, die alle drei Kategorien zulässt.

Diese Voreinstellungen sind Empfehlungen, keine dauerhaften Regeln. Website-Betreiber können sie beim Onboarding oder später über die Sicherheitseinstellungen ändern. Die Steuerungen sind in allen Cloudflare-Plänen verfügbar und arbeiten auf Domainebene.

Das Ergebnis ist ein klarerer Entscheidungsbaum. Ein Publisher kann die reguläre Indexierung erlauben, Training ablehnen und für Agents eine separate Richtlinie wählen. Diese Struktur bildet besser ab, wie automatisierte Systeme heute mit Websites interagieren.

Sie erleichtert auch die Diagnose fehlerhafter Konfigurationen. Wenn ein Publisher Block auswählt und später den Crawler-Zugriff verliert, folgt die Konsequenz unmittelbar aus der gewählten Einstellung. Disallow AI Training ist für das engere Ziel gedacht, die Suche zu erhalten und die Nutzung für die Modellentwicklung abzulehnen.

Es handelt sich nicht lediglich um einen umbenannten Bot-Schalter. Die Steuerungseinheit verschiebt sich von der Crawler-Identität allein hin zur Kombination aus Identität, offengelegtem Zweck und Betreiberverhalten.

Warum Crawler mit gemischter Nutzung Publisher unter Druck setzen

Der Konflikt besteht, weil ein Crawler, der wertvollen Suchtraffic liefert, zugleich Material für einen völlig anderen kommerziellen Zweck sammeln kann.

Der traditionelle Austausch im offenen Web war vergleichsweise leicht zu verstehen. Publisher erlaubten Suchmaschinen, ihre Seiten zu crawlen, und Suchmaschinen lieferten Links, Auszüge und potenzielle Besucher zurück. Werbung, Abonnements, Verkäufe und Beziehungen zu Lesern hingen davon ab, dass einige dieser Nutzer ankamen.

Generative KI verkompliziert diesen Austausch. Ein Modell kann gesammeltes Material während des Trainings nutzen, während eine KI-Antwort eine Anfrage erfüllen kann, bevor der Leser eine zitierte Quelle besucht. Suche, Modellentwicklung und Antwortgenerierung schaffen daher unterschiedliche Formen von Wert.

Cloudflares eigene Messungen verdeutlichen, warum Publisher besorgt sind. Das Unternehmen berichtete, dass Training über einen Zeitraum von zwölf Monaten 80 Prozent des klassifizierten KI-Crawlings ausmachte. In der folgenden Sechsmonatsbetrachtung stieg der Trainingsanteil auf 82 Prozent, während die Suche 15 Prozent und Nutzeraktionen 3 Prozent ausmachten.

Diese Zahlen beschreiben den von Cloudflare beobachteten und klassifizierten Traffic, nicht das gesamte Web. Sie zeigen dennoch, dass Trainingsaktivitäten die automatisierte Nachfrage bei Inhaltsanbietern dominieren können.

Ein Publisher, der einen reinen Training-Crawler blockiert, steht vor einer überschaubaren Abwägung. Die Blockierung kann die unerwünschte Sammlung stoppen, ohne einen wichtigen Suchindexer zu entfernen. Unterschiedliche Bots wie GPTBot und OAI-SearchBot erleichtern die Trennung dieser Zwecke.

Crawler mit gemischter Nutzung schaffen ein schwierigeres Problem. Unterstützt derselbe Crawler Suche und Training, kann eine infrastrukturbasierte Blockierung nicht bestimmen, was geschieht, nachdem der Inhalt seinen Betreiber erreicht hat. Die Blockierung schützt das Material, entfernt aber auch die Suchfunktion.

Das Zulassen des Zugriffs erhält die Auffindbarkeit, erfordert jedoch einen anderen Mechanismus, um die nachgelagerte Nutzung zu beschränken. Diese Lücke versucht die Einstellung Cloudflare Disallow AI Training zu schließen.

Cloudflare begann, diese Lücke mit Content Signals zu adressieren, einem vorgeschlagenen Vokabular in robots.txt. Die Content-Signal-Richtlinie unterscheidet drei erklärte Nutzungen: search, ai-input und ai-train.

Das Suchsignal deckt Indexierung und herkömmliche Suchergebnisse ab. Es umfasst keine KI-generierten Zusammenfassungen. Das Signal ai-input betrifft die Echtzeitnutzung durch KI-Systeme, einschließlich Abruf und Grounding. Das Signal ai-train bezieht sich auf Modelltraining und Fine-Tuning.

Eine Website kann daher search=yes und ai-train=no veröffentlichen. Sie kann ai-input unbestimmt lassen, wenn ihr Betreiber noch nicht entschieden hat, wie generative Antworten den Inhalt verwenden sollen.

Diese Trennung ist wichtig, weil eine fehlende Präferenz nicht als Zustimmung oder Ablehnung interpretiert werden sollte. Cloudflares Richtlinie behandelt ein ausgelassenes Signal als neutral, statt zu vermuten, was der Publisher beabsichtigt hat.

Content Signals sind jedoch Präferenzbekundungen. Sie sind keine Barrieren, die einen Scraper physisch daran hindern, eine Seite herunterzuladen. Cloudflare hat Publisher zuvor empfohlen, solche Signale mit Bot-Steuerungen oder Firewall-Regeln zu kombinieren, wenn technische Durchsetzung erforderlich ist.

Die neue Accountable-Einstufung versucht, diese Ebenen zu verbinden. Sie identifiziert Crawler-Betreiber, die laut Cloudflare bestimmte Steuerungen und Transparenz bereitstellen oder sich zu deren Bereitstellung verpflichtet haben. Zu den Anforderungen gehören ein Training-Opt-out, ein Opt-out für KI-Zusammenfassungen, Sichtbarkeit auf URL-Ebene und der Schutz traditioneller Suchrankings.

Apple, Google und Microsoft erfüllen diesen Schwellenwert durch unterschiedliche Kombinationen aktueller Funktionen und zeitgebundener Zusagen. Die Einstufung bedeutet nicht, dass ihre Implementierungen identisch sind. Sie bedeutet, dass Cloudflare davon ausgeht, dass jeder Betreiber dieselben grundlegenden Verantwortlichkeiten akzeptiert hat.

Dadurch entsteht Druck auf andere Crawler-Betreiber. Ein Unternehmen, das breiten Zugriff wünscht, kann nun mit einer veröffentlichten Grundlage für Zustimmung, Überprüfbarkeit und Suchneutralität verglichen werden. Die Trennung von Bot-Identitäten bleibt ein Weg, diesen Maßstab zu erfüllen, ist aber nicht mehr der einzige.

Publisher erhalten außerdem eine neue operative Verantwortung. Suchsichtbarkeit, KI-Training, Antwortgenerierung und Agent-Zugriff erfordern nun getrennte Richtlinien. Eine einzelne Entscheidung, „KI zu blockieren“, erfasst die geschäftlichen Zielkonflikte nicht mehr.

Eine durch Seitenaufrufe finanzierte Nachrichtenseite könnte sowohl Training als auch Agent-Zugriff auf Werbeseiten ablehnen. Ein Händler könnte qualifizierte KI-Weiterleitungen schätzen, selbst wenn deren Volumen geringer ist. Eine Dokumentationswebsite könnte den Echtzeitabruf durch KI begrüßen, langfristiges Modelltraining jedoch ablehnen.

Die entscheidende Frage lautet nicht mehr, ob KI-Bots gut oder schlecht sind. Sie lautet, welche Nutzung Zugriff rechtfertigt, welcher Wert an den Publisher zurückfließt und ob diese Nutzung überprüft werden kann.

Apple, Google und Microsoft teilen ein Modell, aber keine einheitliche Implementierung

Die drei Unternehmen unterstützen dasselbe Prinzip, doch ihre Steuerungen sind technisch weiterhin unterschiedlich weit entwickelt und werden zu verschiedenen Zeitpunkten eingeführt.

Apple erlaubt Publishern bereits, Training über Applebot-Extended zu steuern. Ein Website-Betreiber kann diesen User-Agent in robots.txt ausschließen und gleichzeitig die regulären Suchfunktionen von Applebot weiterhin zulassen.

Apples Dokumentation zufolge beeinflusst die Applebot-Extended-Präferenz nicht, wie eine Website in Suchergebnissen erscheint. Sie unterstützt außerdem Mechanismen auf Seitenebene für generative Ausgaben, darunter nosnippet und Kennzeichnungen für Inhalte hinter einer Paywall.

Diese Werkzeuge bieten noch nicht jedes Element in Cloudflares Accountable-Rahmenwerk. Cloudflare zufolge fehlt Apple für diesen Zweck die Überprüfbarkeit auf URL-Ebene. Apple soll Details zu einer in Entwicklung befindlichen Lösung geteilt haben, die im nächsten Jahr erwartet wird.

Die aktuellen Applebot-Steuerungen ermöglichen daher eine funktionierende Trennung zwischen Suche und Training, bieten aber nur unvollständige Sichtbarkeit darüber, was nach dem Zugriff geschieht. Cloudflare akzeptiert eine Zusage, diese Lücke zu schließen.

Google verwendet ein ähnliches Erweiterungsmodell. Publisher können Google-Extended blockieren, ohne Googlebot zu blockieren. Google-Extended ist ein Steuerungs-Token, das bestimmte generative KI-Nutzungen regelt, und kein separater Crawler, der stets eigene Anfragen stellt.

Dieses Detail ist wichtig. Googlebot kann den Inhalt weiterhin für die Suche abrufen, während Google die Google-Extended-Präferenz nutzt, um zu bestimmen, ob das Material unterstützte KI-Systeme versorgen darf. Der Publisher steuert die nachgelagerte Nutzung über Richtlinien statt über eine getrennte Netzwerkidentität.

Google sagt, dass ein Opt-out über Google-Extended weder die Aufnahme noch das Ranking in der Google Search beeinflusst. Die Hinweise zum Opt-out vom Training dokumentieren die Beziehung zwischen Googlebot und Google-Extended.

Google bietet außerdem Berichte zur Suchleistung und Steuerungsmöglichkeiten für generierte Sucherlebnisse. Cloudflare zufolge arbeitet Google an zusätzlicher Transparenz auf URL-Ebene im Zusammenhang mit Google-Extended; die Einführung wird innerhalb weniger Wochen erwartet.

Microsoft ist unter diesem spezifischen Mechanismus von den drei Anbietern am wenigsten vollständig aufgestellt. Bing unterstützt granulare Webmaster-Steuerungen, und Publisher können das NOARCHIVE-Meta-Tag verwenden, um bestimmte Nutzungen zwischengespeicherter oder angezeigter Inhalte einzuschränken.

Microsoft sagt, dass NOARCHIVE eine Seite nicht aus dem Suchranking entfernt. Website-Betreiber können zudem Bing Webmaster Tools für die Entfernung von Inhalten und die URL-Verwaltung nutzen.

Bingbot berücksichtigt Cloudflares domainweite Präferenz gegen KI-Training über robots.txt jedoch noch nicht automatisch. Cloudflare zufolge entwickelt Microsoft diese Funktion für Anfang 2027.

Bis dahin übermittelt die Auswahl von Disallow AI Training die beabsichtigte Einschränkung nicht automatisch über den neuen Workflow an Bing. Publisher, die Bing unmittelbar einschränken möchten, müssen weiterhin Microsofts bestehende Werkzeuge und Metadaten auf Seitenebene verwenden.

Microsoft hat seine Optionen zur KI-Steuerung als Möglichkeit beschrieben, die Auffindbarkeit über die Suche zu bewahren und zugleich einzuschränken, wie Inhalte in generativen Erlebnissen erscheinen. Cloudflares einheitlicher Schalter ist heute jedoch noch nicht vollständig mit diesen Steuerungen verbunden.

Diese Implementierungslücke ist die wichtigste Einschränkung beim Start. Cloudflare führt Applebot, Googlebot und Bingbot unter einem gemeinsamen Accountable-Label, doch nur Apple und Google bieten derzeit den spezifischen erweiterten User-Agent-Weg für Trainingspräferenzen.

Die Einbeziehung Microsofts beruht teilweise auf einer älteren Zusage. Das mag für die Etablierung eines kooperativen Standards angemessen sein, doch Publisher sollten den Unterschied zwischen verfügbarer Durchsetzung und zugesagter Kompatibilität verstehen.

Das gemeinsame Modell hängt außerdem von der jeweiligen Interpretation von Training durch die Betreiber ab. Das Vortraining eines neuen Modells, das Fine-Tuning eines bestehenden Systems, die Fundierung einer Live-Antwort und die Erstellung einer Suchzusammenfassung sind getrennte Aktivitäten. Eine „kein Training“-Entscheidung schließt nicht zwangsläufig jede KI-vermittelte Nutzung aus.

Cloudflare behandelt KI-Eingaben und KI-Zusammenfassungen ausdrücklich als unterschiedliche Fragen. Das verhindert, dass eine Präferenz stillschweigend nicht verwandte Nutzungen abdeckt, bedeutet aber auch, dass die neue Steuerung enger gefasst ist, als ihr schlichtes Dashboard-Label vermuten lässt.

Ein Publisher kann Modelltraining ablehnen und dennoch für KI-generierte Suchzusammenfassungen zugelassen bleiben. Ein anderer Publisher kann betreiberspezifische Zusammenfassungssteuerungen nutzen und gleichzeitig Training erlauben. Diese Entscheidungen können zu unterschiedlichen Ergebnissen bei Traffic und Attribution führen.

Das Accountable-Framework ist daher am besten als Mindestvertrag zu verstehen. Es fordert Betreiber dazu auf, Zwecke zu trennen, Präferenzen zu respektieren, Einsichtsmöglichkeiten bereitzustellen und eine Trainingsablehnung nicht in der klassischen Suche zu bestrafen.

Es macht Apple, Google und Microsoft nicht technisch austauschbar. Ebenso wenig garantiert es, dass jede von diesen Unternehmen angebotene KI-Funktion unter dasselbe Opt-out fällt.

Der unmittelbare Wert liegt in der Bündelung. Cloudflare-Kunden erhalten einen zentralen Ort, um eine gemeinsame Präferenz auszudrücken, während die Betreiber diese Präferenz ihren bestehenden oder kommenden Steuerungen zuordnen.

Der langfristige Wert hängt davon ab, ob diese Zuordnungen transparent genug werden, damit ein Publisher sie auf URL-Ebene prüfen kann.

Die Einstellung ist ein Zustimmungssignal, kein Compliance-Nachweis

Cloudflare hat die Anweisung vereinfacht, kann aber nicht nachweisen, dass jede nachgelagerte Nutzung beendet wurde, nur weil eine Website diese Anweisung veröffentlicht hat.

Diese Einschränkung beginnt mit robots.txt. Die Datei wurde als freiwilliges Crawler-Protokoll konzipiert, nicht als Zugangskontrollsystem. Konforme Crawler lesen sie und passen ihr Verhalten an. Ein Betreiber, der sie ignoriert, kann weiterhin öffentlich verfügbare Seiten anfragen, sofern keine andere Kontrolle den Traffic blockiert.

Cloudflare kann Entscheidungen an seinem Netzwerk-Edge durchsetzen, wenn es einen Crawler erkennt. Dadurch ist eine Sperrung stärker als ein Präferenzsignal. Die Durchsetzung hängt jedoch von einer zuverlässigen Identifizierung ab, und User-Agent-Strings können von nicht zugehörigen Bots kopiert werden.

Programme für verifizierte Bots verringern dieses Risiko, indem sie Anfragequellen anhand von Informationen prüfen, die Betreiber bereitstellen. Kryptografische Authentifizierung könnte stärkere Nachweise liefern, doch ihre Verbreitung auf dem Crawler-Markt ist weiterhin unvollständig.

Selbst eine verifizierte Anfrage zeigt, wer eine Seite abgerufen hat, nicht jedoch zwangsläufig jede spätere Nutzung ihres Inhalts. Ein Crawler-Betreiber muss intern zwischen Suchindexierung, Modelltraining, Antwortgenerierung und anderer Verarbeitung trennen.

Die Accountable-Anforderungen von Cloudflare adressieren diese Vertrauenslücke durch Berichterstattung und Verpflichtungen. Transparenz auf URL-Ebene sollte Publishern helfen zu erkennen, welche Seiten für Training verfügbar wurden und wie Inhalte in der Suche erschienen.

Das Schlüsselwort lautet „sollte“. Apples Inspektionssystem befindet sich noch in der Entwicklung, Googles zusätzliche Werkzeuge folgen erst, und Microsofts domainweite robots.txt-Unterstützung ist für Anfang 2027 vorgesehen.

Die Kennzeichnung verbindet daher aktuelle Fähigkeiten mit zukünftigen Zusagen. Cloudflare behauptet nicht, dass alle vier Anforderungen heute identische Produktionsimplementierungen haben.

Publisher sollten „Disallow AI Training“ auch nicht als universelle rechtliche Lösung verstehen. Urheberrechtliche Ausnahmen, vertragliche Bedingungen, Unterschiede zwischen Rechtsordnungen und frühere Datensammlungen sind separate Fragen. Eine neue Präferenz kann Material nicht rückwirkend aus einem bestehenden Modell entfernen.

Die Einstellung regelt das zukünftige Crawler-Verhalten, wie es von teilnehmenden Betreibern und Cloudflare umgesetzt wird. Sie bestätigt nicht, dass zuvor gesammelte Kopien gelöscht wurden. Sie legt auch nicht fest, wie ein trainiertes Modell Informationen möglicherweise speichert oder reproduziert.

Eine weitere Unsicherheit betrifft die Klassifizierung. Cloudflare ordnet Search-, Training- und Agent-Verhalten teilweise anhand von Betreiberangaben und weiteren beobachteten Informationen zu. Der angegebene Zweck eines Crawlers kann sich ändern, und ein Dienst kann mehrere Produkte unterstützen.

Wenn Klassifizierungen hinter Produktänderungen zurückbleiben, könnte eine Richtlinie mehr Aktivitäten zulassen, als ein Publisher erwartet. Transparente Änderungsprotokolle und unabhängiges Monitoring werden ebenso wichtig sein wie das ursprüngliche Dashboard-Design.

KI-Zusammenfassungen legen eine noch größere Lücke offen. Training bestimmt, ob Inhalte zur Modellentwicklung beitragen. Zusammenfassungen bestimmen, ob aktuelle Inhalte in eine Antwort umgewandelt werden, die den Bedarf an einem Besuch reduzieren kann.

Cloudflare verweist auf Forschungsergebnisse, die zeigen, dass KI-Zusammenfassungen im Suchverhalten bereits verbreitet sind. Eine Studie zum Suchverhalten ergab, dass Nutzer seltener auf Ergebnislinks klickten, wenn eine KI-Zusammenfassung erschien.

Das ist nicht dasselbe Problem wie Training. Ein Publisher könnte Training erfolgreich ablehnen und dennoch Besuche verlieren, wenn ein Suchprodukt frisch indexiertes Material zusammenfasst.

Cloudflare sagt, dass Accountable-Betreiber ein Opt-out für KI-Zusammenfassungen direkt und letztlich auch über Cloudflare anbieten müssen. Das nächste Ziel ist eine granularere Kontrolle darüber, wie viel Inhalt eine Zusammenfassung enthalten darf.

Dieser Plan erkennt eine Schwäche binärer Zustimmung an. Ein kurzes Zitat mit einem klaren Link zuzulassen, unterscheidet sich davon, eine detaillierte Antwort zu erlauben, die die Quelle ersetzt. Beides könnte technisch als Zusammenfassungsnutzung gelten.

Auch Geschäftsmodelle verändern die akzeptable Balance. Ein werbefinanzierter Publisher benötigt Besuchsvolumen, weil Impressionen Umsätze stützen. Ein Händler könnte weniger Besuche akzeptieren, wenn KI-Referrals zu mehr Käufen führen. Ein Abo-Publisher könnte Attribution und Wiedererkennung bei Lesern höher bewerten als reine Klickzahlen.

Cloudflare hat sich auf Schätzungen Dritter berufen, nach denen KI-Referrals höhere Konversionsraten erzielen können als traditionelle Such-Referrals. Diese Zahlen variieren je nach Datensatz und Methodik und sollten daher nicht als universeller Ausgleich für verlorenen Traffic betrachtet werden.

Das eigentliche Messproblem ist kausal. Ein Publisher muss wissen, welcher Crawler auf eine URL zugegriffen hat, welches Produkt sie verwendet hat, ob eine Zusammenfassung erschien, wie viel Inhalt sie anzeigte und ob die Interaktion zu einem Besuch führte.

Den meisten Organisationen fehlt diese vollständige Kette heute. Serverprotokolle zeigen Anfragen, während Suchkonsolen Impressionen und Klicks zeigen. Keines von beidem allein belegt, wie Inhalte durch ein KI-Produkt geflossen sind.

Die neuen Steuerungen verbessern die Handlungsmacht, bevor sie vollständige Rechenschaftspflicht schaffen. Sie ermöglichen Publishern, eine engere Richtlinie zu erklären und stärkere Sperren für Crawler anzuwenden, die sich nicht für die Accountable-Ausnahme qualifizieren.

Sie machen Monitoring nicht überflüssig. Publisher sollten nach Änderungen ihrer Einstellungen Suchabdeckung, Crawler-Protokolle, Referral-Muster und die öffentlichen Ausgaben großer KI-Produkte prüfen.

Für Teams, die Forschung, Dokumentation oder institutionelles Wissen pflegen, ist die Crawler-Richtlinie nur eine Ebene der Informationsgovernance. Eine durchsuchbare Wissensdatenbank kann den Quellkontext intern bewahren, selbst wenn externe Plattformen die öffentliche Version zusammenfassen.

Die skeptische Schlussfolgerung ist einfach. Cloudflare hat eine glaubwürdige Steuerungsoberfläche geschaffen, doch Compliance bleibt ein System aus technischer Durchsetzung, freiwilligen Standards, Betreiberpolitik und künftiger Transparenz.

Einen Crawler als Accountable zu bezeichnen, hebt den erwarteten Standard an. Das zugrunde liegende Vertrauensproblem verschwindet dadurch nicht.

Drei Signale werden zeigen, ob das neue Modell funktioniert

Der nächste Test besteht darin, ob Cloudflares gemeinsame Richtlinie messbares Verhalten erzeugt, nicht darin, ob mehr Unternehmen ihre Sprache unterstützen.

Das erste Signal ist Microsofts zugesagte Unterstützung für eine domainweite Präferenz gegen Training in robots.txt. Cloudflare zufolge ist diese Funktion für Anfang 2027 vorgesehen.

Eine funktionierende Implementierung würde die größte aktuelle Lücke unter den drei Crawler-Betreibern mit gemischter Nutzung schließen. Sie würde derselben Cloudflare-Einstellung ermöglichen, Bing eine Trainingsablehnung mitzuteilen, ohne eine separate NOARCHIVE-Implementierung oder einen Entfernungsworkflow zu verlangen.

Eine Verzögerung würde die Accountable-Kennzeichnung schwächen, weil einer ihrer wichtigsten Teilnehmer weiterhin auf manuelle oder seitenbasierte Alternativen angewiesen wäre. Die Implementierung sollte zudem klarstellen, welche Microsoft-KI-Nutzungen unter „Training“ fallen und welche weiterhin durch separate Steuerungen geregelt werden.

Das zweite Signal sind Berichte auf URL-Ebene von Apple und Google. Publisher benötigen mehr als die Bestätigung, dass eine Domain-Präferenz existiert. Sie müssen wissen, auf welche Seiten zugegriffen wurde, welche Nutzungen erlaubt waren und ob die Präferenz die spätere Verarbeitung verändert hat.

Googles zugesagte Ergänzungen im Zusammenhang mit Google-Extended liefern einen frühen Test. Apples geplante Inspektionsfunktion liefert einen längerfristigen. Nützliche Berichte sollten spezifisch genug sein, um Crawler-Zugriffe mit Suchleistung und KI-Sichtbarkeit zu vergleichen.

Eine allgemeine Dashboard-Zahl würde nur begrenzte Rechenschaftspflicht bieten. Aufzeichnungen auf Seitenebene, verständliche Zweckbezeichnungen und stabile historische Daten würden Cloudflares Behauptung stärken, dass Publisher fundierte Entscheidungen treffen können.

Das dritte Signal ist Cloudflares Arbeit an Steuerungen für KI-Zusammenfassungen. Opt-outs vom Training lösen nur einen Teil des Konflikts für Publisher. Suchgenerierte Antworten können den Traffic beeinflussen, selbst wenn keine Erlaubnis für Modelltraining vorliegt.

Cloudflares geplante Steuerung darüber, wie viel Inhalt in einer Zusammenfassung erscheint, ist ehrgeiziger als ein einfaches Opt-out. Sie würde von den Betreibern verlangen, eine gemeinsame Präferenz einheitlich zu interpretieren und genügend Daten offenzulegen, damit Publisher das Ergebnis bewerten können.

Ein Erfolg würde das übergeordnete Prinzip hinter Cloudflare Disallow AI Training stärken: Zugriff sollte zweckgebunden, messbar und durch den Eigentümer der Inhalte veränderbar sein. Ein Scheitern würde Publisher dazu zwingen, sich bei jeder Such- und KI-Plattform mit getrennten Steuerungen auseinanderzusetzen.

Die praktische Reaktion besteht heute darin, den Start als Richtlinien-Upgrade zu behandeln, nicht als Garantie, die man einmal einstellt und dann vergisst. Website-Betreiber sollten die migrierten Einstellungen für jede Domain überprüfen – insbesondere, wenn sie zuvor eine umfassende KI-Sperre aktiviert hatten.

Sie sollten bestätigen, ob Search weiterhin erlaubt ist und ob bei Training jetzt Disallow AI Training statt Block angezeigt wird. Die vollständige Auswahl von Block kann Applebot, Googlebot und Bingbot stoppen – mit einem anderen Ergebnis als der Veröffentlichung einer Präferenz gegen das Training.

Teams sollten außerdem dokumentieren, warum jede Kategorie erlaubt oder abgelehnt wird. Suche, Training und Agents erfüllen unterschiedliche Zwecke; die Richtlinie sollte daher das Erlösmodell der Website und die Beziehung zu ihrer Zielgruppe widerspiegeln.

Nach jeder Änderung sollten Crawler-Antworten und die Indexierung überwacht werden. Ein Rückgang der Sichtbarkeit in der Suche könnte darauf hindeuten, dass die falsche Einstellung gewählt wurde oder eine andere Firewall-Regel die Präferenz überschreibt.

Die gleiche Prüfung sollte wichtige Subdomains einschließen. Dokumentationen, Support-Center, Blogs und Anwendungsseiten können unterschiedliche Konfigurationen haben, selbst wenn sie unter derselben Marke laufen.

Der Start von Cloudflare ist wichtig, weil er eine künstliche Binärentscheidung durch eine realistischere Wahl ersetzt. Eine Website sollte nicht gezwungen sein, Material für die Modellentwicklung bereitzustellen, nur um in einem herkömmlichen Suchindex sichtbar zu bleiben.

Die Glaubwürdigkeit des Systems wird jedoch von überprüfbaren Ergebnissen abhängen. Microsoft muss seine Integration abschließen, Apple und Google müssen nützliche Prüfmechanismen bereitstellen, und Cloudflare muss die zusammenfassende Steuerung in etwas verwandeln, das Publisher messen können.

Vorerst bietet Cloudflare Disallow AI Training Website-Betreibern eine klarere Anweisung und einen sichereren Mittelweg. Die nächste Frage lautet, ob die größten Crawler-Betreiber diese Anweisung ausreichend beobachtbar machen, um ihr vertrauen zu können.

Überprüfen Sie die drei Crawler-Richtlinien Ihrer Domain, dokumentieren Sie das beabsichtigte Ergebnis und beobachten Sie nach jeder Änderung die Sichtbarkeit in der Suche. Bleibt der Traffic stabil, während der Zugriff für Trainingszwecke zurückgeht, hat das gemeinsame Modell seine erste praktische Bewährungsprobe bestanden.