Der Shop war nachts langsam. Nicht im Sale, nicht zur Primetime — nachts um kurz nach drei, wenn kaum jemand bestellt. Die CPU-Auslastung sah harmlos aus, die Datenbank ebenfalls, und trotzdem stieg die Antwortzeit auf ein Vielfaches. Aufgefallen ist es erst, als jemand die Access-Logs nicht nach Uhrzeit sortierte, sondern nach User-Agent. Der Großteil der Anfragen in diesem Zeitfenster stammte von automatisierten Clients. Und sie liefen fast ausschließlich auf Filter- und Sortier-URLs, die kein Cache je gesehen hatte. Jede einzelne belegte einen PHP-Worker und eine Datenbankverbindung. Die wenigen echten Kunden warteten in derselben Queue.
Die Mehrheit der Anfragen kommt nicht mehr von Menschen
Automatisierter Traffic ist keine Randerscheinung mehr. Cloudflare berichtet für Juni 2026, dass mehr als 50 Prozent (Cloudflare Radar) des Traffics im Internet nicht mehr von Menschen stammen — eine Schwelle, die damit erstmals überschritten wurde. Momentaufnahmen des Radar-Dashboards lagen im Juni 2026 bei rund 57,5 Prozent (Cloudflare Radar) Bot-Anteil an den HTML-Anfragen gegenüber 42,5 Prozent menschlichem Traffic. Diese Werte schwanken je nach Zeitfenster und Region deutlich; sie sind ein Trendsignal, kein fester Messwert für Ihr Projekt.
Der Wandel vollzog sich schnell. Zu Beginn des Jahres 2025 entfiel noch etwa die Hälfte (Cloudflare Radar) der HTML-Anfragen auf Nicht-KI-Bots, sieben Prozentpunkte über dem menschlichen Traffic. Bis Anfang Dezember 2025 lag der menschliche Anteil bei 47 Prozent (Cloudflare Radar), Nicht-KI-Bots bei 44 Prozent. Parallel wuchs die Kategorie, die Websites im Auftrag einer konkreten Nutzerfrage abruft, im Jahr 2025 um mehr als das 15-Fache (Cloudflare Radar).
Für die Serverseite zählt die absolute Menge, nicht der Anteil. Über das Netzwerk hinweg stammen 32 Prozent (Cloudflare) des Traffics von automatisierten Clients, und allein die selbst identifizierten KI-Bots erzeugen über 10 Milliarden Anfragen pro Woche (Cloudflare). Davon entfallen rund 80 Prozent (Cloudflare) auf Crawler im engeren Sinne — also auf Clients, die systematisch Seite für Seite abrufen, statt einer einzelnen Nutzerfrage zu folgen.
Bot-Anteil ist kein Naturgesetz
Ein Kapazitätsthema, kein SEO-Thema
Warum Crawler ausgerechnet die teuersten URLs treffen
Ein Cache lebt von einer Annahme: Viele Anfragen treffen dieselbe URL. Genau diese Annahme bricht bei KI-Crawlern. Cloudflare beschreibt, dass Seiten, die früher als Long-Tail galten und selten abgerufen wurden, inzwischen regelmäßig angefragt werden (Cloudflare). Aus den öffentlichen Statistiken von Common Crawl geht hervor, dass über 90 Prozent (Common Crawl) der Seiten inhaltlich einzigartig sind. Für einen Crawler, der Vollständigkeit anstrebt, ist Wiederholung wertlos — er sucht das, was er noch nicht hat.
Entsprechend hoch ist die Rate einzigartiger Zugriffe: KI-Agenten erreichen typischerweise 70 bis 100 Prozent (Cloudflare) einzigartige Abrufe je Durchlauf. In Tests zeigt sich ein klarer Rückgang der Cache-Trefferquote, sobald KI-Crawler-Traffic hinzukommt (Cloudflare). Jeder Cache-Miss bedeutet in der Konsequenz: Die Anfrage geht bis zum Origin durch, belegt dort einen PHP-Worker, öffnet eine Datenbankverbindung und blockiert beides für die Dauer der Berechnung.
Betroffen sind dabei genau die URL-Klassen, die ein Shop technisch erzeugt, ohne sie je bewusst veröffentlicht zu haben:
- Facetten- und Filterkombinationen wie
?farbe=blau&groesse=42&sortierung=preis— jede Kombination ist eine eigene URL mit eigenem Cache-Eintrag. - Tiefe Paginierung, etwa Seite 47 einer Kategorie, die ein Mensch praktisch nicht erreicht, ein Crawler aber systematisch abläuft.
- Interne Suchergebnisseiten, die pro Suchbegriff eine neue Adresse erzeugen und meist ungecacht direkt in die Datenbank gehen.
- Sortiervarianten derselben Liste, die identische Inhalte in anderer Reihenfolge liefern und den Cache vervielfachen.
- Session-, Tracking- und Kampagnenparameter, die inhaltlich nichts ändern, aber jeden Cache-Schlüssel einzigartig machen.
- Kalender- und Archivseiten mit endlosem Datumsraum, in dem ein Crawler ohne Abbruchbedingung weiterlaufen kann.
Der Effekt ist multiplikativ, nicht additiv. Fünf Filterdimensionen mit je vier Ausprägungen und drei Sortieroptionen ergeben rechnerisch über 3.000 URL-Varianten pro Kategorie. Bei 200 Kategorien sind das mehr als 600.000 Adressen, die technisch existieren, aber kaum ein Mensch je aufruft. Für den Cache sind das 600.000 kalte Einträge. Für einen Crawler sind es 600.000 Ziele — und er hat keinen Grund, sie auszulassen.
Auch Medien-Bandbreite ist betroffen
Die Last sichtbar machen
Bevor Sie regeln, messen Sie. Der erste Schnitt läuft über den User-Agent — aber der ist frei wählbar und damit kein Beweis. Seriöse Crawler lassen sich über Reverse-DNS verifizieren: IP zu Hostname auflösen, den Hostname wieder zu einer IP auflösen und prüfen, ob beide übereinstimmen. Ergänzend veröffentlichen die großen Betreiber IP-Bereiche, gegen die Sie abgleichen können. Alles, was sich als bekannter Crawler ausgibt, diese Prüfung aber nicht besteht, gehört in eine eigene Kategorie — und wird anders behandelt als ein verifizierter Bot.
User-Agent segmentieren
Access-Logs nach Agent-Gruppen aufteilen: verifizierte Suchmaschinen, verifizierte KI-Crawler, unverifizierte Selbstauskunft, Menschen. Vier Segmente reichen für den Anfang.
Per Reverse-DNS verifizieren
Forward-confirmed Reverse-DNS plus Abgleich gegen veröffentlichte IP-Bereiche. Ohne diesen Schritt regeln Sie auf einer Angabe, die jeder Client frei setzen kann.
TTFB getrennt auswerten
Antwortzeit je Segment und je URL-Klasse statt als Gesamtmittelwert. Erst diese Trennung zeigt, ob Bot-Last die Kaufstrecke verlangsamt oder nur sich selbst.
Cache-Status protokollieren
Hit, Miss und Bypass pro Anfrage mitschreiben. Die Trefferquote je Segment ist die direkteste Antwort auf die Frage, wer den Origin wirklich belastet.
Worker-Belegung korrelieren
Belegte PHP-Worker und offene Datenbankverbindungen im Zeitverlauf gegen die Bot-Rate legen. Sättigung erklärt Latenzsprünge zuverlässiger als CPU-Auslastung.
Crawl-to-Referral bilden
Gecrawlte Seiten je Plattform gegen die Besucher rechnen, die dieselbe Plattform zurückschickt. Das ist die Kennzahl, die eine Drosselung begründet oder widerlegt.
Ein blinder Fleck entsteht, wenn Sie ausschließlich auf Felddaten aus dem Browser schauen. Real User Monitoring misst per Definition nur Menschen — Bots führen kein JavaScript aus und tauchen dort schlicht nicht auf. Eine Website kann in den Felddaten unauffällig aussehen und trotzdem am Origin an der Sättigungsgrenze laufen. Die Bot-Last sehen Sie ausschließlich serverseitig. Wie sich Feld- und Labordaten sinnvoll ergänzen, ordnet der Beitrag zu RUM, CrUX und Performance-Budgets ein.
Getrennt auswerten, nicht gemittelt
Crawl-to-Referral: das Kosten-Nutzen-Verhältnis
Die Kennzahl setzt die Zahl gecrawlter Seiten ins Verhältnis zu den Besuchern, die eine Plattform zurückschickt. Sie beantwortet die Frage, die bei jeder Drosselung als Erstes kommt: Was kostet dieser Bot, und was bringt er? Die Spannweite zwischen den Plattformen ist dabei größer, als die meisten Betreiber erwarten.
| Crawler | Gecrawlte Seiten je Referral (Juli 2025) | Einordnung |
|---|---|---|
| ClaudeBot (Anthropic) | 38.066 : 1 | Sehr hohe Crawl-Last, kaum Rückverweise |
| GPTBot (OpenAI) | 1.091 : 1 | Hohe Last, wenige Rückverweise |
| PerplexityBot | 195 : 1 | Moderate Last, mehr Rückverweise |
| Microsoft | 41 : 1 | Vergleichsweise ausgewogenes Verhältnis |
Alle Werte stammen aus Messungen vom Juli 2025 (Cloudflare Radar) — und sie bewegen sich schnell. Ende Juni 2025 lag das Verhältnis bei Anthropic noch bei annähernd 71.000 zu 1 (Cloudflare Radar), im Juli 2025 bei 38.066 zu 1 (Cloudflare Radar), was einem Rückgang um rund 87 Prozent gegenüber Januar entspricht. Perplexity bewegte sich im gleichen Zeitraum in die Gegenrichtung und stieg von 54,6 auf 194,8 zu 1 (Cloudflare Radar). Wer diese Kennzahl nutzt, sollte sie deshalb rollierend erheben statt einmalig.
Das Verhältnis hängt zusätzlich von der Branche ab. In der Kategorie News und Publikationen lag Anthropic Anfang August 2025 bei 2.500 zu 1 (Cloudflare Radar), OpenAI bei 152 zu 1 (Cloudflare Radar) und Perplexity bei 32,7 zu 1 (Cloudflare Radar) — deutlich niedriger als im Gesamtdurchschnitt über alle Branchen. Für Ihr Projekt lässt sich dasselbe Verhältnis aus Access-Logs und Referrer-Daten selbst bilden; es ist die belastbarste Grundlage für die Frage, welchen Crawler Sie großzügig bedienen und welchen Sie begrenzen.
Ein Crawler, der Zehntausende Seiten liest und einen einzigen Besucher schickt, ist kein Marketingkanal. Er ist ein Kostenfaktor, den man bewusst dimensioniert.
Drosseln statt blocken
Die naheliegende Reaktion ist ein pauschales Verbot. Sie ist selten die beste. Der Anteil reiner Trainings-Crawls an den KI-Crawler-Anfragen lag im Juni 2026 bei 52 Prozent (Cloudflare Radar), gegenüber 22 Prozent (Cloudflare Radar) im Frühjahr 2025. Gleichzeitig entfallen über 36 Prozent (Cloudflare Radar) auf Crawler mit gemischtem Zweck, die Suche, Agentennutzung und Training verbinden. Genau diese Mischung macht pauschales Blocken riskant: Wer den Crawler sperrt, sperrt unter Umständen auch die Antwortmaschine, die Besucher schicken würde.
Die Abwägung hat eine reale Kehrseite. In besonders stark gecrawlten Kategorien ist der menschliche Traffic binnen weniger als einem Jahr um bis zu 40 Prozent (Cloudflare Radar) zurückgegangen. Wer Sichtbarkeit in Antwortmaschinen anstrebt, braucht deshalb eine differenzierte Regel statt eines Schalters — und die Regel sollte an der Kennzahl hängen, nicht am Bauchgefühl.
| Maßnahme | Wirkung auf die Server-Last | Wirkung auf die Sichtbarkeit |
|---|---|---|
| Pauschales Blocken per User-Agent | Last sinkt sofort und deutlich | Auch nützliche Crawler entfallen |
| Rate-Limit je verifiziertem Crawler | Last wird planbar begrenzt | Inhalte bleiben erreichbar |
| Priorisierung: Menschen vor Bots | Spitzen treffen zuerst die Bots | Weitgehend unverändert |
| Cache-Regeln für Bot-Traffic | Cache-Misses gehen zurück | Unverändert, Inhalte bleiben abrufbar |
| Facetten aus dem Crawl-Pfad nehmen | Crawl-Fläche schrumpft stark | Relevante Seiten bleiben indexierbar |
| 429 statt 503 senden | Entlastet ohne Fehlersignal | Crawler drosselt und kommt wieder |
In der Umsetzung sind es meist wenige, gut gewählte Eingriffe, die den Großteil der Last abfangen:
- Rate-Limits je verifizierter Bot-Gruppe statt global, damit ein aggressiver Crawler nicht das Budget der übrigen aufbraucht.
- Ein eigener Cache-Schlüssel für Bot-Traffic, der Tracking- und Session-Parameter ignoriert und dadurch aus vielen kalten URLs wenige warme macht.
- Längere Cache-Lebensdauer für Bot-Anfragen dort, wo leicht veraltete Inhalte vertretbar sind — Preise, Lagerstände und Warenkorb bleiben ausgenommen.
- Getrennte Worker-Pools oder Verbindungslimits, damit Bot-Last die Kaufstrecke nicht aushungert.
- 429 mit
Retry-Afterstatt 503, weil ein Server-Fehler das Crawl-Budget längerfristig senkt. - Priorisierung am Edge: Bei Überlast zuerst Bot-Anfragen verzögern, nicht Kundensitzungen.
Welche Cache-Schicht wofür zuständig ist, ordnet der Beitrag zu Varnish und Redis ein; wie weit sich Last überhaupt an die Edge verlagern lässt, zeigt der Beitrag zu CDN- und Edge-Caching. Welche Kombination zu Ihrem Projekt passt, umreißt die Leistungsseite zu Caching-Strategien.
robots.txt als Kapazitätsinstrument
Das Robots Exclusion Protocol ist als RFC 9309 (IETF) standardisiert — und damit deutlich präziser, als sein Ruf als bloße Empfehlung vermuten lässt. Für die Kapazitätsplanung sind vier Details entscheidend, die in der Praxis regelmäßig übersehen werden:
- Parsing-Limit: Crawler müssen mindestens 500 Kibibyte (RFC 9309) der Datei auswerten. Regeln jenseits dieser Grenze dürfen ignoriert werden — automatisch generierte, sehr lange robots.txt-Dateien sind daher riskant.
- Caching: Eine zwischengespeicherte robots.txt soll nicht länger als 24 Stunden (RFC 9309) verwendet werden. Eine neue Regel wirkt also nicht sofort, sondern mit bis zu einem Tag Verzögerung. Als Notfallmaßnahme unter akuter Last taugt sie damit kaum.
- Fehlercodes: Bei einem 4xx (RFC 9309) darf ein Crawler alle Ressourcen abrufen — eine fehlende robots.txt ist ein Freibrief. Bei 5xx (RFC 9309) muss er von einem vollständigen Verbot ausgehen.
- Spezifität: Es gilt die längste (RFC 9309) passende Regel, gemessen in Oktetten; bei Gleichstand gewinnt
Allow. Eine breite Sperre wird durch eine spezifischere Freigabe ausgehebelt — was gewollt sein kann, aber bewusst gesetzt sein sollte.
Der 5xx-Bumerang
Google beschreibt den Zusammenhang zwischen Serverleistung und Crawl-Rate unmissverständlich: Antwortet eine Website eine Zeit lang schnell, steigt das Limit und es werden mehr Verbindungen zum Crawlen genutzt; wird sie langsamer oder antwortet sie mit Serverfehlern, sinkt das Limit und Google crawlt weniger (Google Search Central). Die Crawl-Rate ist damit eine Funktion Ihrer Antwortzeit — und eine langsame Website wird seltener gecrawlt, ohne dass das jemand entschieden hätte. Als Kandidaten für eine Crawl-Budget-Optimierung nennt Google Websites ab einer Million (Google Search Central) einzigartiger Seiten sowie Websites ab 10.000 (Google Search Central) Seiten mit täglichen Änderungen.
Für die Praxis heißt das: Facettierte Navigation, doppelte Inhalte, Soft-404-Seiten und lange Redirect-Ketten verbrauchen Crawl-Budget, ohne Gegenwert zu liefern (Google Search Central). Wo Parameter-URLs weder ranken noch konvertieren sollen, gehören sie per robots.txt gesperrt. Dauerhaft entfernte Seiten sollten 404 oder 410 liefern, statt als Soft-404 weiter gecrawlt zu werden (Google Search Central). Wichtig ist die Reihenfolge: robots.txt verhindert den Abruf, nicht die Indexierung einer bereits bekannten URL — beides zu vermischen führt zu Ergebnissen, die niemand wollte.
Worker-Pool und Datenbank absichern
Kein Server bricht wegen der durchschnittlichen Last ein. Er bricht ein, wenn eine endliche Ressource erschöpft ist. Bei PHP-Anwendungen ist das meist der Worker-Pool: Ist die letzte freie Instanz belegt, warten alle weiteren Anfragen in einer Queue — auch die des Kunden, der gerade auf „Zahlungspflichtig bestellen“ geklickt hat. Die TTFB steigt dann nicht linear, sondern sprunghaft. Wie diese Kennzahl entsteht und wo sie kippt, beschreibt der Beitrag zur Server-Antwortzeit.
- Den Worker-Pool am verfügbaren Arbeitsspeicher ausrichten statt am Wunschwert: Mehr Worker als RAM erlaubt, verlagert das Problem nur in den Swap.
- Das Datenbank-Verbindungslimit über der Summe aller Worker halten, damit ein voller Pool die Anwendung nicht an der Datenbank scheitern lässt.
- Das Slow-Query-Log gezielt auf Facetten- und Sortier-Abfragen auswerten — dort entstehen die teuersten Zugriffe der gesamten Anwendung.
- Timeouts konsequent setzen: Eine Anfrage, die nach 30 Sekunden noch rechnet, blockiert einen Worker, den ein zahlender Kunde braucht.
- Verifizierte Bots über einen eigenen Upstream oder Pool führen, damit ihre Last begrenzt bleibt und die Kaufstrecke ihr eigenes Budget behält.
- Sättigung überwachen statt CPU-Auslastung: Belegte Worker und Queue-Länge sagen mehr über den nächsten Ausfall als jeder Auslastungsgraph.
Facettierte Abfragen sind dabei die teuersten Gäste: Sie treffen selten einen Index sauber, erzeugen temporäre Tabellen und skalieren schlecht mit der Artikelzahl. Wie sich solche Abfragen entschärfen lassen, zeigt der Beitrag zur Datenbank-Query-Optimierung. Ob die Hardware überhaupt zum Lastprofil passt, klärt vorab die Hosting-Wahl — ein Modell, das im Leerlauf gut aussieht, kann unter Bot-Last deutlich früher einbrechen.
Ein Teil der Last lässt sich zusätzlich am Transfervolumen senken. Wenn viele ähnliche HTML-Antworten ausgeliefert werden, reduziert Delta-Kompression die übertragene Menge spürbar — die Mechanik dahinter beschreibt der Beitrag zu Shared Dictionaries und Delta-Kompression. Und bei Anwendungen, die clientseitig navigieren, verschiebt sich die Messgrundlage ohnehin; dazu passt der Beitrag zu Soft Navigations in SPAs.
Die Abwägung: Sichtbarkeit gegen Kapazität
Die ehrliche Antwort lautet: Hier existiert ein Zielkonflikt, und er lässt sich nicht wegkonfigurieren. Wer in Antwortmaschinen sichtbar sein will, muss Crawlern Zugang geben. Wer Zugang gibt, zahlt mit Serverkapazität. Cloudflare beziffert die Verschiebung drastisch: Für jede Stunde, die online nach Informationen gesucht wird, entfallen nur noch 15 Minuten (Cloudflare Radar) auf das offene Web. Der Rest der Nutzung endet in Oberflächen, die Ihre Inhalte lesen, ohne dass jemand Ihre Seite betritt.
Die Entscheidung ist deshalb keine rein technische, sondern eine unternehmerische — und sie fällt pro Crawler, nicht pauschal. Ein Crawler mit einem Verhältnis von 41 zu 1 verdient anderen Zugang als einer mit 38.066 zu 1 (Cloudflare Radar). Ein Trainings-Crawl auf Ihre Filterkombinationen bringt in aller Regel weder Umsatz noch Sichtbarkeit; ein Abruf, der aus einer konkreten Nutzerfrage entsteht, kann beides bringen. Diese Unterscheidung ist der eigentliche Hebel.
Damit ist KI-Crawler-Last vor allem ein Dimensionierungsproblem mit einer klaren Reihenfolge: erst messen, welcher Anteil des Traffics automatisiert ist und auf welche URLs er auftrifft; dann die Crawl-Fläche verkleinern, indem Facetten- und Parameter-URLs aus dem Pfad genommen werden; dann drosseln und priorisieren statt zu sperren; und erst danach über zusätzliche Hardware nachdenken. Die Reihenfolge umzudrehen ist teuer — ein größerer Server lässt sich schneller leer crawlen, gelöst ist damit wenig. Wer die Grundlagen der Server-Optimierung und der TTFB-Optimierung sauber aufsetzt, verschafft sich Spielraum für beides: erreichbare Inhalte für Maschinen und schnelle Antworten für Kunden.
Quellen und Studien