Bots stellen 2026 erstmals die Mehrheit des HTML-Traffics
Die Verschiebung ist historisch. Über Jahre bewegte sich der Bot-Anteil am Web-Traffic um die 40- bis 50-Prozent-Marke, doch 2026 kippte das Verhältnis: 57,5 % der HTML-Anfragen im Netz gingen auf automatisierte Programme zurück, nur noch 42,5 % auf Menschen (Cloudflare Radar). Gemessen werden dabei genau die HTML-Dokumente, die auch Analytics-Skripte und Werbung tragen - nicht Videostreaming, E-Mail oder Gaming. Der Befund trifft also unmittelbar die Seiten, auf denen Reichweite und Conversion gemessen werden.
Innerhalb dieses Bot-Anteils wachsen die KI-Crawler am schnellsten. Der weit überwiegende Teil ihrer Aktivität dient dem Training: Über einen Zwölfmonatszeitraum entfielen 80 % des KI-Crawlings auf das Einsammeln von Trainingsdaten, 18 % auf die Suche und nur rund 2 % auf nutzerausgelöste Aktionen (Cloudflare Radar). Der Training-Anteil ist dabei im Jahresvergleich von 72 % auf 79 % gestiegen (Cloudflare Radar) - die Crawler holen also zunehmend mehr Inhalte für Modelle ab, nicht für die direkte Beantwortung einer Nutzerfrage. In der ersten Augustwoche 2025 entfielen allein auf ClaudeBot und GPTBot zusammen fast die Hälfte der beobachteten KI-Crawling-Aktivität (Cloudflare Radar).
Jeder KI-Crawler, der als Besucher in die Analytics rutscht, verwässert Sessions, Verweildauer und Conversion-Rate - genauso wie klassische Bots. Weil KI-Crawler bevorzugt inhaltsreiche Seiten abholen, ist die Verzerrung nicht gleichmäßig, sondern gerichtet. Wie sich automatisierter Traffic serverseitig aussortieren lässt, ohne echte Nutzer zu verlieren, beschreibt der Beitrag dazu, wie Sie Bot-Traffic sauber aus den Analytics filtern.
Wichtig ist, diese Anteile nicht als Momentaufnahme zu lesen, sondern als Trend. Der Bot-Anteil steigt Jahr für Jahr, und die KI-Crawler treiben diese Entwicklung. Eine Website, die heute noch mit einem ungefilterten Roh-Traffic arbeitet, misst mit jedem Quartal ein stärker verzerrtes Bild - und trägt zugleich eine wachsende technische Last, die niemand bestellt hat.
GPTBot, ClaudeBot und Co: wer da eigentlich crawlt
Um KI-Crawler zu messen und zu steuern, muss man zuerst wissen, mit welchen Automaten man es zu tun hat. Die großen Anbieter setzen nicht einen einzigen Crawler ein, sondern mehrere - jeweils mit einem eigenen Zweck und einer eigenen Kennung. Genau diese Trennung ist später der Schlüssel zur gezielten Steuerung.
GPTBot sammelt Inhalte für das Modelltraining (User-Agent GPTBot/1.4), OAI-SearchBot liefert Seiten für die ChatGPT-Suche, und ChatGPT-User ruft Seiten auf direkte Nutzeraktion hin ab. GPTBot und OAI-SearchBot befolgen robots.txt und lassen sich unabhängig voneinander einstellen (OpenAI GPTBot-Dokumentation).
ClaudeBot holt Web-Inhalte für das Training, Claude-User ruft Seiten im Auftrag einzelner Nutzer ab, und Claude-SearchBot verbessert die Suchergebnisse. Alle drei halten sich an robots.txt und unterstützen die Direktive Crawl-delay (Anthropic ClaudeBot-Dokumentation).
Googlebot crawlt für die klassische Google-Suche, während Google-Extended allein steuert, ob Inhalte für Gemini und Vertex AI genutzt werden. Google-Extended hat keinen Einfluss auf das Suchranking und lässt sich über ein eigenes robots.txt-Token separat regeln (Google Search Central).
Die entscheidende Erkenntnis: Training-Crawler und Such-Crawler sind bei allen drei Anbietern getrennte Kennungen. GPTBot ist nicht OAI-SearchBot, ClaudeBot ist nicht Claude-SearchBot, und Google-Extended ist nicht Googlebot. Dadurch lässt sich das Training aussperren, ohne die Sichtbarkeit in KI-gestützten Suchantworten zu opfern. Voraussetzung ist eine sauber gepflegte robots.txt - welche Stolperfallen dort lauern, zeigt der Beitrag dazu, wie Sie robots.txt-Fehler vermeiden.
GPTBot, OAI-SearchBot, ClaudeBot, Claude-SearchBot und Googlebot halten sich an robots.txt (OpenAI GPTBot-Dokumentation; Anthropic ClaudeBot-Dokumentation; Google Search Central). Bei nutzerausgelösten Abrufen wie ChatGPT-User weist OpenAI ausdrücklich darauf hin, dass robots.txt-Regeln möglicherweise nicht greifen, weil die Anfrage direkt von einer Nutzeraktion stammt (OpenAI GPTBot-Dokumentation). Für die verlässliche Erkennung reicht die Kennung allein deshalb nicht - die Herkunft muss zusätzlich geprüft werden.
Warum KI-Crawler messbare Serverlast erzeugen
KI-Crawler sind nicht nur ein Messproblem, sondern eine reale Last für die Infrastruktur. Anders als ein Mensch, der ein paar Seiten liest, arbeiten Crawler systematisch: Sie holen im Bulk große Mengen an Unterseiten ab, oft auch selten aufgerufene Tiefen einer Website. Genau dieser Zugriff ist teuer, weil er an den Caches vorbei bis in die Kern-Rechenzentren durchschlägt, statt aus dem günstigen Zwischenspeicher bedient zu werden.
Die Wikimedia Foundation hat das Ausmaß beziffert. Seit Januar 2024 stieg die Bandbreite für das Herunterladen von Multimedia-Inhalten um 50 % - getrieben vor allem von automatisierten Programmen, die den Bildkatalog für KI-Modelle abgrasen (Wikimedia Foundation). Noch aufschlussreicher ist die Lastverteilung: Mindestens 65 % des ressourcenintensivsten Traffics stammen von Bots, obwohl Bots nur rund 35 % der Seitenaufrufe ausmachen (Wikimedia Foundation). Ein kleiner Anteil der Zugriffe verursacht also einen überproportional großen Anteil der Kosten. Die Foundation blockiert oder drosselt inzwischen etwa 30 % der automatisierten Anfragen, die sich nicht an die Regeln halten - bei bis zu Milliarden Requests pro Tag (Wikimedia Foundation).
Über die Hälfte des Crawl-Traffics von KI-Bots entfällt darauf, unveränderte Seiten erneut abzurufen (Cloudflare Radar). Das bedeutet: Ein großer Teil der Last erzeugt keinerlei neuen Nutzen, sondern wiederholt schlicht, was der Crawler bereits kennt. Für den Seitenbetreiber ist das doppelt ärgerlich - er zahlt Rechenzeit und Bandbreite für Abrufe, die weder ihm noch dem Crawler etwas bringen.
Für kleinere Seiten ohne die Reserven einer großen Stiftung ist die Konsequenz greifbar: Ein aggressiver Crawler, der in kurzer Zeit hunderte Seiten abruft, kann die Antwortzeiten sichtbar nach oben treiben und im Extremfall den Server an seine Grenzen bringen. Wer seine Antwortzeiten nicht nur im Mittel, sondern an den Ausreißern beobachtet, erkennt solche Spitzen früh - wie das mit Perzentilen funktioniert, erklärt der Beitrag zu Antwortzeit-Perzentilen P95 und P99.
KI-Crawler von echten Besuchern trennen: Logs und Traffic
Um KI-Crawler sauber aus der Reichweite herauszurechnen, braucht es eine zuverlässige Erkennung. Drei Signale wirken zusammen, und keines allein genügt.
- User-Agent-Kennung - GPTBot, ClaudeBot, OAI-SearchBot, Claude-SearchBot und Googlebot deklarieren sich in der Kennung. Das ist der erste, schnellste Filter, aber auch der leicht fälschbare: Ein Skript kann jede Kennung vortäuschen.
- IP-Verifikation - OpenAI veröffentlicht die IP-Bereiche seiner Crawler in öffentlich abrufbaren Listen (OpenAI GPTBot-Dokumentation), und Anthropic stellt eine Liste bereit, über die sich ein Zugriff als echter Anthropic-Bot bestätigen lässt (Anthropic ClaudeBot-Dokumentation). Nur wer sowohl die passende Kennung als auch eine IP aus dem offiziellen Bereich sendet, ist wirklich der angegebene Crawler.
- Netzherkunft (ASN) - Zugriffe aus Rechenzentrums-Netzen sind mit hoher Wahrscheinlichkeit maschinell, weil Menschen praktisch nicht aus einem Hosting-Netz surfen. Dieses Signal fängt auch getarnte Automaten, die eine unauffällige Browserkennung senden.
In den Server-Logs zeigen sich KI-Crawler an typischen Mustern: Sie ziehen systematisch die Sitemap ab, folgen Links in die Breite und Tiefe, halten oft feste Zeitabstände ein und tragen die charakteristische Kennung. Für die Analytics ist entscheidend, dass diese Zugriffe gar nicht erst als Session gezählt werden. Eine serverseitige, cookielose Analytics prüft die Netzherkunft beim Eingang und markiert Rechenzentrums-Traffic, bevor er eine Sitzung bildet - unabhängig davon, welche Kennung er vorgibt.
| Erkennungsweg | Was er leistet | Grenze |
|---|---|---|
| User-Agent-Filter | Fasst offen deklarierte Crawler (GPTBot, ClaudeBot) sofort | Kennung ist fälschbar; getarnte Bots entgehen |
| IP-Verifikation | Bestätigt echten Crawler über offizielle IP-Liste | Nur für Anbieter mit veröffentlichten Bereichen |
| ASN-/Rechenzentrums-Erkennung | Erkennt maschinellen Traffic an der Netzherkunft | Braucht kuratiertes Verzeichnis, um Endkunden nicht zu treffen |
| Kombination aller drei | Trennt Mensch und Maschine belastbar | Laufende Pflege nötig |
Der Aufwand lohnt sich doppelt: Saubere Analytics-Daten und ein klares Bild davon, welcher Crawler wie viel Last erzeugt. Erst wenn KI-Crawler getrennt erfasst sind, lässt sich entscheiden, welche man willkommen heißt und welche man drosselt.
Steuern per robots.txt und llms.txt, ohne Auffindbarkeit zu verlieren
Die häufigste Fehlreaktion auf KI-Crawler ist das pauschale Aussperren - und genau das kann teuer werden. Wer alle KI-Bots blockt, verliert nicht nur Trainings-Crawler, sondern auch die Such-Crawler, die eine Seite in KI-gestützten Suchantworten sichtbar machen. Die Lösung liegt in der getrennten Steuerung über die Kennungen.
# Training aussperren, Suche behalten
User-agent: GPTBot
Disallow: /
User-agent: ClaudeBot
Disallow: /
User-agent: Google-Extended
Disallow: /
# Such-Crawler bewusst erlauben
User-agent: OAI-SearchBot
Allow: /
User-agent: Claude-SearchBot
Allow: /
User-agent: Googlebot
Allow: /Mit dieser Aufteilung bleibt eine Website für die KI-Suche auffindbar, während die reinen Trainings-Crawler draußen bleiben. Ein wichtiges Detail: Bei OpenAI kann es rund 24 Stunden dauern, bis eine geänderte robots.txt in den Systemen greift (OpenAI GPTBot-Dokumentation). Bei Google gilt zudem, dass eine Disallow-Regel das Crawling verhindert, aber nicht das Indexieren - wer eine URL zuverlässig aus dem Index halten will, braucht noindex statt nur robots.txt (Google Search Central).
Neben robots.txt hat sich mit llms.txt ein zweiter, ergänzender Ansatz etabliert. Es handelt sich um eine vorgeschlagene Konvention: eine Markdown-Datei im Wurzelverzeichnis, die Sprachmodellen kuratierte, gut strukturierte Inhalte und Verweise bereitstellt. Wichtig ist die Abgrenzung - llms.txt ist ein Angebot zur inhaltlichen Aufbereitung, kein Zugriffs-Schutz. Die Zugriffssteuerung leistet robots.txt, die inhaltliche Kuratierung für Modelle kann llms.txt übernehmen. Wer in KI-Antworten präsent sein möchte, kombiniert beides: Such-Crawler erlauben und die eigenen Inhalte für Modelle sauber aufbereiten. Wie sich die Präsenz in KI-Systemen messen lässt, zeigt die KI-Sichtbarkeit.
Ein völliges Aussperren aller KI-Crawler reduziert zwar die Last, kann aber die Auffindbarkeit in KI-Suchmaschinen kosten. Umgekehrt bedeutet freies Crawling volle Serverlast. Die tragfähige Linie liegt dazwischen: Training gezielt begrenzen, Suche erlauben, aggressive Zugriffe drosseln und die tatsächliche Last laufend messen. So bleibt die Entscheidung datenbasiert statt reflexhaft.
Wer die Skripte und Fremdzugriffe seiner Seite ohnehin absichern will, sollte KI-Crawler-Steuerung als Teil einer breiteren Web-Hygiene sehen. Die aktuellen Angriffsklassen fasst der Beitrag zu den OWASP Top 10 2025 zusammen; wie sich client-seitige Skripte im Zahlungskontext absichern lassen, behandelt der Beitrag zur PCI-DSS-4.0.1-Client-Side-Security.
Lastspitzen und Antwortzeit-Anomalien früh erkennen
Steuerung per robots.txt wirkt nur bei Crawlern, die sich daran halten. Für den Rest - und für den Fall, dass ein sonst gutartiger Crawler plötzlich aggressiv wird - braucht es Beobachtung. Eine plötzliche Welle aus hunderten Abrufen in kurzer Zeit zeigt sich zuerst an zwei Stellen: an steigenden Antwortzeiten und an einem untypischen Traffic-Muster.
Genau hier setzt kontinuierliches Uptime-Monitoring an. Wird eine Seite regelmäßig aus mehreren Regionen abgefragt, fällt eine crawler-bedingte Verlangsamung auf, lange bevor echte Besucher sie als träge Seite erleben. Statt starrer Schwellenwerte hilft eine adaptive Baseline, die den normalen Tages- und Wochenverlauf kennt und nur dann alarmiert, wenn die Antwortzeit wirklich aus dem Rahmen fällt. Wie eine solche automatische Anomalie-Erkennung arbeitet, beschreibt der Beitrag zur KI-gestützten Anomalie-Erkennung im Website-Monitoring.
Steigen die Antwortzeiten plötzlich, ist ein aggressiver Crawler eine der ersten Ursachen, die zu prüfen sind. Multi-Region-Checks trennen ein echtes Lastproblem von einer regionalen Netzstörung.
Eine Meldung, sobald die Antwortzeit über die gewohnte Bandbreite steigt, verschafft Vorsprung - per E-Mail, Slack, Discord oder Telegram, bevor die Seite für Nutzer spürbar langsam wird.
Ein untypischer Anstieg der Abrufe, besonders aus Rechenzentrums-Netzen, ist ein Frühindikator. Getrennt erfasste Crawler-Zugriffe machen solche Muster überhaupt erst sichtbar.
Wer die Last kennt, kann gezielt reagieren: Crawl-delay setzen, einzelne Crawler drosseln oder Kapazität nachziehen - eine bewusste Entscheidung statt eines plötzlichen Ausfalls.
Was XICTRAQ beim KI-Crawler-Monitoring leistet
XICTRAQ verbindet die drei Ebenen, die KI-Crawler-Traffic beherrschbar machen: saubere Messung, laufende Überwachung der Last und die Einordnung verdächtiger Zugriffe. Die folgende Übersicht zeigt, welche Bausteine dabei zusammenwirken.
Verfügbarkeit und Antwortzeiten werden aus mehreren Regionen gemessen, sodass crawler-bedingte Lastspitzen auffallen, bevor die Seite langsam wird - der Kern des Uptime- und Antwortzeit-Monitorings.
Rechenzentrums-Traffic wird ASN-basiert markiert und aus der Reichweite genommen, sodass KI-Crawler die Analytics nicht aufblähen - Grundlage der cookielosen Messung.
Ungewöhnliche Antwortzeiten oder Traffic-Muster lösen eine Meldung per E-Mail, Slack, Discord oder Telegram aus - auf Basis einer adaptiven Baseline statt starrer Schwellen.
Ein echter Browser prüft, welche Skripte und Fremd-Aufrufe eine Seite lädt - Teil des Sicherheits-Scans, der verdächtige Zugriffe sichtbar macht.
Lastverläufe und Verfügbarkeit lassen sich in verständlichen Berichten und einer öffentlichen Statuspage aufbereiten - siehe Reporting und Statuspage.
Während die Last gesteuert wird, bleibt die Präsenz in KI-Antworten messbar, sodass die Balance zwischen Schutz und Auffindbarkeit datenbasiert bleibt.
Der gemeinsame Nenner ist die Perspektive des echten Besuchers: KI-Crawler werden erkannt, ihre Last wird beobachtet, und die Reichweite bleibt frei von automatisiertem Rauschen. Den praktischen Einstieg bieten die Preisübersicht und eine unverbindliche Live-Demo, in der sich Antwortzeiten und Traffic-Muster direkt nachvollziehen lassen.
Dieser Artikel basiert auf Daten und Dokumentationen von: Cloudflare Radar (57,5 % Bot-Anteil an HTML-Anfragen gegenüber 42,5 % Menschen im Juni 2026; 80 % des KI-Crawlings für Training, 18 % Suche, 2 % Nutzeraktionen, Training-Anteil von 72 % auf 79 % im Jahresvergleich; ClaudeBot und GPTBot zusammen fast die Hälfte der KI-Crawling-Aktivität in der ersten Augustwoche 2025; Crawl-zu-Besuch-Verhältnisse im Juli 2025 rund 38.000:1 für ClaudeBot, 1.091:1 für GPTBot und etwa 5:1 für Googlebot; über die Hälfte des KI-Crawl-Traffics als erneutes Laden unveränderter Seiten), Wikimedia Foundation (Multimedia-Bandbreite seit Januar 2024 um 50 % gestiegen; mindestens 65 % des ressourcenintensivsten Traffics von Bots bei rund 35 % der Seitenaufrufe; Drosselung oder Blockade von etwa 30 % der regelwidrigen automatisierten Anfragen), OpenAI GPTBot-Dokumentation (Kennungen GPTBot, OAI-SearchBot, ChatGPT-User; robots.txt-Verhalten; veröffentlichte IP-Bereiche; rund 24 Stunden bis robots.txt-Änderungen greifen), Anthropic ClaudeBot-Dokumentation (Kennungen ClaudeBot, Claude-User, Claude-SearchBot; robots.txt und Crawl-delay; IP-Liste zur Verifikation) und Google Search Central (Googlebot und Google-Extended; separates robots.txt-Token; Unterschied zwischen Crawling und Indexierung). Angaben ohne Gewähr; rechtliche und technische Entscheidungen sollten im Einzelfall geprüft werden.