Das meiste, was über Bot-Traffic geschrieben wird, ist entweder ein Verkaufsargument eines Anbieters oder eine Kriegsgeschichte von einer Website, die groß genug ist, um gezielt angegriffen zu werden. Dies ist weder das eine noch das andere. Es ist eine kleine Agentur-Website, ein Cloudflare-Konto und die Zahlen, die wir gefunden haben, als wir endlich richtig hingesehen haben.
Die Kurzfassung: 72,4 % der Requests an unsere Website trugen über 23 Stunden hinweg keinen erkennbaren Browser-User-Agent. Auf Chrome entfielen 19,7 %. Auf alle benannten Suchmaschinen-Crawler zusammen, Googlebot, Bingbot und Applebot, entfielen 3,5 %.
Diese letzte Zahl hat unser Denken umsortiert. Nahezu jedes Argument, das Sie zum Umgang mit Crawlern lesen, dreht sich um die benannte Minderheit, und die benannte Minderheit ist ein Rundungsfehler neben allem anderen, das an die Tür klopft.
Was wir tatsächlich gemessen haben
Alle Zahlen stammen aus Cloudflares GraphQL-Analytics für unsere eigene Zone, aus einem Fenster von 23 Stunden im August 2026. Nichts davon ist modelliert oder hochgerechnet.
| Client | Requests | Anteil |
|---|---|---|
| Nicht erkannt | 42.700 | 72,4 % |
| Chrome | 11.628 | 19,7 % |
| Bingbot | 1.523 | 2,6 % |
| Edge | 1.064 | 1,8 % |
| Firefox | 523 | 0,9 % |
| Googlebot | 362 | 0,6 % |
| Chrome Mobile | 318 | 0,5 % |
| Safari | 301 | 0,5 % |
| Applebot | 172 | 0,3 % |
| curl | 118 | 0,2 % |
An zwei vollen Tagen lag das Verhältnis von Requests zu Unique Visitors bei 6,5 und 6,6. Ein Mensch, der zwei oder drei Seiten liest, erzeugt keine sechseinhalb Requests, wenn man Assets herausrechnet, also dieselbe Geschichte aus einem anderen Blickwinkel.
Eine extreme Variante davon hatten wir früher im selben Monat gesehen. An einem Tag verdreifachten sich die Requests auf 173.093, während die Unique Visitors bei 7.527 stehen blieben. Verdreifachte Requests bei gleichbleibendem Publikum sind kein Wachstum, sondern ein Durchlauf, und die Pfadverteilung hat das bestätigt: Die meistabgerufene einzelne URL kam von dieser Summe auf gerade einmal 677 Requests. Etwas ist den gesamten Bestand abgelaufen.
Das Wort „Bots” ist hier zu weit gefasst
Wir können belegen, dass diese Clients sich nicht als Browser ausgeben. Wir können nicht belegen, was sie sind, und niemand, der dieselbe Abfrage ausführt, kann das auch.
In diese Kategorie fallen Uptime-Monitore, für die wir bezahlen, Linkprüfer, HTTP-Bibliotheken in irgendwessen Skript, Security-Scanner, Feed-Reader, KI-Crawler, die Trainingsdaten aufbauen, und Agenten, die eine Seite im Auftrag eines Menschen abrufen, der eine Frage gestellt hat. Ein Teil dieses Traffics nützt uns. Ein Teil ist gleichgültig. Ein kleiner Teil ist feindselig.
Die ehrliche Überschrift lautet deshalb nicht „72 % unseres Traffics sind Bots, die uns angreifen”. Sie lautet: 72 % unseres Traffics laufen nicht in einem Browser, und dieser Unterschied ändert, was Sie dagegen tun sollten.
Was wir nicht gefunden haben
Zuerst haben wir nach einem robots.txt-Problem gesucht, weil das am billigsten zu prüfen und ein wirklich verbreiteter Defekt ist: robots.txt wird pro Protokoll und pro Subdomain ausgeliefert, also können http, www und die Apex-Domain still und leise voneinander abweichen. Unsere waren identisch, Byte für Byte, und leiteten alle auf eine kanonische Adresse weiter.
Das gehört klar gesagt, denn ein sauberes Ergebnis ist auch ein Ergebnis. Hätten wir nur veröffentlicht, was wir repariert haben, bekämen Sie ein verzerrtes Bild davon, wie oft diese Arbeit überhaupt etwas findet.
Das andere, was der Erwähnung wert ist: robots.txt senkt die Last nicht. Sie ist eine Bitte um Kooperation an Clients, die sie lesen. Alles, was sie ignoriert, landet trotzdem auf Ihrem Server und verbraucht trotzdem alles, was auf dem Request-Pfad läuft. Die Last senken tatsächlich die Schichten, die ausgewertet werden, bevor Ihr Anwendungscode startet.
Dieser Text handelt davon, was den Server erreicht, also von der Schicht, die ein WordPress Entwickler auslegen muss.
Der Fund, mit dem wir nicht gerechnet haben: unser Cache hat nie funktioniert
Beim Ziehen dieser Zahlen fiel uns die Trefferquote des Edge-Caches auf: rund 4 %, auf einer Website, deren Seiten alle zur Build-Zeit vorgerendert werden. Das sollte ungefähr das Gegenteil sein.
Jede Seite sendet dies:
cache-control: public, max-age=60, s-maxage=3600, stale-while-revalidate=86400Und jede Seite kam mit cf-cache-status: DYNAMIC zurück. Wir baten um eine Stunde Edge-Caching und haben sie kein einziges Mal bekommen.
Zwei Ursachen, und nur zusammen erklären sie es.
Cloudflare cacht HTML standardmäßig nicht. Die Standard-Cache-Stufe deckt eine Liste statischer Dateiendungen ab, und HTML steht nicht darauf, egal was Ihr Origin sagt. s-maxage zu senden macht HTML nicht cachefähig; das macht eine Cache-Regel.
Unsere eigene Funktion hat den Rest blockiert. Wir liefern eine Markdown-Repräsentation jeder Seite an Agenten aus, die per Accept: text/markdown danach fragen. Das heißt, eine URL hat zwei Repräsentationen. Damit ein Cache sicher ist, muss der Cache-Key Accept enthalten, und Cloudflares Standard-Cache-Key enthält nur Vary: Accept-Encoding. Caching naiv einzuschalten würde irgendwann einem Agenten eine gecachte HTML-Seite ausliefern oder einem Menschen gecachtes Markdown, was schlimmer ist als gar kein Cache.
Das ist der Teil, der sich verallgemeinern lässt: Die Kosten waren unsichtbar, weil sie zu einer Funktion gehörten, auf die wir stolz waren. Niemand auditiert den Preis der eigenen guten Idee.
Die Lösung war eine Cache-Regel mit Bedingung auf den Request-Header: Seiten cachen, aber nur wenn Accept kein Markdown verlangt. Dann muss der Cache-Key Accept nie mitführen, weil die verhandelnden Requests komplett vom Caching ausgenommen sind. Das sind rund hundert am Tag gegenüber Zehntausenden gewöhnlicher Seitenaufrufe.
Sie kommt mit einer zweiten Hälfte, die nicht optional ist: Cache bei jedem Deploy leeren. Ohne das hinterlässt jeder Deploy für einen Teil des Publikums bis zu eine Stunde veraltete Seiten, und das Nächste, was Sie hören, ist, dass eine Änderung nicht sichtbar sei. Eine Caching-Regel ohne Purge-Schritt ist eine Falle, die Sie sich selbst stellen.
Warum es um Widerstandsfähigkeit geht, nicht um Geschwindigkeit
Mit max-age=60 ändert Edge-Caching für einen wiederkehrenden Menschen wenig. Es ändert, was passiert, wenn etwas Ihre gesamte Website durchläuft.
Unsere Seiten laufen bei jedem HTML-Request durch eine Edge-Funktion, und der kostenlose Tarif erlaubt 100.000 Funktionsaufrufe pro Tag. Der Median liegt bei etwa 30.000 am Tag. Am Tag dieses Durchlaufs waren es 131.255, also über der Decke.
Der Cache war also nie eine nette Performance-Zugabe. Er war der Unterschied zwischen einem Crawl, der unsichtbar bleibt, und einem Crawl, der die Website umlegt. Diese Umdeutung wurde erst möglich, als Bot-Anteil und Cache-Quote auf derselben Seite standen.
Der Endpunkt, der wochenlang kaputt war
Wir führen einen separaten Zähler für die maschinenlesbare Oberfläche, weil Browser-Analytics sie nicht sieht: Ein Agent, der eine JSON-Datei abruft, führt kein JavaScript aus, also meldet ein beacon-basiertes Analytics-Werkzeug schlicht gar nichts.
Dieser Zähler sagt rund 102 Agent-Requests pro Tag. Die Verteilung hat uns überrascht: Zwei Drittel gehen an unseren MCP-Endpunkt und nicht an die deklarativen Karten wie agent.json oder llms.txt, die in der Debatte um KI-Sichtbarkeit die ganze Aufmerksamkeit bekommen.
Dann hat er uns etwas Schlimmeres verraten. Die Adresse ohne abschließenden Schrägstrich antwortete mit 301. Eine Weiterleitung macht aus einem POST ein GET und verwirft den Request-Body, also erhält ein JSON-RPC-Client entweder nichts oder einen Parse-Fehler. Über einen Tag gemessen: 29 gescheiterte Aufrufe gegenüber 2, die funktionierten.
Wir hatten einen öffentlichen Endpunkt für Agenten, der für einen großen Teil der Clients schlicht defekt war, und wir hätten es nicht gewusst. Er taucht in keinem Dashboard auf, in das ein Marketer schaut. Er erzeugte keinen Fehler, den jemand sah, denn die, bei denen er versagte, waren keine Menschen.
Drei Reparaturversuche in der Anwendung scheiterten, weil die Normalisierung des abschließenden Schrägstrichs auf Plattformebene passiert, bevor Anwendungscode läuft. Die Lösung musste oberhalb der Ursache ansetzen, als Rewrite-Regel am Netzwerk-Edge. Am Tag danach: 12 erfolgreiche POST-Antworten dort, wo es vorher keine gab.
Wie Sie diese Messung selbst durchführen
Nichts davon brauchte ein kostenpflichtiges Werkzeug. Cloudflares GraphQL-Analytics-Endpunkt beantwortet all das, und die ganze Übung besteht aus einem API-Token und einer Handvoll Abfragen.
Zwei Fallen haben uns Zeit gekostet, sie gehören also benannt.
Die Token-Berechtigung ist nicht die naheliegende. Unser seit Langem genutztes API-Token konnte deployen, Cache leeren und Regeln verwalten, und lieferte bei jeder Analytics-Abfrage einen Berechtigungsfehler. Analytics braucht ausdrücklich Zone / Analytics / Read, und ein Token kann durchaus in der Lage sein, Ihre Website zu verändern, ohne Ihnen irgendetwas über sie sagen zu können. Schlimmer noch: Ein kontoweites Token kann die übliche Prüfung über /user/tokens/verify nicht bestehen und für GraphQL trotzdem korrekt arbeiten, testen Sie es also mit einer echten Abfrage statt mit dem Verifikationsendpunkt.
Das Zeitfenster ist gedeckelt. In unserem Tarif verweigert der Adaptive-Request-Datensatz jede Abfrage über mehr als einen Tag und hält etwa drei Tage Historie vor. Fragen Sie nach dreißig Tagen, bekommen Sie keine Teilantwort, sondern einen Fehler. Laufen Sie Tag für Tag durch und aggregieren Sie clientseitig.
Die Abfrage, aus der die User-Agent-Tabelle entstand, ist klein:
{ viewer { zones(filter: {zoneTag: "YOUR_ZONE_ID"}) {
httpRequestsAdaptiveGroups(
limit: 12,
filter: {datetime_geq: "2026-08-19T15:00:00Z"},
orderBy: [count_DESC]
) { count dimensions { userAgentBrowser } }
} } }Tauschen Sie userAgentBrowser gegen cacheStatus, edgeResponseStatus, clientRequestPath oder clientCountryName und Sie haben den Rest des Bildes. Für Requests gegen Unique Visitors trägt httpRequests1dGroups beides in einer Zeile.
Ein Vorbehalt, der beim Lesen der eigenen Ausgabe zählt: userAgentBrowser ist Cloudflares Klassifikation und keine gesicherte Wahrheit. „Nicht erkannt” heißt, dass ihr Parser keine bekannte Browser-Signatur getroffen hat. Ein Crawler, der einen Chrome-User-Agent-String sendet, wird als Chrome gezählt, der wahre Nicht-Browser-Anteil ist also ein Boden und keine Decke.
Worauf wir bewusst verzichtet haben, und warum
Der naheliegende nächste Schritt nach einem Fund von 72 % ist, mit dem Blockieren anzufangen. Wir haben es nicht getan, und die Begründung ist mehr wert als die Entscheidung.
Wir haben keine WAF-Regeln und kein Rate Limiting ergänzt. Beides würde funktionieren, und beides sitzt in der richtigen Schicht, vor dem Anwendungscode. Aber wir hatten keinen Beleg für einen Schaden. Nichts war ausgefallen, nichts war für Menschen langsam, und es entstanden keine Kosten, die eine Cache-Regel nicht günstiger beseitigt hätte. Traffic zu blockieren, dessen Schädlichkeit Sie nicht gezeigt haben, tauscht ein reales Risiko, nämlich etwas auszusperren, von dem Sie abhängen, gegen ein hypothetisches.
Wir sind keinem Fehler hinterhergelaufen, der sich selbst behob. Mitten in dieser Arbeit fanden wir 9.956 Gateway-Timeouts an einem Tag, verteilt über die ganze Website einschließlich der Kontaktseiten in allen Sprachen. Es sah nach einem Notfall aus. Dann zeigte die Aufschlüsselung, dass jeder einzelne davon einen nicht erkannten User-Agent trug: null von Chrome, Safari, Googlebot oder Bingbot. Kein Mensch und keine Suchmaschine hat je einen gesehen. Wir haben es notiert und in Ruhe gelassen. Einen Tag später zeigte dasselbe Fenster drei. Hätten wir es „repariert”, hätten wir den Crawler von jemand anderem repariert und eine Änderung an unserem eigenen Code ausgeliefert, die nichts heilt.
Wir haben die teure Agenten-Arbeit nicht finanziert. Derselbe Zähler, der den defekten Endpunkt fand, hat uns auch eine Aufgabenliste bepreist. Signierte Identitätsdokumente, Attestierungen durch Dritte, eine Sandbox, ein maschinenlesbarer Vertrag: Jedes davon sind Wochen an Arbeit, und jedes rechtfertigt sich über die Annahme, dass einkaufende Agenten unsere deklarativen Dateien lesen. Bei 26 Requests am Tag an agent.json überlebt diese Annahme den Kontakt mit dem Zähler nicht. Zwei unabhängige Messungen im Abstand eines Tages stimmten überein, die Entscheidung ruht also jetzt auf Messung und nicht auf einer einzelnen Ablesung.
Das Muster ist in allen drei Fällen dasselbe. Messung erwirbt das Recht, nichts zu tun, und das ist eine Verwendung von Daten, die weit weniger Anerkennung bekommt, als sie verdient. Der größte Teil des Werts dieser Übung waren nicht die zwei Reparaturen. Es war das Wissen, welche der alarmierenden Zahlen unsere Woche verdient hat.
Was wir jemandem raten würden, der das auf der eigenen Website macht
Messen Sie, bevor Sie irgendetwas blockieren. Ziehen Sie die User-Agent-Aufschlüsselung für einen vollen Tag. Das Verhältnis von Requests zu Unique Visitors ist der schnellste Plausibilitätstest, und wenn es weit über zwei oder drei liegt, sehen Sie genauer hin.
Prüfen Sie Ihren Cache-Status, nicht Ihre Cache-Header. cache-control ist eine Bitte. cf-cache-status, oder das Äquivalent Ihres CDN, ist die Antwort. Wir haben lange einem Header geglaubt, der kein einziges Mal gewirkt hat.
Zählen Sie den Traffic, den Ihr Analytics nicht sehen kann. Wenn Ihnen Ihre Sichtbarkeit für KI-Agenten überhaupt etwas bedeutet, erscheint dieser Traffic ausschließlich in Server- oder Edge-Logs. Bei uns kam so ein defekter Endpunkt zum Vorschein, der wochenlang leise versagt hatte.
Seien Sie vorsichtig damit, was Sie einen Angriff nennen. Das meiste, was wir gefunden haben, war weder bösartig noch nützlich. Es war gleichgültig. Die nützliche Antwort auf gleichgültigen Traffic ist, ihn billig auslieferbar zu machen, nicht ihn zu bekämpfen.
Auditieren Sie die Kosten Ihrer eigenen Funktionen. Das Teuerste, was wir gefunden haben, war kein Bot. Es war eine Funktion, die wir bewusst gebaut hatten, mit null bepreist, und die uns unseren gesamten HTML-Edge-Cache gekostet hat.
