Ihr Shop wird 2026 mehrheitlich nicht mehr von Menschen aufgerufen. Nach den Messungen von Cloudflare stammten im Juni 2026 erstmals 57,5 Prozent (Cloudflare Radar) aller HTML-Seitenabrufe von automatisierten Clients und nur noch 42,5 Prozent (Cloudflare Radar) von echten Besucherinnen und Besuchern. Ein großer Teil dieser Maschinen sind KI-Crawler, die Inhalte für Sprachmodelle und agentische Assistenten einsammeln -- in der Summe geschätzt rund 50 Milliarden (Cloudflare Radar) Anfragen pro Tag. Für Betreiberinnen und Betreiber ist das keine abstrakte Zahl: Jeder dieser Zugriffe kostet Rechenzeit, Datenbankabfragen und Bandbreite. Die Hosting-Rechnung steigt, Seiten werden langsamer, und die Ursache taucht in keinem klassischen Analytics-Bericht auf, weil Bots dort üblicherweise herausgefiltert werden. Dieser Leitfaden zeigt, wie sich KI-Crawler-Last messen, steuern und im Rahmen der laufenden Shop-Wartung beherrschen lässt -- nicht als Sicherheitsthema, sondern als Kosten- und Tempofrage.
Das Wichtigste in Kürze
- Im Juni 2026 stammten erstmals 57,5 Prozent (Cloudflare Radar) aller HTML-Seitenabrufe von automatisierten Clients und nur noch 42,5 Prozent (Cloudflare Radar) von echten Besucherinnen und Besuchern.
- Es geht um Kosten und Tempo, nicht um die Abwehr bösartiger Bots. KI-Crawler und agentische Assistenten sind häufig legitime Zugriffe, laufen aber in Sekunden durch Kategorien, Filter und Produktseiten und erzeugen dabei volle Rechenlast.
- In den gewohnten Werkzeugen bleibt die Last unsichtbar. Sie zeigt sich in steigender CPU- und Datenbanklast ohne mehr menschliche Sitzungen, in sinkender Cache-Hit-Rate und in Zugriffsspitzen ohne Marketingaktion -- sichtbar in Logs, Cache-Statistik und Hosterrechnung.
- Der größte einzelne Hebel liegt bei der facettierten Navigation: Aus wenigen hundert Produkten entstehen rechnerisch Millionen URL-Kombinationen. Kanonische Verweise, gezielte robots.txt-Regeln und eine gepflegte Sitemap bündeln diese Varianten.
- Die Reihenfolge zählt: erst messen, dann steuern, dann deckeln. Die robots.txt ist eine Bitte, kein Riegel -- die tatsächliche Begrenzung leisten Cache, CDN und serverseitiges Rate-Limiting, und die Konfiguration braucht laufende Pflege.
Warum KI-Crawler die Serverrechnung treiben
Ein klassischer Suchmaschinen-Crawler war über Jahre ein kalkulierbarer Gast: Er besuchte in überschaubarem Tempo neue und geänderte Seiten und richtete sich weitgehend nach den Vorgaben in der robots.txt. KI-Crawler verhalten sich anders. Sie sammeln Trainings- und Kontextdaten in großem Umfang, folgen Links tiefer und wiederholen Besuche häufiger, weil sie möglichst aktuelle Inhalte wollen. Cloudflare beziffert das gesamte Aufkommen auf rund 50 Milliarden (Cloudflare Radar) Crawler-Anfragen täglich -- eine Größenordnung, die einzelne Server und ganze Shop-Plattformen sichtbar belastet. Dazu kommt, dass das Verhältnis von Crawls zu tatsächlich vermittelten Besuchern bei manchen KI-Diensten sehr ungleich ist: Erfahrungsgemäß entfallen auf jeden weitergeleiteten menschlichen Besucher viele tausend Crawler-Zugriffe (Cloudflare), sodass der Traffic Kosten verursacht, ohne unmittelbar Umsatz zu bringen.
Der eigentliche Kostentreiber 2026 ist aber weniger der reine Crawler, sondern die agentische KI. Ein Assistent, der im Auftrag einer Person nach einem Produkt sucht, Preise vergleicht oder eine Bestellung vorbereitet, arbeitet nicht wie ein Mensch, der zwei oder drei Seiten öffnet. Er klickt sich in Sekunden durch Kategorien, Filter und Produktdetails und ruft dabei schnell Tausende URLs ab, wo eine Kundin fünf angesehen hätte. Diese Zugriffe sehen für den Server wie legitime Anfragen aus, treffen aber selten den Cache und erzeugen jede Menge dynamischer Datenbanklast. Genau deshalb bemerken Betreiber zuerst die Symptome -- eine höhere Cloud-Rechnung und langsamere Antwortzeiten (Projekterfahrung) -- und suchen erst danach nach der Ursache.
Abgrenzung: Kosten und Tempo, nicht Security
Was 2026 neu ist: die Maschinen-Mehrheit
Dass Bots einen erheblichen Teil des Web-Traffics ausmachen, ist nicht neu. Der Bruch liegt in der Mehrheit: Erstmals stellen automatisierte Clients mit 57,5 Prozent (Cloudflare Radar) den größeren Anteil am HTML-Traffic. Ein unabhängiger Blick bestätigt den Trend -- laut dem Imperva Bad Bot Report überholte automatisierter Traffic bereits 2024 mit rund 51 Prozent (Imperva Bad Bot Report 2025) den menschlichen, und gut ein Drittel davon, etwa 37 Prozent (Imperva Bad Bot Report 2025), entfiel auf unerwünschte Bots. Bemerkenswert ist die Dynamik einzelner Akteure: ClaudeBot legte im Juni 2026 um 66 Prozent (Cloudflare Radar) zu und rückte damit hinter GPTBot auf Platz zwei der aktivsten KI-Crawler (Cloudflare Radar). Für Shops heißt das: Der maschinelle Anteil ist kein Randphänomen mehr, sondern der größere Teil der Last.
Der wirtschaftliche Kontext macht das relevant. Der deutsche Online-Handel mit Verbrauchern setzte 2025 rund 83,1 Milliarden Euro (bevh) um, bei einem durchschnittlichen Bestellwert von 146,19 Euro (bevh). In einem Markt dieser Größe zählt jede Sekunde Ladezeit und jeder Euro Infrastrukturkosten. Wenn ein wachsender Teil der Rechenlast von Zugriffen stammt, die weder einkaufen noch konvertieren, verschiebt sich das Verhältnis von Kosten zu Ertrag. Die folgenden sechs Mechanismen erklären, warum KI-Crawler einen Shop technisch anders belasten als menschliche Besucher.
Agentische Zugriffe
KI-Assistenten arbeiten im Auftrag von Nutzern und rufen in einer Session Tausende Seiten ab, wo ein Mensch nur wenige öffnet -- mit voller dynamischer Last.
Facetten-URLs
Filter- und Sortierkombinationen erzeugen praktisch unbegrenzt viele URL-Varianten. Crawler folgen ihnen, obwohl der Inhalt sich kaum unterscheidet.
Cache-Bruch
Viele Crawler-URLs sind so speziell, dass sie den Cache verfehlen. Jede Anfrage läuft voll durch Applikation und Datenbank statt aus dem Zwischenspeicher.
Asset-Last
Neben HTML laden Bots Bilder, Skripte und Downloads. Bei großen Produktbildern summiert sich die Bandbreite schnell zu spürbaren Transferkosten.
Crawl-Spitzen
Statt gleichmäßig zu crawlen, kommen manche Bots in Wellen. Solche Spitzen treffen den Shop unvorbereitet und drehen die Antwortzeiten kurzfristig hoch.
robots-Ignoranz
Nicht jeder Crawler hält sich an die robots.txt. Ohne serverseitige Deckelung nützt eine höfliche Bitte um Zurückhaltung erfahrungsgemäß wenig.
Woran man die Last erkennt
Das Tückische an KI-Crawler-Last ist ihre Unsichtbarkeit in den gewohnten Werkzeugen. Ein Analytics-Dashboard, das nur menschliche Sitzungen zählt, zeigt womöglich stabile Besucherzahlen, während die Serverauslastung steigt. Die Wahrheit steht in den Server- und Applikationslogs, in der Cache-Statistik und in der Rechnung des Hosters. Wer Last früh erkennen will, achtet auf ein Muster aus mehreren Signalen gleichzeitig -- die folgende Liste fasst die verlässlichsten zusammen. Ein strukturiertes Log-Monitoring mit Alerting macht diese Signale sichtbar, bevor die nächste Cloud-Rechnung sie bestätigt.
- Steigende CPU- und Datenbanklast ohne entsprechenden Anstieg menschlicher Sitzungen
- Sinkende Cache-Hit-Rate, weil viele angefragte URLs Filter- oder Sortiervarianten sind
- Ungewöhnlich viele Zugriffe mit KI-typischen User-Agents wie GPTBot, ClaudeBot oder Bytespider
- Traffic-Spitzen zu Zeiten ohne Marketingaktion, oft nachts oder am frühen Morgen
- Wachsender Bandbreitenverbrauch durch Bild- und Asset-Abrufe ohne Konversion
- Antwortzeiten, die zu Stoßzeiten kippen, obwohl die Besucherzahl gleich bleibt
Bots nicht wegfiltern, sondern getrennt ausweisen
Facetten-URLs und der Crawl-Explosions-Effekt
Der größte einzelne Hebel liegt bei der facettierten Navigation. Ein Shop mit Filtern für Größe, Farbe, Marke, Preis und Verfügbarkeit erzeugt aus wenigen hundert Produkten rechnerisch Millionen möglicher URL-Kombinationen. Für Menschen ist das praktisch, für Crawler eine Einladung, sich zu verlieren. Google beschreibt facettierte Navigation ausdrücklich als Quelle eines nahezu unendlichen URL-Raums, der das Crawl-Budget aufzehren kann (Google Search Central). KI-Crawler, die weniger diszipliniert sind als etablierte Suchmaschinen, folgen diesen Kombinationen oft ungebremst -- und jede einzelne verfehlt in der Regel den Cache und löst eine frische Datenbankabfrage aus (Projekterfahrung).
Aus Wartungssicht ist das der Punkt, an dem sich mit vergleichsweise wenig Aufwand am meisten erreichen lässt. Entscheidend ist, dem Shop beizubringen, welche URL-Varianten indexier- und crawlbar sein sollen und welche nicht. Kanonische Verweise bündeln Filtervarianten auf die Hauptkategorie, gezielte Regeln in der robots.txt halten sinnlose Parameterketten fern, und serverseitige Grenzen fangen ab, was sich nicht bitten lässt. Dieselbe Sorgfalt, mit der tote Produktlinks und Redirects gepflegt werden, gilt hier für die Filter- und Parameterlogik: Sie ist ein Wartungsobjekt, kein einmaliges Setup.
Parameter-Wildwuchs kostet doppelt
Gegenmaßnahmen: Rate-Limiting, Crawl-Steuerung, Cache
Es gibt nicht den einen Schalter gegen KI-Crawler-Last, sondern ein Zusammenspiel aus mehreren Hebeln. Wichtig ist die Reihenfolge: Zuerst wird gemessen, dann gesteuert, dann gedeckelt. Wer sofort hart blockt, riskiert, auch gutwillige Suchmaschinen oder legitime Agenten zu verlieren, die durchaus Sichtbarkeit oder Umsatz bringen. Die folgende Übersicht ordnet die wichtigsten Maßnahmen nach Wirkung und Einsatzfeld -- eng verzahnt mit einer belastbaren Performance-Wartung, die Ladezeit und Serverlast dauerhaft im Blick behält.
| Hebel | Was er bewirkt | Wann er hilft |
|---|---|---|
| Rate-Limiting je Bot und IP | Deckelt die Anfragen pro Zeitfenster und glättet Spitzen | Bei aggressiven Crawl-Wellen und einzelnen Vielanfragern |
| Caching und CDN | Beantwortet Wiederholungen ohne Applikations- und Datenbanklast | Bei statischen und halbstatischen Seiten mit hohem Wiederholanteil |
| Crawl-Steuerung (robots.txt, Sitemap) | Lenkt kooperierende Bots auf das Wesentliche und weg von Parameter-URLs | Bei regelkonformen Crawlern etablierter Anbieter |
| Facetten- und Canonical-Regeln | Verhindert Millionen sinnloser URL-Varianten im Crawl | Bei großen Sortimenten mit vielen Filtern |
| Monitoring und Alerting | Macht Last sichtbar und warnt, bevor sie eskaliert | Dauerhaft, als Grundlage aller anderen Hebel |
In der Praxis greifen diese Hebel ineinander. Ein sauber konfigurierter Cache fängt den Großteil wiederholter Zugriffe ab, bevor sie überhaupt Applikationslast erzeugen. Rate-Limiting schützt vor einzelnen Bots, die aus der Reihe tanzen. Crawl-Steuerung reduziert die Menge sinnloser Anfragen bei den kooperierenden Anbietern, und die Facetten-Regeln verhindern, dass der URL-Raum überhaupt explodiert. So sieht ein pragmatisches Vorgehen aus:
- Ausgangslage messen: Server- und Applikationslogs, Cache-Hit-Rate und Bot-Anteil über einen repräsentativen Zeitraum erfassen.
- Die größten Verursacher identifizieren -- nach User-Agent, IP-Bereich und angefragtem URL-Muster.
- Cache- und CDN-Strategie schärfen, damit wiederholte Zugriffe die Applikation gar nicht erst erreichen.
- Facetten-, Parameter- und Canonical-Regeln setzen, um den crawlbaren URL-Raum bewusst zu begrenzen.
- Rate-Limits je Bot und IP definieren, mit klaren Ausnahmen für wichtige Suchmaschinen.
- Wirkung im Monitoring nachhalten und die Schwellen bei Bedarf nachjustieren.
robots.txt, Sitemaps und gutes gegen schlechtes Crawling
Die robots.txt ist das erste Steuerungsinstrument, aber sie ist eine Bitte, kein Riegel. Regelkonforme Crawler etablierter Anbieter lesen sie und richten sich danach; sie eignet sich hervorragend, um kooperierende Bots von Parameter-URLs, internen Suchergebnissen und Warenkorb-Pfaden fernzuhalten und sie stattdessen über eine gepflegte Sitemap auf die wirklich relevanten Seiten zu führen. Was die robots.txt nicht leistet: Sie hält keinen Crawler auf, der sich nicht daran halten will. Deshalb braucht es die zweite Ebene -- serverseitige Grenzen, die unabhängig vom guten Willen des Clients wirken.
Sinnvoll ist eine Unterscheidung zwischen gewünschten, geduldeten und unerwünschten Zugriffen. Suchmaschinen-Crawler, die Sichtbarkeit bringen, gehören in die erste Gruppe und bekommen großzügige Grenzen. KI-Crawler, die Inhalte für Assistenten sammeln, kann man dulden, aber deckeln, damit sie nicht die gesamte Kapazität beanspruchen. Alles, was sich weder identifizieren noch begrenzen lässt und nur Last erzeugt, wird strenger behandelt. Diese Einordnung ist eine betriebliche Entscheidung, die zur Geschäftslage passen muss -- und die sich, wie die WAF- und Bot-Pflege im Shop, regelmäßig überprüfen lässt, weil sich das Crawler-Feld schnell ändert.
robots.txt ist eine Bitte, kein Schloss
Warum das in den Wartungsvertrag gehört
KI-Crawler-Last ist kein einmaliges Problem, das man löst und abhakt. Das Crawler-Feld verändert sich fast monatlich: Neue Agenten kommen hinzu, bestehende ändern ihr Verhalten, und einzelne legen sprunghaft zu -- ClaudeBot etwa um 66 Prozent (Cloudflare Radar) allein im Juni 2026. Eine Konfiguration, die heute passt, kann in einigen Wochen zu locker oder zu streng sein. Genau darum gehört die Steuerung von Serverlast und Crawl-Verhalten in denselben Rhythmus wie Sicherheitsupdates, Backups und Verfügbarkeitskontrolle. Ein SLA-Wartungsvertrag legt fest, ab welcher Lastschwelle reagiert wird, wie schnell und mit welchen Maßnahmen -- damit aus einer Crawl-Spitze kein Ausfall und aus stetiger Last keine schleichend steigende Rechnung wird. Sie steht damit neben weiteren wiederkehrenden Bausteinen wie dem Schutz der Kundenkonten vor Account-Takeover und der automatisierten Erneuerung kurzlebiger TLS-Zertifikate.
Der Zusammenhang mit den Kosten ist direkt: Wer weiß, dass ein Shop-Ausfall oder eine lahme Seite bares Geld kostet, sieht die KI-Crawler-Last mit anderen Augen. Wie hoch die Ausfallkosten pro Minute wirklich sind, macht deutlich, warum stabile Antwortzeiten kein Luxus sind. In Kombination mit einer soliden Lasttest- und Skalierungsstrategie für Spitzenlast und dem Blick auf die Datenbank-Wartung entsteht ein Gesamtbild: Der Shop bleibt schnell und günstig, auch wenn die Maschinen die Mehrheit stellen. Wer das strukturiert angehen will, findet in unseren Wartungspaketen den passenden Rahmen -- am Anfang steht eine Bestandsaufnahme von Last, Cache und Crawler-Anteil, die sich unverbindlich anfragen lässt.