Cloudflare KI-Bot-Standards und Pay Per Crawl: Was 2026 neu ist

Die KI-Bot-Standards von Cloudflare treffen Stand Oktober 2026 vor allem Crawler, die offen sagen, wer sie sind. Eine neue Domain, deren Betreiber angibt, dass dort Werbung läuft, startet jetzt mit abgelehntem KI-Training und auf Werbeseiten gesperrten KI-Agenten, während Such-Crawler zugelassen bleiben. Preis-Monitoring, SEO-Audits und anderer „Data Collection“-Traffic fallen nicht unter diese drei Presets und werden nach denselben Bot-Regeln beurteilt wie bisher. Was sich für ein Datenteam ändert, ist keine neue Mauer. Es ist ein stärkerer Grund, ein Bot zu sein, der sich zu erkennen gibt, mit einem Bezahlweg (Pay Per Crawl und seit dem 30. September Pay Per Use) für Inhalte, die bisher komplett verschlossen waren.

Ein Großteil der Berichterstattung, die man findet, ist bereits veraltet. Cloudflare kündigte am 1. Juli 2026 einen Plan an und lieferte am 15. September eine überarbeitete Fassung aus. Die folgende Zeitleiste hält sich an das, was laut Cloudflares eigenem Blog und eigener Dokumentation tatsächlich ausgeliefert wurde.

Wie die KI-Bot-Standards von Cloudflare Stand Oktober 2026 aussehen

Kurzfassung: Search, Agent und Training sind jetzt in jedem Cloudflare-Tarif, auch im Free-Tarif, drei getrennte Schalter, jeweils mit den Optionen Allow, Block on pages with ads oder Block. Training hat zusätzlich eine vierte Option, Disallow AI Training. Neue Domains erhalten ein empfohlenes Preset, abhängig davon, ob der Betreiber mit Werbung Geld verdient. Bestehende Domains behalten die Wirkung ihrer bisherigen Einstellungen.

Der Juli-Plan im Vergleich zu dem, was am 15. September ausgeliefert wurde

Laut der Ankündigung vom Juli sollten Mehrzweck-Crawler „wie Googlebot, Applebot und BingBot blockiert werden“, sobald ein Kunde Training sperrt. Damit wären Websites aus der Suche verschwunden. Der Beitrag vom 15. September hat das ersetzt. Bei Disallow AI Training schreibt Cloudflare eine Präferenz gegen Training in die robots.txt. Accountable-Mehrzweck-Crawler (Applebot, Bingbot, Googlebot) bleiben für die Suche zugelassen, und „jeder andere Trainings-Crawler wird blockiert, einschließlich der reinen Trainings-Crawler von Amazon, Anthropic, Meta und OpenAI“. Nur ein ausdrückliches Block oder Block on pages with ads stoppt jetzt Googlebot und damit auch die Suche.

Die Presets, die Cloudflare jetzt beim Anlegen einer neuen Domain anbietet:

Für bestehende Domains besagen Cloudflares Migrationshinweise, dass eine Domain, die den alten Schalter „Block AI bots“ nie aktiviert hatte, bei allen drei Kategorien auf Allow abgebildet wird. Domains, bei denen er aktiv war, wechseln zu Disallow AI Training. Laut dem Bericht von TechCrunch vom 1. Juli sollten die neuen Standards auch „alle bestehenden Free-Kunden“ erreichen. Cloudflares eigene Migrationstabellen vom 15. September zeigen das nicht. Prüfen Sie also Ihre Zielseiten, statt das eine oder das andere anzunehmen.

Search, Agent, Training: wie ein Request klassifiziert wird

Cloudflare klassifiziert Bots, nicht einzelne Requests isoliert. Ein bekannter Bot erhält in BotBase, dem Bot-Verzeichnis von Cloudflare, ein oder mehrere Verhaltenslabels. Jedes Preset blockiert dann laut der Dokumentation zu Block AI Bots „verifizierte Bots, die mit diesem Verhalten klassifiziert sind, sowie weitere unverifizierte Bots, die unter diese Klassifizierungen fallen“.

• Search: Crawling zum Aufbau eines Suchindex oder einer RAG-Datenbank, die später Fragen beantwortet.
• Agent: nutzergesteuert, meist in Echtzeit: Chat-Fetcher wie ChatGPT-User oder Browser-Use-Agenten, die Chrome steuern.
• Training: Crawling, um ein Modell zu trainieren oder per Fine-Tuning anzupassen.

Die Seite zu verifizierten Bots führt acht weitere Verhaltensweisen auf, die nicht zu den drei KI-Presets gehören. Das sind Transact, Data Collection („Preis-Scraping, Wettbewerbsanalyse und Analytics durch Dritte“), Security Testing, SEO, Ads Verification, Social/Link Preview, Feed Fetching sowie Monitoring & Operations. Ein Crawler mit mehreren Zwecken wird jetzt unter allen geführt, und die restriktivste zutreffende Regel gewinnt.

Die Identität stammt aus einer von drei Quellen:

1. Verifizierter Bot oder Agent. Der Betreiber hat sich beworben, und Cloudflare prüft die Identität deterministisch. Das heißt: eine Web-Bot-Auth-Signatur (Ed25519-Schlüssel, veröffentlicht unter /.well-known/http-message-signatures-directory, gemäß IETF-Entwürfen), eine veröffentlichte IP-Liste mit stabilem User-Agent oder Reverse DNS. Seit dem 1. Juli 2026 zählen signierte Agenten als Verified. Sie werden als Direct (ein Betreiber) oder Intermediary (eine Plattform, die viele Endnutzer steuern) gekennzeichnet.
2. Bekannt, aber unverifiziert. Der Traffic passt zu einem Muster, das Cloudflare einer Crawler-Kategorie zuordnet, etwa die Heuristiken, die nach der Perplexity-Untersuchung hinzukamen.
3. Alles andere. Hier entscheidet die allgemeine Bot-Erkennung: Bot-Score, Fingerprints, Challenges. Diese Ebene gab es schon vor alldem. Unser Beitrag zu den Interna von Turnstile erklärt, wie die Challenge-Seite eine Session bewertet.

Verifiziert zu sein heißt nicht mehr, eingelassen zu werden. Cloudflare hat den Begriff am 1. Juli 2026 neu definiert: Ein Verified Bot ist innerhalb der Kategorie „zulässig“, die der Website-Betreiber erlaubt. Ehrliche Identifikation sorgt für eine korrekte Einstufung. Ob Sie hineinkommen, entscheidet weiterhin der Betreiber.

Was „standardmäßig gesperrt“ für einen konkreten Request bedeutet

„Gesperrt“ bedeutet hier bis zu drei getrennte Mechanismen. Welchen Sie treffen, bestimmt, was Ihr Crawler zu sehen bekommt.

1. Eine Präferenz in der robots.txt

Bot Preference Sync (der Nachfolger der verwalteten robots.txt) stellt einer bestehenden robots.txt Regeln voran, die aus den Einstellungen der Zone generiert werden, sodass Ihre eigenen Disallow-Zeilen erhalten bleiben. Die verwaltete Datei im Beispiel aus der Dokumentation enthält eine Content-Signals-Zeile und Disallow-Regeln pro Crawler:

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

User-agent: GPTBot
Disallow: /

User-agent: Google-Extended
Disallow: /

In der Präambel heißt es, die Signale seien „ausdrückliche Rechtevorbehalte“ nach Artikel 4 der EU-Urheberrechtsrichtlinie für den digitalen Binnenmarkt (2019/790). Das hat in der EU rechtliches Gewicht für Text- und Data-Mining, auch wenn robots.txt an sich freiwillig ist.

2. Eine Sperre an der Edge

Sperrt die Zone Ihre Kategorie, wird der Request an der Cloudflare-Edge abgewiesen, bevor er den Origin erreicht. Pay Per Crawl dokumentiert diesen Fall als crawler-error: CrawlerForbidden mit HTTP 403. Bei Block on pages with ads kann derselbe Crawler auf einer URL ein 200 und auf einer anderen URL derselben Domain eine Sperre erhalten. Cloudflare erkennt werbeausspielende Seiten automatisch und erklärt, die Liste sei „zu groß und ändere sich zu häufig, um sie in robots.txt aufzuzählen“. Von außen lässt sich nicht vorhersagen, welche Seiten betroffen sind.

3. Ein Preis: HTTP 402 und Pay Per Crawl

Auf Zonen mit Pay Per Crawl (Stand Oktober 2026 noch eine geschlossene Beta) erhält ein verifizierter Crawler ohne Zahlungsabsicht einen 402 mit dem Preis:

HTTP/2 402
crawler-price: USD 0.01

Laut Cloudflares Dokumentation zum Crawlen von Seiten wiederholt der Crawler den Request mit genau einem der Header crawler-exact-price (muss crawler-price entsprechen) oder crawler-max-price. Der Zahlungs-Header muss in den Web-Bot-Auth-Komponenten von signature-input enthalten sein. Eine bezahlte 200-Antwort trägt crawler-charged: USD 0.01. Fehler kommen mit einem crawler-error-Header zurück. Zu den Codes gehören MissingCrawlerPrice (402), InvalidCrawlerMaxPrice (402), ConflictingPriceHeaders (400) und StrongAuthRequired (400). Bezahlen können nur verifizierte, signierende Crawler. Ein anonymer Scraper hat überhaupt keinen Bezahlweg. Eine Sperre durch WAF oder Bot Management hat zudem Vorrang vor der Aktion „charge“.

Wer einen Crawler betreibt, sollte sich angewöhnen, einen 402 als Datenpunkt zu behandeln, nicht als Fehler, den man durch Wiederholungen umgeht. Ein minimales Muster mit requests:

import requests

def fetch(url, session: requests.Session):
    r = session.get(url, timeout=30)
    if r.status_code == 402 and "crawler-price" in r.headers:
        # Kostenpflichtiger Inhalt: für eine Lizenz-/Budgetentscheidung festhalten.
        return {"url": url, "status": 402, "price": r.headers["crawler-price"]}
    if r.status_code == 403 and r.headers.get("crawler-error") == "CrawlerForbidden":
        # Der Betreiber lehnt diesen Crawler ab. URL verwerfen, nicht per Rotation umgehen.
        return {"url": url, "status": 403, "refused": True}
    r.raise_for_status()
    return {"url": url, "status": r.status_code, "body": r.text}

Pay Per Use, am 30. September als Beta gestartet, funktioniert anders. Es greift nicht zum Zeitpunkt des Requests. Ein Käufer definiert eine „Nutzung“ (etwa einen Auszug, der in einer KI-Suche ausgegeben wird), Publisher nehmen das Angebot an oder lehnen es ab, und der Käufer meldet jede Nutzung selbst an eine Cloudflare-API, die monatlich abrechnet. Die ersten namentlich genannten Partner waren laut TechCrunch Ceramic.ai und You.com.

Wer betroffen ist und wer nicht

Die neuen Standards ändern am meisten für Crawler, die sich als KI zu erkennen geben, und am wenigsten für Traffic, der nie in einer KI-Kategorie war. Umgehung zählt nicht als Ausnahme.

Ein Trainings-Crawler, der sich selbst identifiziert (GPTBot, ClaudeBot, CCBot, Bytespider usw.), ist der eindeutigste Fall. Auf einer neuen werbefinanzierten Domain wird er standardmäßig abgewiesen. Auf vielen anderen Zonen ist er gesperrt oder kostenpflichtig. Seine Optionen sind ehrliche: die Ablehnung respektieren, bezahlen, wo Pay Per Crawl oder Pay Per Use angeboten wird, oder direkt lizenzieren.

Ein KI-Agentenprodukt, das Seiten für einen Nutzer abruft, ist das neue Ziel. Agenten sind auf neuen werbefinanzierten Domains standardmäßig auf Werbeseiten gesperrt. Eine „Disallow“-Variante für Agenten gibt es noch nicht, weil kein robots.txt-ähnlicher Standard für Agenten existiert. Cloudflare will das erneut prüfen, sobald Vorschläge wie ai-prefs ausgereift sind. Requests zu signieren (als Signed Agent) sorgt zumindest dafür, dass Sie als Agent eingestuft werden und nicht als anonymer Bot. Das zählt auf jeder Zone, die Agenten zulässt.

Ein Scraper mit normalem Browser-User-Agent fällt nicht unter die „KI-Preset“-Logik, solange Cloudflare ihn keiner KI-Kategorie zuordnet. Sicher ist er deshalb nicht. Er bekommt es weiterhin mit Bot-Scoring, JavaScript-Challenges und Rate Limits zu tun. Wenn er tatsächlich einen Trainingsdatensatz oder eine Antwortmaschine füttert, tut er genau das, wofür Perplexity 2025 von der Liste flog. Cloudflare sperrt ausdrücklich „weitere unverifizierte Bots“, die unter die jeweilige Kategorie fallen. Wir helfen niemandem, einen KI-Crawler als menschlichen Besucher zu tarnen. Abgesehen von der Ethik ist das ein aussichtsloses Spiel, sobald das Netzwerk beginnt, Ihr Verhalten abzugleichen.

Ein internes Preis-Monitoring gehört zu Data Collection, das keines der drei Presets ist. Die Änderungen vom September allein ändern nichts an seinem Zugang. Entscheidend ist, was die Website ohnehin einsetzt: Bot Fight Mode, Bot-Management-Regeln, Rate Limits. Unser White-Hat-Leitfaden zu Cloudflare-Sperren geht diese Fehlercodes durch.

Entscheidungstabelle für Datenteams

Gehen Sie davon aus, was Sie sammeln und warum. Das bestimmt Ihre Kategorie, und die Kategorie bestimmt Ihre Optionen.

Zwei Hinweise zur Zeile Preis-Monitoring. Erstens bedeutet „Egress aus dem passenden Markt“, den Preis zu sehen, den ein lokaler Käufer sieht. Es bedeutet nicht, zu verbergen, was Sie sind. Bei ProxyHat ist das ein Flag im Benutzernamen, z. B. http://USERNAME-country-DE:PASSWORD@gate.proxyhat.com:8080. Unser Leitfaden zum Preis-Monitoring behandelt die Pipeline drumherum. Zweitens ist das Request-Volumen weiterhin der schnellste Weg, aufzufallen. Unser Erklärartikel zu Rate Limits beschreibt Backoff, das Websites tolerieren.

Warum werbefinanzierte Publisher das gefordert haben

Werbung zahlt sich nur aus, wenn ein Mensch die Seite sieht. In Cloudflares Worten: „Training ersetzt diesen Besuch durch eine Antwort; Agenten rufen die Seite ab, ohne dass jemand da ist, der die Werbung sieht.“ Deshalb sind die Presets für Werbeseiten strenger. Cloudflares Beitrag vom 15. September beziffert die Verteilung: Weniger als 1 % seiner Websites sperren Such-Bots, während 17 % irgendeinen Mechanismus gegen Training aktivieren. Publisher wollen auffindbar bleiben, aber Modelle nicht kostenlos mit Inhalten versorgen, und vor September konnten sie die Trainingsnutzung durch Googlebot nicht sperren, ohne die Google-Suche zu verlieren. Disallow AI Training und die Accountable-Zusagen sind Cloudflares Antwort auf dieses Dilemma. Pay Per Use ist der Versuch, aus einem „Nein“ ein „Ja, gegen Bezahlung“ zu machen.

Was sich dadurch nicht ändert

• Websites, die nicht bei Cloudflare sind. Akamai, DataDome, HUMAN und hauseigene Lösungen haben ihre eigenen Regeln.
• Allgemeine Bot-Abwehr. Bot-Scores, Turnstile, Rate Limiting und WAF-Regeln funktionieren wie bisher. Ein Data-Collection-Crawler kann von ihnen weiterhin gesperrt werden.
• Bing-Opt-out vom Training per robots.txt. Microsoft arbeitet an Unterstützung für No-Training in robots.txt mit Ziel Anfang 2027. Bis dahin übermittelt Disallow AI Training die Präferenz auf diesem Weg nicht an Bing.
• Vorhersagbarkeit. Die Werbeerkennung ist nicht dokumentiert, und Betreiber können Presets jederzeit ändern. Lesen Sie die robots.txt und die Response-Header jeder Zielseite; verlassen Sie sich nicht auf Blog-Zusammenfassungen (diese hier eingeschlossen).
• Ihre Rechtslage. Kategorielabels entscheiden keine Fragen zu Urheberrecht, Verträgen oder personenbezogenen Daten. Der Vorbehalt nach Artikel 4 über Content Signals gilt in der EU unabhängig von Ihrem Bot-Score.

Eine kurze Checkliste vor Ihrem nächsten Crawl

1. Halten Sie den Zweck jedes Crawlers schriftlich fest. Erledigt ein Bot Suche und Training, teilen Sie ihn auf. Cloudflare erfasst jetzt jeden Zweck, und die restriktivste Regel gewinnt.
2. Verwenden Sie einen ehrlichen, stabilen User-Agent mit Kontakt-URL. Das kostet nichts und ist Voraussetzung für die Verifizierung.
3. Lesen Sie die robots.txt einschließlich Content-signal. Werten Sie ai-train, search, ai-input und use aus, nicht nur Disallow.
4. Behandeln Sie 402 und crawler-error explizit. Protokollieren Sie Preise; setzen Sie Ablehnungen auf eine Do-not-fetch-Liste.
5. Ziehen Sie Web Bot Auth in Betracht, wenn Sie einen Agenten oder Crawler in großem Maßstab betreiben. Es ist Voraussetzung für Pay Per Crawl und der Weg zum Verified-Status.
6. Bevorzugen Sie lizenzierte Quellen (APIs, Datenpartnerschaften, Pay Per Use) für Inhalte, die Sie regelmäßig von Publishern brauchen, die kostenloses Crawling ablehnen.

Die Änderungen von 2026 weisen in eine Richtung: Crawler, die sagen, wer sie sind und was sie tun, haben mehr legitime Optionen als vor einem Jahr, getarnte Crawler weniger. Wenn Ihr Team unter diesen Regeln Infrastruktur für Agenten- oder LLM-Datenarbeit auswählt, zeigt unser Leitfaden zu Proxys für KI-Agenten, wo Proxys helfen und wo nicht.