Wir hatten Cloudflare Bot Fight Mode aktiv. Auffälliger Traffic kam trotzdem bis an die Website.
Browser-Challenges halfen nach unserer Betreibererfahrung ebenfalls nicht zuverlässig. Dasselbe galt für einen zuvor ausprobierten Ansatz namens „precursor“. Entscheidend war am Ende nicht eine weitere generische Bot-Funktion, sondern eine Regel, die genau auf die tatsächlich beobachteten Request-Muster zugeschnitten war.
Unsere KI-Agenten haben zwei unterschiedliche Scraping-Muster aus dem Traffic herausgearbeitet und in eine gezielte Cloudflare-Blockstrategie übersetzt. Die Regeln kombinieren Browsermerkmale, Fetch Metadata, Quellnetze, Referrer, Einstiegsseiten und Cloudflares Kennzeichnung verifizierter Crawler. Passende Requests werden direkt am Edge mit HTTP 403 beendet.
Dabei veröffentlichen wir bewusst nicht die vollständigen Fingerprints. Eine Anti-Scraping-Regel ist kein guter Ort für ein öffentliches Changelog an die Scraper.
Was uns überhaupt auffiel
Der erste Hinweis kam nicht aus einem einzelnen Security-Event, sondern aus der Kombination mehrerer Messpunkte.
Ein Minilytics-Snapshot zeigte 544 direkte Sitzungen bei null gemessenen Outbound-Konversionen. Zwischen zwei abgeschlossenen Stunden stiegen die direkten Sitzungen von 24 auf 163.
Gleichzeitig sah Cloudflare in einem untersuchten 30-Minuten-Fenster ungefähr 17.700 HTTP-Anfragen, von denen rund 15.400 den Origin erreichten. Ein fünfminütiger Origin-Ausschnitt enthielt 1.980 Requests von 1.238 unterschiedlichen IP-Adressen.
Wichtig ist die Trennung der Größen: Ein HTTP-Request ist keine Sitzung. Und „null Konversionen“ bedeutet bei uns in diesem Kontext null ausgelöste konfigurierte Outbound-Events – nicht nachgewiesen null Verkäufe oder null Umsatz.
Wir hatten damit aber genug Signal, um den Traffic genauer zu zerlegen.
Muster 1: Der Browser sagte Chrome – die Request-Metadaten passten nicht dazu
Die erste große Gruppe rotierte massiv über IP-Adressen und Länder. Die Clients präsentierten sich als Windows-Chrome-Browser und wechselten zwischen mehreren Chrome-Identitäten.
Im untersuchten Ausschnitt gehörten 1.628 Requests von 1.120 IP-Adressen in 100 Ländern zu diesem Muster. Ein großer Teil davon fragte zusätzlich Next.js-Seitendaten ab.
Das allein ist noch kein Bot-Nachweis. RSC-Requests entstehen auch bei normalem Browsen auf Next.js-Seiten.
Interessant wurde der Widerspruch an einer anderen Stelle: Die Requests behaupteten eine moderne Browseridentität, aber ein Fetch-Metadata-Merkmal, das wir bei dieser Request-Klasse erwartet hätten, fehlte vollständig.
Unsere erste neue Blocklogik koppelt deshalb mehrere Bedingungen:
- Request an einen Srocket-Host
- GET
- passende Windows-Chrome-Identität aus dem beobachteten Muster
- fehlender Fetch-Metadata-Header
- kein von Cloudflare verifizierter Bot
- keine internen Next.js- oder API-Pfade
Die konkrete Versionsliste veröffentlichen wir nicht.
Das ist der entscheidende Unterschied zu einer groben „Chrome-Version X blockieren“-Regel: Nicht eine einzelne Eigenschaft löst den Block aus, sondern der Widerspruch zwischen behaupteter Browseridentität und dem tatsächlich gesendeten Request-Kontext.
Cloudflare stellt mit `cf.client.bot` ein Feld bereit, das bekannte gute Bots und Crawler kennzeichnet. Diese verifizierten Crawler schließen wir aus der Blocklogik aus.
Muster 2: Diesmal sah der Browser-Request plausibel aus
Kurz darauf zeigte sich ein zweites Muster.
Diese Requests hatten browserähnliche Header und verwendeten auch einen normalen `Sec-Fetch-Site`-Wert. Damit fielen sie nicht unter den ersten Fingerabdruck.
Hier lag das Signal in der Kombination aus Herkunft, Browserprofil und Zielseite.
Wir sahen direkte HTML-Einstiege aus einem rotierenden Pool von Quellnetzen. Die Requests nutzten nur wenige exakt wiederkehrende Browserprofile, kamen ohne Referrer und trafen gezielt eine kleine Gruppe unserer Vergleichsseiten.
Solche wechselnden Quellnetze sind auch der Grund, warum IP-Adressen allein als Fingerprint wenig taugen. Wer die technische Seite dahinter besser einordnen will, findet in unserem Proxy-Vergleich die Unterschiede zwischen gängigen Proxy-Typen und Anbietern.
Unsere zweite Blocklogik kombiniert deshalb:
- einen beobachteten Quellpool
- eines der exakt wiederkehrenden Browserprofile
- GET
- leeren Referrer
- eine kleine definierte Gruppe betroffener Einstiegsseiten
- keinen von Cloudflare verifizierten Bot
Wichtig: Wir sperren nicht pauschal ein komplettes ASN und nicht pauschal Besucher ohne Referrer. Erst die Kombination der Merkmale führt zum Block.
Auch die konkreten Netze, User Agents und Seitenkombinationen bleiben intern.
Warum `Sec-Fetch-Site: none` kein Bot-Signal ist
Das zweite Muster zeigt gut, warum einzelne Header gefährlich schlechte Blockkriterien sein können.
`Sec-Fetch-Site: none` ist laut MDN vollkommen normales Browserverhalten, etwa wenn jemand eine URL direkt in die Adresszeile eingibt oder ein Lesezeichen öffnet.
Ein Request mit diesem Wert ist also nicht automatisch verdächtig.
Genau deshalb blockieren wir diese Gruppe nur dann, wenn Quellpool, exaktes Browserprofil, leerer Referrer und betroffene Einstiegsseite gleichzeitig zusammenpassen.
Das ist enger als eine generische Bot-Regel – und absichtlich so.
Die KI hat nicht „einen Bot erkannt“ – sie hat zwei Regelmodelle daraus gebaut
Der für uns interessante Teil war nicht, dass ein Modell auf Traffic schaut und „Bot“ sagt.
Nützlich wurde die KI erst dort, wo aus vielen einzelnen Requests zwei unterscheidbare technische Muster entstanden:
1. Identitätswiderspruch: Browserprofil und Fetch Metadata passen nicht zusammen. 2. Quellen-Fingerprint: Herkunft, Browserprofil, direkter Einstieg und Zielseite treten wiederholt gemeinsam auf.
Aus diesen Mustern haben unsere KI-Agenten eine Cloudflare-Strategie abgeleitet, die wir anschließend gegen echte Requests und normale Browserzugriffe geprüft haben.
Das ist für uns die wesentlich interessantere Form von KI im Betrieb: nicht ein Chatbot, der Security erklärt, sondern Agenten, die reale Telemetrie in eine kontrollierte Edge-Regel übersetzen.
Wir haben bereits an anderer Stelle beschrieben, warum Bot-Traffic Attribution und Retargeting verfälschen kann. Gleichzeitig zeigt die aktuelle Debatte um Transparenzpflichten für KI-Crawler, wie schwer automatisierter Traffic inzwischen sauber zuzuordnen ist.
Kein weiteres Deployment: Die Regel sitzt direkt bei Cloudflare
Die finale Lösung läuft als bestehende Cloudflare Custom Rule mit der Aktion Block.
Wir mussten dafür weder die Anwendung deployen noch einen weiteren Regelplatz verbrauchen. Die bereits bestehende Scanner-/Flood-Regel wurde um die beiden zusätzlichen Muster erweitert.
Die Logik lässt sich bewusst nur auf Prinzip-Ebene zusammenfassen:
- Bereits bestätigte Scanner bleiben blockiert.
- Muster 1 greift nur, wenn Browseridentität und Fetch Metadata in der beobachteten Weise widersprüchlich sind, der Request ein GET ist, kein verifizierter Bot erkannt wird und keine internen Framework- oder API-Pfade betroffen sind.
- Muster 2 greift nur bei der Kombination aus beobachtetem Quellenpool, exakt wiederkehrendem Browserprofil, direktem Einstieg ohne Referrer und einer der betroffenen Einstiegsseiten.
- Erst wenn ein Zweig vollständig passt, folgt die Aktion Block.
Die konkreten Netze, Browserversionen, User Agents und die produktive Cloudflare-Expression veröffentlichen wir nicht. Mehr muss ein Scraper über die Regel nicht wissen.
Cloudflare selbst empfiehlt Custom Rules, wenn mehrere Request-Felder kombiniert werden müssen. Eine terminierende Block-Aktion greift dabei bereits auf Ebene der Custom Rules und lässt passende Requests nicht erst weiter in nachgelagerte Bot-Mechanismen laufen.
Was nach dem Aktivieren passiert ist
Wir haben nicht nur geprüft, ob Cloudflare die Regel akzeptiert. Wir haben kontrolliert, ob sie tatsächlich das gewünschte Muster trifft und normale Anfragen weiter funktionieren.
Die Kontrolltests ergaben:
- Testrequest mit dem ersten Fingerabdruck: Cloudflare 403
- dieselbe Browserfamilie mit normalen Navigationsmerkmalen: 200
- öffentliche Vergleichsseite bei normalem Zugriff: 200
- echtes Event aus dem zweiten Muster: Custom rules / Block
- angezeigte Regelmatches während der Prüfung: rund 1.300
Besonders deutlich war der Origin-Verlauf: Beim ersten Muster fielen die passenden Requests von 626 in einer vollständigen Minute auf null im letzten 18-Sekunden-Intervall des untersuchten Ausschnitts.
In einer späteren Minilytics-Prüfung kamen über 156 Sekunden keine neuen direkten Sitzungen ohne Outbound-Konversion hinzu.
Das beweist nicht, dass unerwünschter Traffic für immer verschwunden ist. Es zeigt aber, dass die neue Regel die beobachteten Muster tatsächlich am Edge abgefangen hat.
Warum wir nicht behaupten, dass es keine False Positives geben kann
Wir haben die Regel mit normalen browserartigen Zugriffen getestet und bewusst eng eingegrenzt.
Trotzdem wäre „garantiert ohne Fehlalarm“ unseriös.
Ein echter direkter Besucher könnte theoretisch ebenfalls mehrere Merkmale des zweiten Musters gleichzeitig erfüllen – etwa aus einem betroffenen Quellnetz, mit einem der wiederkehrenden Browserprofile und auf einer der betroffenen Seiten.
Deshalb behandeln wir die Regel nicht als universelle Anti-Bot-Lösung, sondern als Incident-spezifischen Fingerprint mit dokumentierter Rücknahmemöglichkeit.
Dasselbe gilt für das erste Muster. Ändern Scraper ihre Request-Identität, kann auch ein Fingerprint an Wirkung verlieren.
Der Vorteil liegt gerade darin, dass wir keine magische Dauerlösung behaupten: Wir können beobachten, neu klassifizieren und die Edge-Regel gezielt nachziehen.
Was wir aus dem Incident mitnehmen
Bot Fight Mode war nicht nutzlos. Aber eine generische Bot-Abwehr konnte diese beiden Verkehrsmuster bei uns nicht ausreichend stoppen.
Erst die Kombination aus eigener Telemetrie, KI-gestützter Musteranalyse und einer präzisen Cloudflare Custom Rule hat den Unterschied gemacht.
Für andere Websites sind unsere konkreten Fingerprints nicht übertragbar. Die Methode dagegen schon:
Nicht IP-Adressen hinterherjagen. Nicht einzelne Header isoliert sperren. Mehrere unabhängige Request-Merkmale kombinieren, verifizierte Crawler ausnehmen, normale Browserzugriffe testen und die Wirkung danach messen.
So haben unsere KI-Agenten aus einem Traffic-Problem eine überprüfbare Edge-Regel gemacht – ohne den Scrapern eine universelle Anleitung mitzuliefern.