Kurz gesagt: Am 15. September 2026 hat Cloudflare Disallow AI Training und neue empfohlene Defaults angekündigt, die Search-, Training- und Agent-Traffic getrennt behandeln. Das kommt zusätzlich zu Precursor (verhaltensbasierte Erkennung auf Session-Ebene, Rollout im Juli) und dem üblichen Stack aus Managed Challenges / Turnstile. Wenn Scrapes oder Monitore in diesem Monat hängen geblieben sind: Sie bilden sich das nicht ein.
Kommt der Job trotzdem durch? Das ist für die meisten Data-Teams die einzige Frage, die zählt. Piloterr fährt diese Art von Collection bereits über WebUnlocker und die anderen Website-Produkte.
Was Cloudflare im September tatsächlich ausgeliefert hat
Die datierte Ankündigung ist das Bot-Management- / AI-Crawl-Control-Update vom 15. September, beschrieben im Cloudflare-Blogpost und in der Pressemitteilung.
Was veröffentlicht wurde:
- Eine neue Einstellung Disallow AI Training, damit eine Site Training ablehnen und trotzdem in der Suche bleiben kann (für Crawler, die Cloudflare als Accountable einstuft).
- Klarere Bedeutung von Block und Block on pages with ads: Diese Aktionen gelten jetzt auch für Mixed-Use-Crawler wie Googlebot, Bingbot und Applebot. Wer nur Training stoppen und Suche behalten will, nimmt Disallow AI Training statt Block.
- Abkündigung des groben Schalters Block AI Bots zugunsten getrennter Search-, Training- und Agent-Controls.
- Bot Preference Sync ersetzt Managed Robots.txt.
- Für neue Domains, die ab diesem Datum onboarden, empfohlene Presets auf ad-finanzierten Sites: Search erlaubt, Training auf Disallow AI Training, Agents auf Seiten mit Ads blockiert. Der Juli-Changelog hatte diese Defaults schon angedeutet.
Bestehende Zones wurden nach ihren bisherigen Einstellungen migriert. Viele Betreiber haben nach dem News-Zyklus trotzdem manuell umgestellt. In beiden Fällen stufen mehr Domains Chat-Fetcher, Browser-Agenten und training-ähnliche Crawler jetzt standardmäßig als unerwünscht ein.
Das ist eine offizielle Produktänderung. Was viele Collectors im Browser beobachten, ist parallel der ältere Challenge-Stack, der in der Praxis strenger wirkt, weil mehr Zones Features aktivieren.
Warum Jobs, die früher durchkamen, jetzt scheitern
Cloudflares eigener Changelog und die Precursor-Docs beschreiben eine Verschiebung, die im Frühsommer begann und weiter auf Kunden-Zones landet: Erkennung über die gesamte Session, nicht nur ein Tor am Eingang.
Precursor injiziert clientseitiges JavaScript, sammelt über die Zeit Verhaltenssignale und aktualisiert den Session-State im Cookie cf_clearance. Cloudflare schreibt, dass Clearance mitten in der Session reduziert oder invalidiert werden kann und dass zusätzliche Challenges feuern können, nachdem ein Besucher schon einmal „durch“ war. Ein Page-Refresh wischt diese Session-Signatur nicht so weg wie früher ein einmaliger CAPTCHA.
Ein Monitor, der beim ersten HTML-Fetch menschlich wirkt, kann also beim dritten Pagination-Hop trotzdem eine Challenge bekommen. Ein Preis-Scraper, der ein Interstitial räumt und dann Produkt-URLs in enger Schleife abklopft, sieht unter der neuen Search-/Training-/Agent-Taxonomie plötzlich nach Agent-Traffic aus.
Dafür muss man kein benannter KI-Crawler sein. Site-Betreiber schalten Agent- und Training-Controls um, weil sie die September-Defaults gesehen haben. Ihr legitimer B2B-Enrichment-Job landet im selben automatisierten Eimer, sofern der Publisher keine Ausnahme eingerichtet hat.
„HTTP sieht gut aus“, aber Sie sind nicht auf der echten Seite
Hier verstummen Pipelines aus dem falschen Grund.
Cloudflare dokumentiert, dass eine volle Interstitial-Challenge-Page den Response-Header cf-mitigated: challenge setzt, content-type: text/html liefert und (bei Managed Challenge / Under Attack Mode) ein 403 mit Challenge-HTML statt Ihres Produkt-Payloads zurückgibt. Siehe Detect a Challenge Page response und Error-Page-Typen.
Im Feld sagen Teams trotzdem oft „HTTP 200, aber auf einer Challenge stecken geblieben“. Meist meinen sie einen weicheren Fehler als das dokumentierte Interstitial.
Manche Collectors prüfen nur Statuscodes und werten jeden HTML-Body als Erfolg. Challenge-HTML ist immer noch HTML. Steht der Check auf status < 400, speichern Sie am Ende „Checking your browser…“ als Preis.
JavaScript Detections und Precursor sind noch einmal anders: Cloudflare injiziert sie in HTML-Antworten, ohne den Besucher wie bei einem Interstitial anzuhalten. Sie bekommen einen glaubwürdigen 200, während die Edge die Session weiter scored und später eine Challenge feuert oder den Bot-Score absenkt. Eingebettetes Turnstile auf einem Formular, das schon 200 geliefert hat, wirkt aus Operator-Sicht genauso. Die Seite lädt. Die geschützte Aktion endet erst, wenn das Widget durchkommt.
Managed Challenges bleiben adaptiv. Viele Menschen sehen eine kurze, nicht interaktive Wartezeit; Traffic, der automatisiert wirkt, wird zur Interaktion aufgefordert. Das steht in den Challenge-Pages-Docs, nicht in einer September-only Release Note. September hat mehr Policies gegen Agent- und Training-Traffic geschoben. Die Challenge-Maschine ist das, was diese Policies aufrufen.
Was Operatoren bis in den Herbst erwarten sollten
Nicht jede Zone hat am selben Tag umgestellt. Wer Collectors gegen Cloudflare-Properties fährt, sollte trotzdem mit mehr interaktiven Managed Challenges rechnen, wenn Fingerprint und Verhalten abweichen, und mit Clearance, der den ganzen Job nicht hält, sobald Precursor auf Maximize Security steht oder die Session driftet.
Weiche Fehler bleiben häufig: Antworten, die erfolgreich wirken, bis Sie cf-mitigated, Body-Länge oder die tatsächlich extrahierbaren Felder prüfen. Ad-finanzierte Sites mit den neuen Onboarding-Presets behandeln mehr von dem, was Cloudflare Agent-Traffic nennt, als unerwünscht. Homegrown-Stacks, die Cloudflare 2024 oder Anfang 2025 „gelöst“ hatten, brauchen oft einen weiteren Wartungszyklus. Session-Scoring und Agent-Defaults ändern den Fehlermodus schneller, als TLS-Fingerprint-Tweaks allein nachziehen können.
Wer die Collectors selbst betreibt, sollte Retries einplanen, die trotzdem Challenge-HTML liefern, und Validierung, die auf Inhalt statt nur auf Status schaut.
Wenn die Pipeline an Cloudflare hängt
Die meisten Teams, mit denen wir sprechen, wollen die Daten raus, nicht ein zweites Vollzeit-Anti-Bot-Projekt. Piloterr fährt Collectors gegen Cloudflare-geschützte Ziele bereits über Website WebUnlocker (Allowlist-Domains, HTTP-Modus) und Website Rendering, wenn die Seite selbst einen echten Browser braucht. Welches Tool wohin passt: Crawler vs Rendering vs WebUnlocker.
Die Cloudflare-Änderungen vom September sind real. Solche Vendor-Shifts abzufangen ist Teil unserer Arbeit, damit Ihre Product-Roadmap das nicht leisten muss.
Brauchen Sie nach den Mid-September-Defaults eine Domain-Prüfung? Starten Sie mit Website Rendering, wenn ein echter Browser nötig ist, oder mit den WebUnlocker-API-Docs für allowlistete HTTP-Ziele. Schreiben Sie uns über die Site, wenn Sie hören wollen, ob das Ziel im Scope liegt und welche Success Rate realistisch ist.
