KI-Bots mit Logfiles auswerten: Was, wie und warum

Bots haben das Web übernommen. Das ist nicht neu: Laut dem 2025 Bad Bot Report hatte automatisierter Traffic schon 2024 den menschlichen überholt. Außerdem haben wir uns schon immer dafür interessiert, ob Googlebot und seine per User Agent ihre Identität bekennenden und willkommenen Kollegen unsere Inhalte finden, besuchen und dem Index hinzufügen. Seit KI Crawler das gleiche Spielfeld betreten haben und uns ebenso (in den meisten Fällen) willkommen sind, haben sich zu Tools rund um Insights zu Suchmaschinen inzwischen reichlich neue Quellen ergeben, an denen wir Daten zu Chat GPT & Co. bekommen. Bing Webmaster Tools, Microsoft Clarity, die Google Search Console sind "First Party" Quellen, die allerdings stets nur einen Teil der Story erzählen können. Im komplett neu entstandenen Markt der Prompt- und KI-Rank Tracker wird ebenso versucht, Traansparenz in die eigene Rolle in Antworten und Trainingsdaten zu finden.

Eine der vollständigsten Quellen zu KI-Crawler Daten aber sind die Logfiles des eigenen Servers. Wie diese mit minimalem Aufwand hinsichtlich GPTBot, ClaudeBot, PerplexityBot und anderen unterscht werden und hilfreiche Einsichten generiert werden können, zeigt dieser Beitrag.

Logfiles und KI-Crawler User Agents

Was ein LLM auf dem Server anstellt - ob es überhaupt hereinkommt, welche Seiten es mitnimmt und was der Server ihm dabei zurückgibt - entscheidet mit darüber, ob die eigenen Inhalte irgendwann in einer KI-Antwort auftauchen. Und das steht an genau einer Stelle: im Serverlog. Eine wichtige Einschränkung sollte dabei aber von Anfang an bekannt sein: Genau wie bei Suchmaschinen ist der User Agent kein verlässlicher Indikator. Ähnlich wie bei Suchmaschinen gibt es auch für KI-Crawler Gründe, warum er gelegentlich lieber wie ein regulärer Chrome auf Windows 11 oder eine andere "unauffällige" Maschine daherkommt. Und auf der anderen Seite sind es Tools, die Gründe haben, sich als Googlebot oder ChatGPT auszugeben. Solche Fehlinformationen spiegeln sich auch in Logfiles wieder und ohne weitere Merkmale wie IP-Adressen, Muster in Frequenz und Regelmäßigkeit der Aufrufe etc. sind rein User Agent basierte Auswertungen nicht perfekt.

Das Gute daran: Es muss auch gar nicht perfekt sein. Um ein erstes Gefühl dafür zu bekommen, ob und wie KI-Crawler die eigene Website besuchen und a) welche Inhalte und b) Probleme sie dort vorfinden.

Vorgefertigte "KI-Bot-Auswertungen" in Logalytrix

Ich habe mich selbst durch Fragestellungen rund um KI-Bots wieder verstärkt mit der Anforderung konfroniert gesehen, regelmäßig(er) in Logfiles zu schauen. Deshalb habe ich mir mit Logalytrix ein eigenes Werkzeug geschaffen, das unter anderem eben auch diesen Bereich abdeckt.

Es ist also kein spezialisiertes Tool für KI-Crawler. Aber durch passende Kategorisierung und flexible Filter sind viele der dort zu findenden Auswertungen speziell auf KI-Crawler anzuwenden. Zudem existiert eine eigene Bot-Auswertung im Tool, die bei Fragen zu KI-Bots ganz besonders hilfreich ist. Das lliegt vor allem daran, dass Logalytrix die Hits aus den Logs in verschiedene Kategorien einteilt. Keie davon ist perfekt, aber durch vorgefertigte Filter kann man sich den o. a. groben Eindruck verschaffen, ohne sich lange mit Konfiguration auseinanderzusetzen. Was ist Browser, was ist Bot und was dient offebar eher einem "Angriff" auf den Server bzw. der Suche nach Schwachstellen? Ohne Anspruch auf Perfektion wird diese Klassifizierung schon beim Import anhand einfacher Signale vorgenommen. Genauso werden Hits anhand des User Agents einer Kategorie zugeordnet. "KI-Crawler" lautet eine davon - und die ist nochmals in "Training" vs. "Grounding" unterteilt (zum Verfahren gleich mehr).

Training oder Grounding? Zwei Bots, zwei unterschiedliche Aufgaben

KI-Bots sind die einzigen im Tool, die eine solche Unterklassifizierung erhalten haben. Warum? Wenn man Zahlen zu KI-Crawlern auswerte will, lohnt sich diese Unterscheidung im Kontext von KI-Bots ganz besonders. Ein KI-Anbieter schickt in der Regel mehrere Bots los, welche vollkommen unterschiedliche Aufgaben haben.

• Training: Offline-Crawler, die große Textmengen einsammeln, um damit die nächste Modellversion zu trainieren. GPTBot (OpenAI), ClaudeBot (Anthropic), CCBot (Common Crawl), Meta-ExternalAgent gehören hierher. Was heute gecrawlt wird, beeinflusst frühestens das übernächste Modell - es kann Monate dauern, bis überhaupt etwas davon in einer Antwort landet.
• Grounding / Retrieval: Live-Crawler, die eine Seite in dem Moment abrufen, in dem ein Nutzer eine passende Frage stellt. OAI-SearchBot und ChatGPT-User (OpenAI), Claude-User / Claude-SearchBot (Anthropic), PerplexityBot gehören hierher. Diese Abrufe entscheiden, ob man in einer KI-Antwort zitiert werden kann.

Der Unterschied hat handfeste Folgen. Man kann sich per robots.txt aus dem Training heraushalten und trotzdem für Grounding erreichbar bleiben - oder umgekehrt aus Versehen den Grounding-Bot blocken und sich damit unsichtbar machen, während man eigentlich nur das Training verhindern wollte. Wenn sich Bots denn überhaupt an die dortigen Anweisungen halten.

Nach Cloudflares Auswertung entfallen rund 79 Prozent des KI-Crawlings auf Training, 17 Prozent auf Suche und gut 3 Prozent auf nutzergetriebene Abrufe (Stand Mitte 2025). Das meiste Volumen war zu dieser Zeit also Training - die wenigen Grounding-Abrufe sind aber die, bei denen sich jemand konkret für die eigene Seite interessiert. Wenngleich sich die Verhältnisse inzwischen verschoben haben können, bleibt die Unterscheidung des Zwecks wesentlich.

In Logalytrix können KI-Crawler daher gesamt als Kategorie oder für die Unterklassen Training und Grounding gefiltert werden. Rund 70 bekannte Bots werden dazu namentlich über Muster im User-Agent erkannt, der Rest über generische Signale. So entstehen keine exakten Zahlen - eine forensische Bot-Verifikation per Reverse-DNS und andere o. a. Merkmale fließen hier nicht ein. Die typischen, bekannten und relevanten Bots in der richtigen Unterkategorie helfen in Logalytrix aber dennoch, ohne langes Setup einen Eindruck zu bekommen.

Wie viel Log ist genug?

Logalytrix läuft komplett im Browser, die Daten landen in der IndexedDB. Das ist bequem und hat eine natürliche Grenze: Was in den Browser passt, ohne dass jeder Ansichtswechsel zäh wird, ist endlich. Ein Logfile von einem gut besuchten Server über mehrere Monate sprengt das - und bringt für die Frage nach KI-Bots wenig zusätzlichen Erkenntnisgewinn.

Für einen ersten Eindruck reicht eine einzelne Logdatei völlig. Ein Tag, eine Woche, je nach Traffic. Bot-Verhalten ist erstaunlich gleichförmig: Wer sehen will, ob GPTBot 200er oder 429er kassiert, braucht dafür keine 40 Millionen Zeilen. Eine Stichprobe ist als Indikator meistens gut genug, und sie ist schnell geladen. Danach kann anhand der Größe der einzelnen Logfiles grob berechnet werden, ob und wie viele weitere Tage man sich im Browser ansehen kann. Dennoch: Nicht jede Website hat "wenig genug" Traffic in den Logfiles, um mit diesem Werkzeug ausgewertet zu werden. Ein Trick mag aber helfen:

Will man doch längere Zeiträume abdecken, muss nicht alles importiert werden. Der Import-Dialog von Logalytrix erlaubt, den Umfang schon beim Einlesen zu beschränken. Wählt man Browser und Angriffe ab und lässt nur Bots stehen, wird der ganze Menschen- und Angreifer-Traffic gar nicht erst importiert. Damit ist bei einer typischen Website bereits eine Menge eingespart, so dass ggf. Wochen statt Tage ins gleiche Limit passen. Wer noch enger filtern will, kann zusätzlich Dateitypen und / oder Bereinigungsregeln filtern (etwa bestimmte nur mit Anmeldung erreichbare Pfade) und so den Import faktisch auf das reduzieren, was relevant ist. Im ersten Schritt aber auf einzelne Statuscodes zu schauen, ist nicht zu empfehlen, denn gerade da steckt gelegentlich die eine oder andere Überraschung.

Ein reiner Bot-Import ist im Zweifel die sauberere Grundlage, weil alle Prozentangaben sich dann auf Bots beziehen und man nicht ständig gegen den Menschen-Traffic rechnen muss. Wer die Bots dagegen im Verhältnis zum echten Traffic sehen will (Bot-Anteil, Crawl-Waste gegen echte Seitenaufrufe), lässt Browser drin und filtert erst in der Auswertung. Beides ist legitim, es hängt an der Frage und dem Volumen der zu untersuchenden Logs.

Nachträglich KI-Bots filtern

Der Filter Nur Bots in Kombination mit der Bot-Kategorie KI-Crawler (wahlweise nur Training oder nur Grounding) blendet global alles andere aus. Aktive Filter erscheinen als Chips unter der Kopfzeile und wirken auf sämtliche Ansichten gleichzeitig. Man stellt den Filter also einmal ein und wandert dann durch die Reports, ohne ihn erneut setzen zu müssen.

KI-Bot "taugliche" Auswertungen

Nicht jede Ansicht ist für Bots sinnvoll - Sessions, Bounce-Rate und Conversion-Pfade sind auf Menschen anwendbar und Browser & Betriebssystem sind in diesem Kontext irrelevant. Für KI-Bots lohnen vor allem sieben Bereiche. Einige sind allerdings erst dann hilfreich, nachdem man den Import entsprechend eingeschränkt oder die Logs auf KI-Bots gefiltert hat:

1. Bots & Crawler: Dieser Bereich ist extra für Bots gemacht. Details zu Kategorien, einzelnen Bots, Statuscodes und Inhalten im Überblick helfen dabei, das Gesamtbild zu erfassen. Das Zeitverhalten von Bots kann helfen, Ressourcen zu Spitzenzeiten gezielt auszubauen, um z. B. zu langsame Antwortzeiten zu behandeln.
2. Crawl-Budget: Diese Auswertung kombiniert Statuscodes und Inhalte mit User-Agents. Gezielt für KI-Bots betrachtet, sieht man sowohl, ob man ein Problem hat, als auch welche Inhalte betroffen sind.
3. Dashboard: Mit gesetztem KI-Crawler-Filter wird aus dem allgemeinen Überblick ein Bot-Überblick. Täglicher Traffic zeigt, wann und wie stark gecrawlt wird, die HTTP-Status-Verteilung, wie erfolgreich - das ist der schnellste Blick auf "läuft das grundsätzlich rund".
4. Top-Seiten und Verzeichnisse: Welche Inhalte holen KI-Bots, welche werden ignoriert? Die Verzeichnis-Ansicht aggregiert nach Pfadtiefe. So sieht man, ob ein Crawler sich auf /blog stürzt und den Rest links liegen lässt - oder umgekehrt Ressourcen in Bereichen verbrennt, die gar nicht relevant sind.
5. Statuscodes: Der Kern, dazu gleich mehr.
6. Ressourcentypen: Holt der Bot Seiten oder verzettelt er sich in Bildern, CSS und JavaScript? Für einen textgetriebenen KI-Crawler ist jeder Abruf einer Schriftdatei verschenkte Zuwendung. Die Verteilung nach Inhaltstyp macht das sichtbar.
7. Zeitverlauf: Das eingebaute "Grafana für Arme" erlaubt die Untersuchung einzelner Merkmale als Balken- oder Liniendiagrammen. Nicht nur, aber vor allem für Bots hilfreich, um Ergebnisse präsentierbar zu machen.

Eigene Karten im Zeitverlauf

Warum gerade das letztgenannte Feature hier so hilfreich ist: Die eingebauten Bot-Auswertungen zeigen Momentaufnahmen und Aggregate. Interessant wird es oft erst über die Zeit - und dafür gibt es die frei konfigurierbaren Karten im Zeitverlauf. Pro Karte wählt man eine Dimension und eine Darstellung. Für Bots besonders nützlich:

• Dimension Statuscode auf einzelne Codes wie 404, 403 oder 429 gestellt, als Linien - statt nur die grobe 2xx/3xx/4xx/5xx-Verteilung. So sieht man einen 4xx-Anstieg tagesgenau kommen und gehen.
• Dimension Bot-Kategorie, um den Anteil von KI-Bots am Gesamttraffic über die Zeit zu visualisieren.
• Umschaltbar zwischen Volumen und 100 Prozent, mehrere Karten stapelbar. Eine 429-im-Zeitverlauf-Karte, gefiltert auf KI-Crawler, sagt so deutlich mehr aus, als nur eine Durchschnittszahl über den ganzen Zeitraum.

Was Statuscodes über KI-Bots verraten

Die wichtigsten Codes und was sie im Bot-Kontext bedeuten:

• 200 - der Bot hat bekommen, was er wollte. Der Normalfall, den man sehen will.
• 304 Not Modified - der Bot hat konditional angefragt (per If-Modified-Since / ETag), der Server hat "unverändert" geantwortet. Ein gutes Zeichen: Der Crawler kommt wieder und arbeitet effizient.
• 301 / 302 - Weiterleitungen. Bots folgen ihnen, aber lange Ketten oder Crawler, die auf alten URLs hängen, kosten Crawl-Budget ohne Gegenwert. Hier unterscheidet sich die abzuleitende Aktion nicht von Suchmaschinen: Wer freundlich zu den Anbietern sein möchte, verschwendet keine Ressourcen für Weiterleitungen und sorgt dafür, dass alle imternen und selbst kontrollierten Links direkt beim korrekten Ziel ankommen.
• 403 Forbidden - der Server blockt aktiv. Bei KI-Bots ist das oft Absicht (WAF-Regel, Managed-Server-Default), manchmal aber unbeabsichtigt. Wer hier einen Grounding-Bot findet, sollte genau hinsehen (Beispiel weiter unten) und ggf. die Konfiguration anpassen (oder anpassen lassen).
• 404 - der Bot crawlt tote oder alte URLs. In Maßen normal, in Menge ist es Crawl-Waste - der Crawler verbrennt sein Budget auf Seiten, die es nicht gibt. Analog zu Weiterleitungen ist ein 404 für einen KI-Bot ebenso entweder "tragisch" oder ein hilfreiches Signal nach einem Abbau von Content wie für eine Suchmaschine.
• 429 Too Many Requests - Rate Limiting. Der Server sagt "langsamer". Bei einem KI-Bot, der sich gerade für die eigenen Inhalte interessiert, ist das ein echter Verhinderer. Vor allem, wenn man detaiilierter in die Hits eines einzelnen Bots schaut und dabei feststellt, dass dieser Statuscode bereits ab dem ersten Request als Antwort kommt. Warum und wie das sein kann - siehe unten.
• 408 Request Timeout - der Server war zu langsam, der Bot hat aufgegeben. KI-Crawler sind hier oft ungeduldiger als der Googlebot. Genau deshalb ist es auch wünschenswert, Daten zur Response Time in den Logs zu haben (siehe Kasten).
• 5xx - der Server ächzt, womöglich unter der Crawl-Last selbst?

LogFormat "%h %l %u %t \"%r\" %>s %O \"%{Referer}i\" \"%{User-Agent}i\" %D" combined_rt
CustomLog /var/log/apache2/access.log combined_rt

Logalytrix bündelt einen Teil der Daten zu Statuscodes in der Kategorie-Vergleichstabelle der Bot-Ansicht: 429-Rate, 408-Rate, allgemeine Fehlerrate und die Response-Time-Perzentile (Median und P95) pro Bot-Kategorie nebeneinander. Auf einen Blick sieht man, ob KI-Crawler gegenüber Suchmaschinen benachteiligt werden - etwa durch systematisch höhere 429-Raten oder spürbar langsamere Antworten.

Neben dem "wie reagiert der Server" steht das "was holt der Bot überhaupt". Die Crawl-Budget-Analyse zeigt Bot-Hits, verbrauchte Bandbreite, Crawl-Waste (Bot-Hits auf 4xx/5xx) und - oft am aufschlussreichsten - Seiten mit echtem User-Traffic, die aber kein Bot zu untersuchen scheint (wenn man genug Tage in das Tool bekommt, um dies bewerten zu können).

Beispiele aus der Praxis

Drei Besonderheiten sind mir bei meinen Analysen mehr als einmal aufgefallen. Beide haben mit der Server-Umgebung zu tun, nicht mit der eigenen Website.

Lange Antwortzeiten

Wo Googlebot, Bing und andere Suchmaschinen vergleichsweise geduldig sind, sind die meisten KI-Crawler sehr sparsam mit der Zeit, die sie auf eine Antwort warten. Kein Inhalt oder nur halb geladene Seiten sind daher nur zu vermeiden, indem nicht nur der Content "schlank" ist, sondern auch und vor allem schnell verfügbar. Antwortzeiten werden z. B. im Dashboard dargestellt und sehen hoffentlich okay aus. Status 408 aus der obigen Übersicht ist ansonsten ein echter Gegner der eigenen GEO Strategie.

429 auf Shared Hosting

Auf geteiltem Hosting teilt man sich die vom Anbieter bereitgestellten Server-Ressourcen mit fremden Websites. Dabei geht es nicht nur um die IP oder den physikalischen Speicherplatz, sondern oft auch um Limits. Wie viel Traffic ein geteilter Server in Summe ertragen kann und darf, ist fest geregelt und man teilt diese Budgets mit einer unbekannten Anzahl an Websites, welche vielleicht mehr, vielleicht weniger Traffic als die eigene Site haben. Speziell bei Bots greifen Rate Limits dort gern früh und pauschal, oft über Module wie mod_evasive oder providerseitige Limits, die man selbst nicht sieht und nicht kontrolliert. Ein KI-Crawler, der in kurzer Zeit viele Seiten abruft, läuft schnell in eine 429-Wand - und crawlt danach seltener, weil er die Drosselung ernst nimmt. Ist das schon "aus Sicht des Servers" vor ein paar Stunden (für eine ganz andere Website im gleichen Hosting-Cluster) passiert und kommt ein Crawler nun für "meine" Inhalte zurück, ist er ggf. schon direkt ausgesperrt. Andere Hoster antworten ab irgendeinem Wert pauschal nur noch mt 403 (Forbidden). Da kann man nur hoffen, dass es der Crawler später doch noch mal versucht.

In der Auswertung sehen solche Fälle eindeutig aus: Eine hohe 429-Rate speziell in der KI-Crawler-Kategorie, während normale Besucher und der Googlebot (der behutsamer vorgeht) davon kaum betroffen sind, sind ein guter Indikator.

Zeigen die Daten dies an, lohnt sich zudem ein Blick in die Details, denn oft sind einzelne Crawler davon betroffen, weil diese pauschal vom Hoster abgewiesen werden. Diese findet man im Bereich Bots & Crawler -> Übersicht nach Klick auf einen einzelnen Eintrag in der Liste de Bots Hier im Beispiel ist es ClaudeBot, der nicht nur eine Menge an 404 bekommt, weil er sehr oft eine ungültige Sitemap abrufen wollte, sondern auch an 429 krankt und trotz 34 unterschiedlicher IPs eine Fehlerrate von 100% aufweist. Das will man vermutlich so nicht haben und die weiteren Fehler lassen sich im Tool und / oder einem Export hervorragend auseinandernehmen.

403 für ClaudeBot auf Managed Server

Der zweite Fall betrifft ein generelles Verbot. Auf einem Managed Server bei Hetzner war ClaudeBot per Default vollständig ausgesperrt: durchgehend 403, ohne dass an der Website irgendetwas falsch gewesen wäre. Der Block saß in der vorkonfigurierten Server-Umgebung. Viele Hoster machen das ähnlich. Es lohnt sich nach einem solchen Fund in den eigenen Logs, den Content für den betroffenen User Agent per Support-Ticket freigeben zu lassen. Was nutzt die beste GEO Strategie, wenn interessierte LLMs an der Tür abgewiesen werden?

Der Effekt einer solchen Aufhebung ist dann idealerweise im Zeitverlauf sicht- und kontrollierbar. Vor dem Ticket reichlich 403ern für ClaudeBot, danach der Umschwung auf vermehrte 200er. Eine passend gebaute Zeitverlauf-Karte auf den Statuscode 403, gefiltert auf die Grounding-Kategorie, macht den Knick sichtbar - Beleg dafür, dass es die Server-Umgebung war und nicht der Bot. Selbst bei Betrachtung aller Bots in einem Topf auf einer Karte des Zeitverlaufs lässt sich die Gesundung gut nachvollziehen. Nicht alle 403 sind fort (es gibt schlussendlich auch immer noch ander Bots und Inhalte, die wirklich keinen Bot etwas angehen), aber der Trend ist klar zu erkennen: 403 runter, 200 rauf.

Ist Dein Server der GEO-Flaschenhals?

Beide Fälle führen zur gleichen Erkenntnis, und die ist der eigentliche Grund, warum sich das Hinsehen lohnt. Wenn KI-Crawler die eigenen Inhalte nicht sauber abrufen können, landen diese Inhalte auch nicht in KI-Antworten. Für die Sichtbarkeit in Suchmaschinen hat man Search Console und andere Werkzeuge, die einem das von der anderen Seite zeigen. Für die Sichtbarkeit in KI-Assistenten gibt es das nur bedingt. Das eigene Log ist aktuell die beste verfügbare Quelle zur Verifikation, dass wirklich alles "nach Plan" läuft.

Wie teuer ein blockierter oder gedrosselter Crawl sein kann, zeigt eine Zahl von Cloudflare: Anthropic crawlte Mitte 2025 im Schnitt rund 38.000 Seiten für jeden einzelnen Besucher, den es an die Quelle zurückschickte (bei OpenAI etwa 1.000:1, bei Google gut 5:1). Der Rückfluss ist also ohnehin dünn. Wer den Crawler dann auch noch mit 429 oder 403 abweist, macht aus "wenig" sogar im schlimmsten Fall "nichts".

Man muss daraus keine Grundsatzentscheidung machen - manche wollen KI-Crawler bewusst draußen halten, und das ist ein legitimer Standpunkt. Aber es sollte eine bewusste Entscheidung sein und kein unbekannter Nebeneffekt einer Default-Konfiguration oder Einschränkungen der Hosting-Umgebung.

Selbst ausprobieren: Logalytrix gibt es als einzelne HTML-Datei zum Download bei GitHub. Ein Tages-Log vom eigenen Server genügt für den ersten Blick. Wenn dabei etwas Interessantes herauskommt - oder etwas fehlt, das ihr euch wünscht - freue ich mich über Feedback. Damit: Happy Analyzing!