KI-Crawler-Loganalyse

TL;DR — Bei der Analyse von KI-Crawler-Logs lesen Sie die Rohzugriffslogs Ihres Servers, um zu sehen, welche KI-Bots — etwa OpenAIs GPTBot oder Anthropics ClaudeBot — Ihre Website tatsächlich besucht haben, wie oft sie kamen und was sie erhalten haben. Nur Ihre Logs zeichnen das auf. Die Google Search Console zeigt keine KI-Bots, und Google Analytics sieht nur Menschen, die klicken, nicht die Bots selbst. Der Haken: Viel Traffic behauptet lediglich, von einem bekannten KI-Bot zu stammen, und der Name allein ist daher nicht vertrauenswürdig.

Was eine Logdatei ist

Serverzugriffslogs erfassen Anfragen, die den Server erreicht haben, einschließlich User-Agent, Zeitpunkt, Pfad und — wenn konfiguriert — Antwortdetails. Evidence for this claim Server access logs record requests and can include fields such as request path, status, referrer, and user agent. Scope: Apache HTTP Server logging; available fields depend on server configuration. Confidence: high · Verified: 2026-07-14 Apache: Log files Dokumentationen der Anbieter nennen Crawler-User-Agents, aber eine Zeichenfolge allein beweist nicht, dass der Anfragende echt ist. Evidence for this claim OpenAI publishes user-agent tokens and controls for several of its crawlers. Scope: OpenAI's documented crawlers; a user-agent string is not proof of downstream training, retrieval, citation, or use. Confidence: high · Verified: 2026-07-14 OpenAI: Crawlers

Jedes Mal, wenn irgendetwas — der Browser einer Person, Googlebot oder GPTBot — Ihren Server nach einer Seite fragt, schreibt der Server eine Zeile in eine Logdatei. Jede Zeile enthält den Zeitpunkt, die IP-Adresse des Besuchers, die angeforderte Ressource, den „User-Agent“ (eine Bezeichnung, mit der sich der Besucher identifiziert, etwa GPTBot) und den Antwortcode Ihres Servers (200 für Erfolg, 404 für nicht gefunden und so weiter).

Bei der Analyse von KI-Crawler-Logs werden diese Zeilen gelesen und auf KI-Bots gefiltert. Das beantwortet Fragen, die Sie auf keinem anderen Weg direkt beantworten können:

• Hat ein KI-Bot meine Website überhaupt besucht?
• Welche Seiten hat er abgerufen, und welche wichtigen Seiten ignoriert?
• War es der echte Bot oder jemand, der sich als Bot ausgegeben hat?
• Was hat er erhalten — meinen tatsächlichen Inhalt oder eine Fehlerseite?

Wenn Sie die gesamte Bandbreite der KI-Bots und den Zweck jedes Bots kennenlernen möchten (Trainings-Bots, Such-Bots und Bots nach dem Muster „Diese Seite jetzt abrufen“), ist das ein eigenes Thema — siehe AI crawlers. Diese Seite behandelt das Wie: Logs abrufen und lesen.

Warum Ihre Dashboards das nicht abdecken

• Google Search Console hat einen Bericht zu Crawling-Statistiken, aber er betrifft nur Googlebot. GPTBot, ClaudeBot oder PerplexityBot werden dort nicht angezeigt.
• Google Analytics (GA4) erfasst nur Besucher, die auf einen Link zu Ihrer Website klicken und mit einem „Referrer“ ankommen. Ein Crawler, der Ihre Seite im Hintergrund lädt, erscheint dort überhaupt nicht.

Damit sind die Logs die Quelle der Wahrheit. Nichts anderes sieht den Bot.

Das eine, was Anfänger übersehen

Ein GPTBot-Label in Ihren Logs beweist nicht, dass es wirklich OpenAI war. Jede Person kann bei einer Anfrage jeden gewünschten User-Agent angeben — wie eine Rücksendeadresse auf einem Briefumschlag. Viele Scraper versehen ihren Traffic mit dem Namen eines bekannten Bots, um seriös zu wirken. Sicher ist nur die Prüfung der Besucher-IP-Adresse gegen die Liste echter Adressen, die das KI-Unternehmen veröffentlicht. Dieser Verifizierungsschritt ist das Herzstück einer sauberen Analyse; der Tab Fortgeschritten führt ihn durch.

TL;DR — Rufen Sie Ihre Apache-/Nginx- oder CDN-Zugriffslogs ab und erledigen Sie dann vier Dinge: verifizieren (User-Agent abgleichen und die IP gegen die veröffentlichte Liste des jeweiligen Betreibers prüfen — die Spoofing-Raten reichen von 5,7 % bei HUMAN Security bis zu Duane Forresters selbst getesteten 81,8 %); ein Tool wählen nach Umfang (grep → Screaming Frog Log File Analyser → ELK/Splunk → BigQuery/Cloudflare); messen, wie oft jeder Bot crawlt, welche Seiten abgerufen werden, Crawl-vs.-Render und Statuscodes; und ehrlich interpretieren — Abruf ist notwendig, aber nicht ausreichend, daher ist „mehr Crawling = mehr Zitationen“ unbewiesen. Dies ist die Methode neben AI crawlers (dort geht es darum, welche Bots es gibt), AI traffic attribution (die Klickseite) und LLM visibility (der Rahmen abgerufen → erwähnt → zitiert, von dem diese Analyse nur die erste Stufe beobachtet).

Was dieser Artikel behandelt — und was nicht

Logs belegen Anfragen, nicht, ob Inhalte für Training, Abruf oder eine Antwort verwendet wurden. Evidence for this claim Server access logs record requests and can include fields such as request path, status, referrer, and user agent. Scope: Apache HTTP Server logging; available fields depend on server configuration. Confidence: high · Verified: 2026-07-14 Apache: Log files Verifizieren Sie Bots, wo verfügbar, mit den vom Anbieter veröffentlichten Verfahren und behandeln Sie die Zuordnung als begrenzten Beleg. Evidence for this claim OpenAI publishes user-agent tokens and controls for several of its crawlers. Scope: OpenAI's documented crawlers; a user-agent string is not proof of downstream training, retrieval, citation, or use. Confidence: high · Verified: 2026-07-14 OpenAI: Crawlers

Der verwandte Artikel AI crawlers behandelt bereits die Tabelle Bot für Bot, die Drei-Kategorien-Taxonomie (Training / KI-Suche / durch Nutzer ausgelöster Abruf), die Unterscheidung „Google-Extended ist ein Token, kein Bot“ sowie die robots.txt-Rezepte. Das leite ich hier nicht erneut her. AI traffic attribution behandelt die GA4-/Referrer-Seite — was der Bot zurückschickt. Dieser Artikel ist die andere Seite des Funnels: was der Bot mitnimmt. Und LLM visibility gehört der Rahmen abgerufen → erwähnt → zitiert; die Loganalyse zeigt speziell die abgerufen-Stufe und nichts darüber hinaus.

Dies ist die Fortsetzung der klassischen SEO-Logdateianalyse im KI-Zeitalter. Als ich Ahrefs’ How to Do an SEO Log File Analysis geprüft habe, waren die Dimensionen Crawlhäufigkeit, gecrawlte URLs, Statuscodes und Bot-Verifizierung anhand der von Google veröffentlichten IPs. Hier ist das Grundgerüst gleich — aber auf eine Botpopulation gerichtet, die meistens kein JavaScript rendert, ständig imitiert wird und in unregelmäßigen Schüben statt als gleichmäßiger Strom crawlt.

Schritt 1 — Logs besorgen

Ihre Logs liegen an einem von zwei Orten oder an beiden:

• Origin-Server-Logs. Apache (access.log), Nginx (access.log) oder Ihr Anwendungsserver. Jede Zeile enthält mindestens: Zeitstempel, Client-IP, Request-Methode und Pfad, Statuscode, Bytes, Referrer und User-Agent.
• CDN-/Edge-Logs. Wenn Sie Cloudflare, Fastly, Akamai oder einen ähnlichen Dienst vorgeschaltet haben, wird viel Bot-Traffic am Edge beantwortet und erreicht den Origin möglicherweise nie — das Edge-Log ist daher die vollständigere Aufzeichnung. Cloudflare stellt es über Logpush (und eine GraphQL-API) bereit, Fastly über Echtzeit-Log-Streaming.

Die Felder, die Sie für die KI-Bot-Analyse tatsächlich brauchen: Zeitstempel, Client-IP, User-Agent, Request-Pfad und Statuscode — idealerweise zusätzlich Bytes und Referrer.

Das praktische Problem ist die Aufbewahrung. Viele Hoster behalten Logs nur wenige Tage. Lauren Busbys Beitrag in Search Engine Land nennt die Lösung direkt: Ein geplanter Abruf macht aus einem kurzen Zeitfenster etwas, das sich über die Zeit analysieren lässt. Ein geplanter SFTP-Job, in einem Workflow-Tool wie n8n erstellt oder skriptiert, reicht aus, um ein kurzes Aufbewahrungsfenster dauerhaft auswertbar zu machen (Busby, SEL). Richten Sie ihn ein, bevor Sie die Daten brauchen.

Eine ehrliche Grenze sollten Sie von Anfang an beachten: Wie Busby schreibt, zeigen Logdateien, was Ihre Website erreicht hat, aber nicht immer, was sie zu erreichen versucht hat (SEL) — blockierte oder vorgelagert beantwortete Anfragen erscheinen möglicherweise überhaupt nicht.

Schritt 2 — Vor dem Vertrauen in den User-Agent verifizieren

Das ist der Schritt, der die KI-Bot-Loganalyse von der klassischen Variante unterscheidet und den die meisten konkurrierenden Anleitungen überspringen. User-Agent-Zeichenfolgen lassen sich trivial fälschen. Zwei unabhängige Datenpunkte zeigen, wie schlimm es werden kann:

• HUMAN Security analysierte zwei Wochen Traffic, der behauptete, von einem von 16 bekannten KI-Crawlern zu stammen, und stellte fest, dass 5,7 % gefälscht waren — etwa jede 18. Anfrage (über SEJ berichtet).
• Duane Forrester führte dieselbe Prüfung in seinen eigenen Logs durch und fand ein noch schlechteres Ergebnis. Von 33 Anfragen mit einem Live-Fetch-Namen kamen sechs von einer vom Anbieter veröffentlichten IP und 27 nicht — eine Spoofing-Rate von 81,8 % unter den prüfbaren Anfragen (SEJ). Bei Googlebot war seine Zahl noch schlechter: Von 799 Anfragen mit dem Namen Googlebot stammten nur 107 von einer verifizierten Google-Adresse — die übrigen rund 87 % waren nicht Google (SEJ).

Behandeln Sie diese Zahlen wegen unterschiedlicher Stichproben und Methoden als richtungsweisend, nicht als eine universelle Zahl. Noch wichtiger: Übertragen Sie die Verifizierungsmethode eines Anbieters nicht auf jeden Bot. Einige Betreiber veröffentlichen Adressbereiche; andere dokumentieren User-Agent-Tokens, aber keinen aktuellen öffentlichen Bereich und keinen DNS-Verifizierungsvertrag (SEJ).

Die Verifizierungsmethode:

1. User-Agent-Zeichenfolge abgleichen. GPTBot identifiziert sich als Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko); compatible; GPTBot/1.3; +https://openai.com/gptbot; OAI-SearchBot und ChatGPT-User führen eigene Tokens (OpenAI-Bot-Dokumentation).
2. Die aktuelle offizielle Verifizierungsmethode des Anbieters verwenden, wenn es eine gibt. OpenAI veröffentlicht openai.com/gptbot.json, searchbot.json und chatgpt-user.json. Anthropics aktuelle Crawler-Dokumentation sagt, dass eine Adresse in der veröffentlichten Liste anzeigt, dass der Crawler von Anthropic kommt. Verwenden Sie dieses aktuelle, anbieterspezifische Verfahren; verallgemeinern Sie es nicht zu einer universellen Bot-Regel.
3. Keinen Fallback erfinden. Reverse-plus-Forward-DNS ist nur dann für einen Anbieter gültig, wenn dieser das Hostnamensuffix und das Prüfverfahren veröffentlicht. Ein allgemeiner PTR-Abgleich beweist die Kontrolle über DNS, nicht die behauptete Bot-Identität. Screaming Frog Log File Analyser kann öffentlich bestätigte Listen verwenden; seine Verifizierung beim Import prüft öffentliche IP-Listen, um echte Bots zu bestätigen (Screaming Frog). @@BT@@openai.com/gptbot.json@@BT@@ @@BT@@searchbot.json@@BT@@ @@BT@@chatgpt-user.json@@BT@@

Die Verifizierung sollte eine präzise Richtlinie und die Reaktion auf Incidents ermöglichen. Bevorzugen Sie das dokumentierte robots-Token des Anbieters für eine Crawling-Richtlinie; reservieren Sie Netzwerkregeln für Missbrauchs- oder Sicherheitsfälle und kennzeichnen Sie diese getrennt von der robots-Konformität.

Schritt 3 — Ein Tool auswählen

Passen Sie das Tool an die Größe der Aufgabe an, grob von kostenlos zu kostenpflichtig und von Rohdaten zu Managed Service:

• grep / PowerShell — eine schnelle einmalige Zählung und ein verifizierungsbewusster Filter. Der Artikel AI crawlers enthält das grundlegende Bot-Zähl-Snippet; der Tab Skripte hier erweitert es um IP-Verifizierung, Statuscode-Aufschlüsselung und Crawl-vs.-Render-Erkennung.
• Screaming Frog Log File Analyser — ein Desktop-Importer mit integrierten KI-Bot-Voreinstellungen (GPTBot, OAI-SearchBot, ChatGPT-User, ClaudeBot, Claude-User, PerplexityBot, Perplexity-User, CCBot) und dem Schalter „Bots beim Import verifizieren“. Der Tab Response Codes unterteilt 2XX/3XX/4XX/5XX pro URL, User Agents zeigt Anfragen und Fehlerraten pro Bot, URLs sortiert nach Num Events (am häufigsten abgerufene Seiten) und IPs hilft bei der Untersuchung verdächtiger Quellen (Tutorial).
• ELK Stack (Elasticsearch / Logstash / Kibana) oder Splunk — für kontinuierliche Aufnahme im größeren Maßstab mit Dashboards und Alarmen, sobald ein einzelnes Desktop-Tool zu langsam wird oder Sie fortlaufendes Monitoring statt gelegentlicher Exporte benötigen.
• BigQuery — für langfristige Aufbewahrung und SQL-Abfragen im großen Maßstab, häufig gespeist über Cloudflare Logpush oder einen geplanten GraphQL-Abruf aus Cloudflares Dataset httpRequestsAdaptiveGroups. So können Sie Botaktivität nach Seite, Datum und Statuscode abfragen, ohne Flatfiles neu zu importieren.
• Cloudflare AI Crawl Control (für Websites hinter Cloudflare) — ein Managed Dashboard für Crawleraktivität und Request-Muster, Bot-Verifizierung und die Überwachung von Richtlinien, ohne eine eigene Pipeline zu bauen (Dokumentation). AI crawlers article

Schritt 4 — Was messen und wie lesen

Crawlhäufigkeit pro Bot. Treffer pro Tag oder Woche je Botname. KI-Bots crawlen in Schüben, nicht in gleichmäßigen Strömen. In WISLRs 48-tägiger CDN-Log-Fallstudie war GPTBot wochenlang abwesend und erzeugte dann 187 Anfragen in einer Woche — 152 davon in einem dreiminütigen Schub, mit einem Höchstwert von 114 Anfragen pro Minute (WISLR). Lesen Sie Häufigkeit als Muster, nicht nur als Summe.

Welche Seiten abgerufen werden — und welche wichtigen nicht. Sortieren Sie nach Anfragezahl. Busby weist darauf hin, dass KI-Crawler häufig oberflächlich bleiben: Oft beschränken sie sich auf Seiten der obersten Ebene, die Startseite, Hauptnavigation und wenige übergeordnete URLs (SEL). Für tiefe Seiten, die für Zitationen am wichtigsten sind, fällt die Zahl stark ab. Eine tiefe Seite, die nie in den Logs erscheint, kann nicht abgerufen werden.

Abhängigkeit von Roh-HTML — messen, nicht verallgemeinern. Die Dokumentation der Anbieter liefert keinen gemeinsamen JavaScript-Renderingvertrag für GPTBot, OAI-SearchBot, ChatGPT-User, ClaudeBot, PerplexityBot und andere Agents. Ein beobachtetes Muster ist trotzdem nützlich: In WISLRs Stichprobe rief ChatGPT-User nur HTML ab — null Anfragen für Bilder, CSS oder JS — während Googlebot und OAI-SearchBot auch Bilder luden (WISLR). Wenn Ihre Logs zeigen, dass KI-Bots Seiten mit einem fast leeren JS-Shell-HTML stark anfragen, ist das ein prüfbares Abhängigkeitsrisiko, kein Beweis dafür, dass jeder Anbieter immer so arbeitet. Vergleichen Sie ausgeliefertes HTML mit Ergebnissen oder anbieterspezifischen Fetch-Tests. (Für die Grundlagen des Renderings siehe JavaScript SEO.)

Aufschlüsselung von Statuscodes und Blockierungen. Beobachten Sie: 200 (Erfolg), 304 (nicht geändert — guter, effizienter Re-Crawl), 404 (fehlerhafte Links, denen der Bot gefolgt ist) und 403/429 (blockiert / rate-limitiert). Busby nennt ausdrücklich, dass Logdateien zeigen, wo Crawler auf Probleme stoßen, einschließlich 403-Antworten (blockierte Anfragen) und 429-Antworten (Ratenbegrenzung) (SEL). Prüfen Sie, ob die Blockierung beabsichtigt oder versehentlich ist.

Anfragen an robots.txt und llms.txt als eigenes Signal. Vergleichen Sie, welche Bots überhaupt /robots.txt anfragen, bevor sie crawlen — in WISLRs Stichprobe prüften GPTBot und Meta-WebIndexer die Datei über 48 Tage nie — und ob gesperrte Pfade trotzdem abgerufen werden. WISLR protokollierte außerdem über diese 48 Tage null Anfragen an /llms.txt von irgendeinem KI-Bot (WISLR), passend zum Befund aus dem Artikel AI crawlers, dass ungefähr 97 % sie nicht lesen. Erwarten Sie /llms.txt-Anfragen nicht als Beweis dafür, dass sie „funktioniert“.

Bedeutet mehr Crawling mehr Zitationen? Seien Sie ehrlich.

Keine etablierte Datenlage stützt die Aussage „mehr crawlen, mehr zitiert werden“. Abruf ist eine notwendige Voraussetzung für Zitation, aber längst nicht ausreichend — Seiten werden ständig gecrawlt und nie zitiert, etwa wegen clientseitigem Rendering, Paywalls, dünnem oder doppeltem Content oder weil sie im Abruf-/Ranking-Schritt des Modells schlicht gegen eine bessere Quelle verlieren. Der tragende Rahmen steht im Artikel LLM visibility: abgerufen → erwähnt → zitiert, und die Loganalyse beobachtet nur die erste Stufe.

Um den Kreislauf ehrlich zu schließen, verbinden Sie die Eingangsseite des Crawlings (Ihre Logs) mit der Ausgangsseite der Zitation. Bings Bericht AI Performance (öffentliche Vorschau, Februar 2026) ist das erste offizielle Tool, das Zitationsdaten zusammen mit Grounding-Abfragen zeigt — den Schlüsselphrasen, welche die KI beim Abruf von Inhalten verwendet hat, die in KI-generierten Antworten referenziert wurden (Bing Webmaster Blog). Logs sagen Ihnen, was mitgenommen wurde; Grounding-Abfragen und Zitationszahlen sagen, was daraus entstanden ist. Keines allein zeigt das ganze Bild — siehe den Hub für Messung und Reporting, der erklärt, wie die Schichten zusammenpassen.

Die Besonderheit des Stealth-Crawlings

Verifizierung ist kein einmaliges Audit. Laut Clint Spaulding von Seer Interactive können verdeckte Crawler nach einer Blockierung unter generischen Browser-Headern und mit anderen IPs wieder auftauchen. Diese Sitzungen sehen in Logs menschlich aus; dadurch werden Sitzungszahlen aufgebläht, Bot-Traffic unterschätzt und GEO-Segmente weniger zuverlässig (Seer). Seine deutliche Zusammenfassung: Wenn Sie diese Stealth-Crawler nicht sehen, können Sie ihre Auswirkungen nicht messen. Genau deshalb braucht Loganalyse regelmäßige Neuverifizierung und neue Baselines, nicht nur einen Durchlauf.

KI-Zusammenfassung

Eine komprimierte Zusammenfassung der Advanced-Version:

• KI-Crawler-Loganalyse = Rohserver- oder CDN-Logs nach KI-Bot-Anfragen lesen, um anhand eigener Daten zu verifizieren, welche Bots Sie erreichen, ob sie echt sind und was sie erhalten haben. GSC (nur Googlebot) und GA4 (nur Referrer) sehen das nicht.
• Umfang: Hier geht es um die Methode. Welche Bots es gibt, gehört zu AI crawlers; die Klickseite zu AI traffic attribution; der Rahmen abgerufen → erwähnt → zitiert zu LLM visibility (Logs beobachten nur abgerufen).
• Verifizierte Identität von einem behaupteten User-Agent trennen. User-Agents werden gefälscht — HUMAN Security maß 5,7 % über 16 Bots; Duane Forrester testete 81,8 % Fälschungen unter seinen Live-Fetch-Anfragen (87 % bei Googlebot). Gleichen Sie den UA ab und prüfen Sie die Quell-IP gegen die aktuelle offizielle Liste des Betreibers, sofern vorhanden (etwa openai.com/gptbot.json oder Anthropics claude.com/crawling/bots.json). Erfinden Sie keinen allgemeinen Reverse-DNS-Fallback.
• Tools nach Umfang: grep → Screaming Frog LFA (KI-Voreinstellungen und Verifizierung beim Import) → ELK/Splunk → BigQuery / Cloudflare AI Crawl Control.
• Messen: Crawlhäufigkeit je Bot (Schübe, etwa WISLRs 152 GPTBot-Anfragen in 3 Minuten), abgerufene Seiten, Roh-HTML-Abhängigkeit (ChatGPT-User lud in WISLRs Stichprobe null Bilder/CSS/JS), Statuscodes (403/429) und robots.txt-/llms.txt-Anfragen (WISLR protokollierte in 48 Tagen null llms.txt-Treffer).
• Crawling ≠ Zitation. Abruf ist notwendig, aber nicht ausreichend — „mehr Crawls = mehr Zitationen“ ist unbewiesen. Verbinden Sie Logs mit Bings Grounding-Abfragen.
• Regelmäßig neu verifizieren — blockierte Stealth-Crawler tauchen wieder auf und sehen menschlich aus.

Offizielle Dokumentation

Primärquellen — die eigenen Verifizierungsdateien der Bot-Betreiber und die Plattformdokumentation.

OpenAI

• OpenAI-Bots / Crawler-Dokumentation — User-Agent-Zeichenfolgen und Verhalten von GPTBot, OAI-SearchBot, ChatGPT-User und OAI-AdsBot.
• Veröffentlichte IP-Listen zur Verifizierung: gptbot.json, searchbot.json, chatgpt-user.json, adsbot.json.

Anthropic

• Crawlt Anthropic Daten aus dem Web? — aktuelle Botnamen, Zwecke, robots-Steuerung und die Aussage, dass eine Adresse in der veröffentlichten Liste einen Anthropic-Crawler anzeigt.
• Anthropic-Crawler-IP-Liste — aktuelle gemeinsame Verifizierungsquelle für ClaudeBot, Claude-SearchBot und Claude-User.

Google

• Bericht zu Crawling-Statistiken — Googles eigene Ansicht der Crawlaktivität (nur Googlebot; Drittanbieter-KI-Bots werden nicht erfasst, weshalb für sie Rohlogs nötig sind).

Cloudflare

• AI Crawl Control — Managed Dashboard für KI-Crawleraktivität, Bot-Verifizierung und Richtlinienkonformität.

Bing / Microsoft

• AI Performance in den Bing Webmaster Tools (öffentliche Vorschau) — das Gegenstück zur Loganalyse auf der Zitationsseite: Total Citations, Average Cited Pages, Grounding Queries und Zitationsaktivität auf Seitenebene.

Zitate aus den Quellen

Dokumentierte Aussagen von Betreibern und namentlich genannten Praktikern.

Anthropic — aktueller Umfang

• Anthropics aktuelle Supportseite unterscheidet ClaudeBot, Claude-SearchBot und Claude-User, dokumentiert die Anwendung ihrer robots-Steuerung und sagt, dass eine Adresse in der veröffentlichten Liste einen Anthropic-Crawler anzeigt. Quelle

Lauren Busby, Mitgründerin von Trebletree — Search Engine Land

• “Log files are the closest thing to that missing layer. They don’t summarize or interpret activity. They record it — every request, every URL, every crawler.” (Übersetzung) „Logdateien kommen dieser fehlenden Schicht am nächsten. Sie fassen Aktivität nicht zusammen und interpretieren sie nicht. Sie zeichnen sie auf — jede Anfrage, jede URL, jeden Crawler.“
• “Tools like Screaming Frog Log File Analyzer make it possible to process that data quickly.” (Übersetzung) „Tools wie Screaming Frog Log File Analyzer ermöglichen eine schnelle Verarbeitung dieser Daten.“
• Zur Tiefe von KI-Crawlern: “It’s common to see them limited to top-level pages – the homepage, primary navigation, and a small number of high-level URLs.” (Übersetzung) „Oft sind sie auf Seiten der obersten Ebene beschränkt — Startseite, Hauptnavigation und wenige übergeordnete URLs.“
• Zu den sichtbaren Problemen: “Log files also surface where crawlers encounter issues. This includes: 403 responses (blocked requests). 429 responses (rate limiting).” (Übersetzung) „Logdateien zeigen außerdem, wo Crawler auf Probleme stoßen. Dazu gehören: 403-Antworten (blockierte Anfragen) und 429-Antworten (Ratenbegrenzung).“
• Zur Aufbewahrung: “A scheduled SFTP job – whether built in a workflow tool like n8n, or scripted – is enough to turn a short retention window into something you can actually analyze over time.” (Übersetzung) „Ein geplanter SFTP-Job — ob in einem Workflow-Tool wie n8n erstellt oder skriptiert — reicht aus, um ein kurzes Aufbewahrungsfenster über die Zeit analysierbar zu machen.“
• Die ehrliche Grenze: “Log files show you what reached your site. They don’t always show you what tried to.” (Übersetzung) „Logdateien zeigen, was Ihre Website erreicht hat. Sie zeigen nicht immer, was es versucht hat.“ Quelle

Duane Forrester — Search Engine Journal

• “Of 33 requests carrying one of those live-fetch names. Six came from an IP the vendor publishes. Twenty-seven did not. That is an 81.8% spoof rate among the requests I could check.” (Übersetzung) „Von 33 Anfragen mit einem dieser Live-Fetch-Namen kamen sechs von einer vom Anbieter veröffentlichten IP. 27 kamen nicht von dort. Das ist eine Spoofing-Rate von 81,8 % unter den prüfbaren Anfragen.“
• “The real check is not complicated. The major operators publish the actual IP addresses their bots use, as plain files you can open right now, and a request is legitimate only if the name matches and the address sits inside the published list.” (Übersetzung) „Die eigentliche Prüfung ist nicht kompliziert. Die großen Betreiber veröffentlichen die tatsächlichen IP-Adressen ihrer Bots als einfache Dateien, die Sie sofort öffnen können; eine Anfrage ist nur dann legitim, wenn der Name stimmt und die Adresse in der veröffentlichten Liste liegt.“
• Zu Googlebot: “Of 799 requests carrying the Googlebot name, only 107 came from a verified Google address. The other 692, roughly 87%, were not Google.” (Übersetzung) „Von 799 Anfragen mit dem Namen Googlebot kamen nur 107 von einer verifizierten Google-Adresse. Die übrigen 692, ungefähr 87 %, stammten nicht von Google.“
• Sein Aufruf: “Do not take my numbers; take the method… Pull a date range, match the names, verify the IPs against the published lists, and find your real fraction.” (Übersetzung) „Übernehmen Sie nicht meine Zahlen, sondern die Methode … Wählen Sie einen Zeitraum, gleichen Sie die Namen ab, verifizieren Sie die IPs gegen die veröffentlichten Listen und ermitteln Sie Ihren eigenen Anteil.“ Quelle

Clint Spaulding, Senior Manager Technical SEO, Seer Interactive

• “Once blocked, stealth crawlers can reappear under generic browser headers and unrelated IPs.” (Übersetzung) „Nach einer Blockierung können Stealth-Crawler unter generischen Browser-Headern und mit anderen IPs wieder auftauchen.“
• “These sessions look human in logs. That means session counts get inflated, bot traffic gets undercounted, and GEO segmentation becomes less trustworthy.” (Übersetzung) „Diese Sitzungen sehen in Logs menschlich aus. Dadurch werden Sitzungszahlen aufgebläht, Bot-Traffic unterschätzt und GEO-Segmente weniger zuverlässig.“
• “If you can’t see these stealth crawlers, you can’t measure their impact.” (Übersetzung) „Wenn Sie diese Stealth-Crawler nicht sehen, können Sie ihre Auswirkungen nicht messen.“ Quelle

Screaming Frog — Tutorial zum Log File Analyser (Produktdokumentation)

• Zur Verifizierung beim Import: “Search engine bots are often spoofed, and this performs a lookup against publicly confirmed IP lists to confirm they are genuine.” (Übersetzung) „Suchmaschinen-Bots werden häufig gefälscht; dieses Verfahren prüft öffentliche bestätigte IP-Listen, um zu bestätigen, dass sie echt sind.“
• “If you see high request volumes from IPs that don’t verify, you’re likely dealing with fake bot traffic that should be blocked at server level.” (Übersetzung) „Wenn Sie hohe Anfragevolumen von IPs sehen, die sich nicht verifizieren lassen, handelt es sich wahrscheinlich um gefälschten Bot-Traffic, der auf Serverebene blockiert werden sollte.“ Quelle

Bing Webmaster Tools — AI-Performance-Bericht (öffentliche Vorschau, Februar 2026)

• Grounding Queries: “Shows the key phrases the AI used when retrieving content that was referenced in AI-generated answers.” (Übersetzung) „Zeigt die Schlüsselphrasen, welche die KI beim Abruf von Inhalten verwendet hat, die in KI-generierten Antworten referenziert wurden.“
• Total Citations: “Shows the total number of citations that are displayed as sources in AI-generated answers during the selected time frame.” (Übersetzung) „Zeigt die Gesamtzahl der Zitationen, die im ausgewählten Zeitraum als Quellen in KI-generierten Antworten angezeigt werden.“ Quelle

„Ist diese KI-Bot-Anfrage echt, und was mache ich damit?“

Gehen Sie damit eine einzelne verdächtige Logzeile — oder den gesamten Traffic eines Bots — durch. Es ist die Verifizierungslogik aus Schritt 2 als Ablauf.

Checkliste für die KI-Crawler-Loganalyse

Ein wiederholbarer Durchlauf, vom Abruf der Logs bis zu ihrer Auswertung:

• Logs werden mit den benötigten Feldern erfasst: Zeitstempel, Client-IP, User-Agent, Request-Pfad und Statuscode (Bytes und Referrer helfen).
• Sie ziehen aus der richtigen Schicht — CDN-/Edge-Logs hinter Cloudflare/Fastly (viel Bot-Traffic erreicht den Origin nie).
• Ein geplanter Abruf (SFTP/n8n/Skript) überbrückt das Aufbewahrungsfenster, damit Sie Historie statt nur der letzten Tage haben.
• Jede KI-Bot-Anfrage ist verifiziert: User-Agent abgeglichen und Quell-IP gegen die veröffentlichte Liste des Betreibers geprüft (Reverse-DNS als Fallback).
• Gefälschte oder unverifizierte Anfragen werden aus den KI-Crawl-Metriken ausgeschlossen und nicht als der genannte Bot gezählt.
• Crawlhäufigkeit ist pro Bot als Baseline erfasst (Schübe gegenüber gleichmäßigen Mustern beobachten).
• Die meistabgerufenen Seiten sind identifiziert — und wichtige tiefe Seiten werden nachweislich überhaupt gecrawlt.
• Crawl-vs.-Render ist geprüft: Ziehen KI-Bots auf Seiten mit JS-Rendering nur HTML? (Als Test der Roh-HTML-Abhängigkeit erfassen; das Verhalten ist agentenspezifisch und möglicherweise nicht dokumentiert.)
• Statuscodes sind geprüft: 200/304 gesund; 404 fehlerhafte Links; 403/429 als beabsichtigt bestätigt oder behoben.
• Das Vorhandensein von robots.txt-Anfragen ist geprüft (rufen Bots sie vor dem Crawling ab?) und es gibt keine überraschenden Treffer auf gesperrten Pfaden.
• Vor jeder Aussage „Funktioniert es?“ mit Zitationsdaten (Bing Grounding Queries / GSC-KI-Funktionen) verbunden.
• Eine erneute Verifizierung ist geplant — dies ist kein einmaliges Audit (Stealth-Crawler tauchen wieder auf und sehen menschlich aus).

Spickzettel für die KI-Crawler-Loganalyse

Verifizierungsdateien (als Lesezeichen speichern)

Statuscodes, die Sie beobachten sollten

Verifizieren, nicht vertrauen

• User-Agent allein = unverifiziert. UA abgleichen und, sofern verfügbar, veröffentlichte Verifizierungsdaten des Betreibers nutzen; andernfalls die Unsicherheit bewahren.
• In der Praxis beobachtete Spoofing-Raten: 5,7 % (HUMAN, 16 Bots) → 81,8 % (Forresters Live-Fetch-Logs); 87 % gefälschte Googlebots im selben Audit.

Hinweis auf Roh-HTML-Abhängigkeit

• Wenn ein Bot nur HTML und null .js-, .css- oder Bildanfragen abruft, ist das ein beobachtetes Fetch-Muster. Auf einer JS-abhängigen Seite ist es ein Risikosignal, kein Beweis für eine universelle Fähigkeit. @@BT@@.js@@BT@@ @@BT@@.css@@BT@@

Schnelle Fakten

• Crawlhäufigkeit ≠ Zitationswahrscheinlichkeit. Abruf ist notwendig, aber nicht ausreichend.
• Verwenden Sie dokumentierte robots-Tokens für die Crawling-Richtlinie; halten Sie Netzwerkblockierungen als separate Maßnahme gegen Missbrauch oder Sicherheitsprobleme.

Skripte für die KI-Crawler-Loganalyse

Der Artikel AI crawlers enthält das grundlegende Snippet „Bot-Treffer zählen“. Die folgenden Beispiele gehen weiter: Extraktion, Verifizierung, Statuscode-Aufschlüsselung und Erkennung von Crawl-vs.-Render.

1. Jede KI-Bot-Zeile extrahieren (grep + Regex)

macOS / Linux — eine Alternative über die gängigen KI-User-Agents:

# Pull all AI-bot requests from a combined-format access log
grep -Ei 'GPTBot|OAI-SearchBot|ChatGPT-User|ClaudeBot|Claude-User|Claude-SearchBot|PerplexityBot|Perplexity-User|Applebot|Amazonbot|Bytespider|CCBot|Meta-ExternalAgent' \
  access.log > ai-bots.log

# Count requests per bot (which token, how many hits)
grep -Eoi 'GPTBot|OAI-SearchBot|ChatGPT-User|ClaudeBot|Claude-User|PerplexityBot|Perplexity-User|CCBot|Bytespider' \
  access.log | sort | uniq -c | sort -rn

Für Windows PowerShell:

Select-String -Path .\access.log -Pattern 'GPTBot|OAI-SearchBot|ChatGPT-User|ClaudeBot|PerplexityBot|CCBot|Bytespider' |
  ForEach-Object { ($_ -match '(GPTBot|OAI-SearchBot|ChatGPT-User|ClaudeBot|PerplexityBot|CCBot|Bytespider)') | Out-Null; $Matches[1] } |
  Group-Object | Sort-Object Count -Descending | Select-Object Count, Name

2. Eine behauptete GPTBot-IP gegen die veröffentlichte OpenAI-Liste prüfen

Der User-Agent allein beweist nichts — prüfen Sie die IP. Dieses Beispiel lädt OpenAIs Liste und testet, ob eine IP aus Ihren Logs in einen veröffentlichten CIDR-Bereich fällt:

# Requires jq and (for CIDR math) grepcidr — brew/apt install both
IP="203.0.113.45"   # the IP from your log line
curl -s https://openai.com/gptbot.json \
  | jq -r '.prefixes[].ipv4Prefix // .prefixes[].ipv6Prefix' \
  | while read -r cidr; do
      echo "$IP" | grepcidr "$cidr" >/dev/null 2>&1 && echo "VERIFIED in $cidr"
    done
# No output = the IP is NOT in OpenAI's published range → treat as spoofed.

Für Anthropic laden Sie die aktuelle Liste https://claude.com/crawling/bots.json und passen Sie den jq-Pfad an deren dokumentierte Struktur an. Wenn ein anderer Betreiber keinen aktuellen Verifizierungsfeed veröffentlicht, behalten Sie das Ergebnis als behaupteten User-Agent bei.

3. Reverse- und Forward-DNS-Fallback (IPs außerhalb der Liste)

Verwenden Sie dies nur, wenn der genannte Anbieter ein erwartetes Hostnamensuffix und das Verfahren für Reverse-plus-Forward-Verifizierung veröffentlicht. Es ist kein allgemeiner Beweis der Bot-Identität:

IP="203.0.113.45"
HOST=$(host "$IP" | awk '/pointer/ {print $NF}' | sed 's/\.$//')
echo "PTR: $HOST"
host "$HOST" | grep -q "$IP" && echo "FORWARD-CONFIRMED" || echo "MISMATCH → suspect"

4. Statuscode-Aufschlüsselung pro Bot

Finden Sie 403-/429-Blockierungen und Fehler bei nicht gefundenen Seiten, denen die Bots begegnen:

# For GPTBot: tally status codes (combined log format; $9 is the status)
grep -i 'GPTBot' access.log | awk '{print $9}' | sort | uniq -c | sort -rn
# → e.g. "812 200 / 47 404 / 15 403" — the 403s are worth investigating

5. Signal für Roh-HTML-Abhängigkeit — welche Dateitypen ruft der Bot ab?

Wenn ein behaupteter Bot ausschließlich .html// lädt und niemals .js, .css oder Bilder abruft und Ihre Inhalte per JS gerendert werden, ist das ein zu untersuchendes Abhängigkeitssignal:

# What extensions is ChatGPT-User actually requesting?
grep -i 'ChatGPT-User' access.log \
  | awk '{print $7}' \
  | grep -oE '\.(html?|js|css|png|jpe?g|webp|svg|woff2?)(\?|$)' \
  | sort | uniq -c | sort -rn
# All HTML, zero subresources = compare the raw body with provider-specific outcomes.

6. Chrome-DevTools-Console — KI-Abrufende auf einer Live-Seite erkennen

Keine Logabfrage, aber eine schnelle Prüfung dessen, was eine Seite im Roh-HTML gegenüber nach JavaScript ausliefert (was ein KI-Bot sehen würde und was nicht). In die Console einfügen:

// Compare rendered text length to what's in the initial HTML source.
// A big gap means most content depends on JS; provider behavior must be verified separately.
(async () => {
  const raw = await (await fetch(location.href, { cache: "no-store" })).text();
  const rawText = new DOMParser().parseFromString(raw, "text/html").body.innerText.trim().length;
  const renderedText = document.body.innerText.trim().length;
  console.log({ rawText, renderedText, jsDependentRatio: +(1 - rawText / renderedText).toFixed(2) });
})();
// jsDependentRatio near 1 = almost all content is JS-injected; flag dependency, not invisibility.

7. Bookmarklet — die IP-Liste jedes Bots auf einmal öffnen

Ziehen Sie dies als Lesezeichen ab, um die Verifizierungsdateien für eine schnelle Prüfung in Tabs zu öffnen:

javascript:(function(){["https://openai.com/gptbot.json","https://openai.com/searchbot.json","https://openai.com/chatgpt-user.json","https://claude.com/crawling/bots.json"].forEach(u=>window.open(u,"_blank"));})();

SOP: monatliche Prüfung von KI-Crawler-Logs

Ein wiederkehrendes Verfahren, das regelmäßig ausgeführt wird (für die meisten Websites monatlich, wöchentlich, wenn KI-Traffic für Sie wesentlich ist). Es erzeugt jedes Mal eine vergleichbare Baseline.

Vorbereitung

1. Ziehen Sie das Logfenster seit der letzten Prüfung aus der richtigen Schicht (CDN-/Edge-Logs hinter einem CDN, sonst Origin-Logs). Bestätigen Sie, dass der geplante SFTP-/n8n-Abruf tatsächlich gelaufen ist — Lücken zerstören Trendlinien unbemerkt.
2. Laden Sie es in Ihr führendes Tool (Screaming Frog LFA für regelmäßige Importe, BigQuery/ELK für eine Pipeline).

Verifizieren (niemals überspringen) 3. Aktualisieren Sie jede aktuelle, vom Anbieter veröffentlichte Verifizierungsquelle (gptbot.json, searchbot.json, chatgpt-user.json, adsbot.json und Anthropics claude.com/crawling/bots.json) — diese ändern sich. 4. Aktivieren Sie die Verifizierung beim Import (Screaming Frog) oder führen Sie den IP-in-CIDR-Check (Tab Scripts) gegen jede KI-Bot-Anfrage aus. 5. Teilen Sie den Traffic in verifiziert und unverifiziert. Berichten Sie den unverifizierten Anteil — das ist Ihre Spoofing-Rate für diesen Zeitraum. Ein Sprung ist selbst eine Erkenntnis.

Messen (nur verifizierter Traffic) 6. Crawlhäufigkeit pro Bot gegenüber dem letzten Zeitraum — neue, verschwundene Bots und Schübe notieren. 7. Meistabgerufene Seiten; bestätigen, dass Prioritäts- und tiefe Seiten überhaupt gecrawlt werden. 8. Stichprobe der Roh-HTML-Abhängigkeit an 2–3 JS-lastigen Templates (rufen Bots nur HTML ab?). 9. Statuscode-Aufschlüsselung pro Bot; neue Cluster von 403/429/404 untersuchen. 10. Vorhandensein von robots.txt-/llms.txt-Anfragen und alle Treffer auf gesperrten Pfaden.

Berichten und handeln 11. Protokollieren Sie die Zahlen des Zeitraums in einer fortlaufenden Tabelle (verifizierte Treffer je Bot, Spoofing-%, Top-Seiten und Fehlercluster), damit Sie Trends statt Momentaufnahmen haben. 12. Verbinden Sie die Daten mit Zitationsdaten (Bing Grounding Queries / GSC-KI-Funktionen), bevor Sie etwas über Sichtbarkeit schlussfolgern. 13. Erfassen Sie konkrete Korrekturen: beabsichtigte gegenüber versehentlichen Blockierungen, JS-Rendering-Lücken, fehlerhafte Links und präzise User-Agent-Regeln für bestätigte Imitatoren.

Hinweis zur Frequenz: Führen Sie die Verifizierung in jedem Zeitraum erneut aus — speichern Sie keine „bekannte gute“ IP-Liste zwischen. Stealth-Crawler tauchen unter neuen IPs und generischen Browser-UAs wieder auf.

Playbook: „GPTBot (oder ClaudeBot) erhält 403er/429er und ich weiß nicht, ob das Absicht ist“

Ein lineares Runbook für den häufigen Incident — ein verifizierter KI-Bot erhält in Ihren Logs Fehler. Arbeiten Sie es in dieser Reihenfolge ab.

Schritt 1 — Zuerst bestätigen, dass es der echte Bot ist. Verwenden Sie vor allem anderen die aktuelle offizielle Verifizierungsmethode des benannten Anbieters. Gibt es keine, bleibt die Identität unverifiziert; stufen Sie diese nicht stillschweigend als echt oder gefälscht ein. Der 403 kann trotzdem bedeuten, dass Ihre WAF korrekt arbeitet.

Schritt 2 — Die genaue Antwort und ihre Herkunft ermitteln. Ziehen Sie die Statuscode-Aufschlüsselung für diesen Bot (Tab Scripts). Ist es 403 (blockiert), 429 (rate-limitiert) oder 503? Notieren Sie, ob die Blockierung an Ihrem CDN/WAF, in der Serverkonfiguration oder in robots.txt-nahen Regeln liegt.

Schritt 3 — Entscheiden: Ist die Blockierung beabsichtigt?

• Sie wollten diesen Bot blockieren (z. B. einen Trainingscrawler, von dem Sie sich abgemeldet haben) → der 403 funktioniert wie vorgesehen. Halten Sie die dokumentierte robots-Richtlinie getrennt von jeder Netzwerkregel gegen Missbrauch oder Sicherheitsprobleme. Fertig.
• Sie wollten ihn NICHT blockieren (z. B. OAI-SearchBot oder PerplexityBot, wenn Sie Sichtbarkeit in der KI-Suche möchten) → weiter.

Schritt 4 — Die versehentliche Regel finden. Häufige Ursachen: eine zu weit gefasste WAF-„Bot“-Regel, ein für einen schubweisen Crawler zu niedriger Rate-Limit-Schwellenwert (denken Sie an WISLRs GPTBot-Spitze mit 114 Anfragen pro Minute — ein Limit pro Minute kann legitime Schübe auslösen), ein vergessener robots.txt-Disallow oder eine Geo-/ASN-Blockierung, welche die Bereiche des Betreibers trifft. @@BT@@robots.txt@@BT@@

Schritt 5 — Präzise beheben. Setzen Sie den verifizierten Bot anhand von User-Agent und veröffentlichter IP-Range auf die Whitelist oder erhöhen Sie das Rate-Limit gezielt für diesen verifizierten Bot. Lockern Sie den Schutz nicht für alle.

Schritt 6 — Die Korrektur in den Logs verifizieren. Ziehen Sie nach dem Deployment die Logs für diesen Bot erneut. Der Cluster aus 403/429 sollte sich auf den für Sie wichtigen Seiten in 200/304 verwandeln.

Schritt 7 — Neue Baseline erstellen und beobachten. Notieren Sie die Änderung in Ihrer laufenden Tabelle. Prüfen Sie im nächsten Zeitraum erneut — und achten Sie darauf, ob der Bot unter einem anderen UA wieder auftaucht, falls Sie ihn tatsächlich blockieren wollten (Stealth-Crawling).

Fehler der Loganalyse, die zu falschen Schlussfolgerungen führen

Jeder Fehler ist eine verbreitete Annahme, der Grund, warum sie falsch ist, und die bessere Alternative.

Mythos: „Wenn meine robots.txt einen Bot blockiert, taucht er nicht in meinen Logs auf / ist das kein Problem.“ Warum falsch: robots.txt ist eine Anfrage, keine Durchsetzung. Fetcher, die durch Nutzer ausgelöst werden, nehmen sich ausdrücklich aus, und von einigen Crawlern wurde berichtet, dass sie Blockierungen umgehen (Perplexity Stealth-Crawling, Cloudflare August 2025). Die Blockierung kann vollständig ignoriert werden. Stattdessen: Verwenden Sie die Logs, um zu prüfen, ob die Regel eingehalten wird — suchen Sie nach Treffern auf gesperrten Pfaden und danach, ob der Bot /robots.txt überhaupt anfragt.

Mythos: „Ein GPTBot-/ClaudeBot-User-Agent in meinen Logs bedeutet, dass er wirklich OpenAI/Anthropic ist.“ Warum falsch: User-Agents lassen sich trivial fälschen — HUMAN Security maß 5,7 % Fälschungen über 16 Bots, und Duane Forrester fand 81,8 % Fälschungen unter seinen eigenen Live-Fetch-Anfragen. Stattdessen: User-Agent abgleichen und, sofern vorhanden, die aktuelle offizielle Verifizierungsmethode des Betreibers nutzen; andernfalls die Identität als unverifiziert kennzeichnen.

Mythos: „Mehr KI-Crawler-Treffer = höhere Wahrscheinlichkeit, zitiert zu werden.“ Warum falsch: Keine etablierte kausale oder korrelative Datenlage stützt das. Abruf ist notwendig, aber nicht ausreichend — stark gecrawlte Seiten werden ständig nicht zitiert. Stattdessen: Behandeln Sie Logs nur als Sichtbarkeit der abgerufen-Stufe und verbinden Sie diese mit Zitationsdaten (Bing Grounding Queries, GSC-KI-Funktionen).

Mythos: „Jeder KI-Crawler rendert gleich.“ Warum falsch: Anbieter veröffentlichen keinen gemeinsamen Vertrag für JavaScript und Subressourcen, und das beobachtete Verhalten unterscheidet sich je nach Agent und Stichprobe. Stattdessen: Vergleichen Sie die Rohantwort mit der gerenderten Seite, untersuchen Sie Subresource-Anfragen des benannten Bots und kennzeichnen Sie das Ergebnis als beobachtet, nicht als universell.

Mythos: „KI-Bots prüfen wenigstens meine llms.txt.“ Warum falsch: WISLRs 48-tägige Stichprobe verzeichnete von keinem KI-Bot eine einzige Anfrage an /llms.txt — passend zum Befund im Artikel AI crawlers, dass ungefähr 97 % sie nicht lesen. Stattdessen: Behandeln Sie llms.txt-Anfragen nicht als erwartete Validierung, sondern messen Sie, was Bots tatsächlich abrufen.

Mythos: „Netzwerkblockierung und robots-Richtlinie sind dieselbe Kontrolle.“ Warum falsch: robots kommuniziert Crawling-Präferenzen; eine Firewall erzwingt Netzwerkzugriff und kann unabhängigen Traffic beeinflussen. Stattdessen: Verwenden Sie die dokumentierte User-Agent-Regel für Richtlinien und reservieren Sie Netzwerkblockierung für separat begründete Reaktionen auf Missbrauch oder Sicherheitsprobleme.

Reale Fälle

Duane Forrester — selbst getestete Spoofing-Raten in den eigenen Logs. Forrester führte diese Methode auf seiner Website aus und veröffentlichte die Zahlen. Von 33 Live-Fetch-Anfragen kamen nur 6 von einer vom Anbieter veröffentlichten IP — eine Spoofing-Rate von 81,8 %; unter 799 Googlebot-benannten Anfragen waren nur 107 verifiziert — ungefähr 87 % waren gefälscht (SEJ). Vorher: Der Traffic seines „KI-Assistenten“ wirkte real, weil er dem User-Agent vertraute. Nachher: Beim Abgleich der Namen mit veröffentlichten IP-Listen erwies sich der größte Teil als Imitation. Schlussfolgerung: Die Methode ist wichtiger als seine konkreten Zahlen — wie er sagt: Ziehen Sie Ihren eigenen Zeitraum heran und ermitteln Sie Ihren echten Anteil.

WISLR — 48 Tage CDN-Logs, das Crawl-vs.-Render-Muster. Tony Castillo analysierte über 48 Tage 288 566 CDN-Logzeilen (12 099 KI-/Bot-Anfragen) (WISLR). Konkrete Ergebnisse: GPTBot war wochenlang abwesend und erzeugte dann in drei Minuten 152 Anfragen (Spitze 114 Anfragen/Minute); ChatGPT-User lud null Bilder, CSS oder JS — reine HTML-Extraktion; und über das gesamte Zeitfenster gab es null Anfragen an /llms.txt. Vorher: Man hätte gleichmäßiges Crawling und JS-fähige Bots angenommen. Nachher: Die Logs zeigen schubweises Verhalten und reines HTML — n=1, die Daten einer Website, aber ein anschauliches Bild dessen, was eine echte Analyse sichtbar macht. Schlussfolgerung: Das Muster des Abrufs ohne JS ist der direkte Beleg für die Crawl-vs.-Render-Prüfung.

Cloudflare — das Crawl-to-Referral-Verhältnis im Netzwerkmaßstab. Cloudflares aggregierte Daten zeigen, wie wenig Crawling in Traffic umschlägt: Für jeden Besucher, den Anthropic an eine Website zurückverweist, haben seine Crawler bereits Zehntausende Seiten besucht (Cloudflare). Vorher: Die Intuition lautete, starkes Crawling bedeute Engagement. Nachher: Im Netzwerkmaßstab ist das Verhältnis unausgewogen — Training treibt inzwischen den größten Teil der KI-Bot-Aktivität, und Trainings-Bots sollen überhaupt keinen Traffic zurücksenden (Cloudflare). Schlussfolgerung: Eine stark gecrawlte Seite ohne Referral ist normal und kein Erfolgssignal — genau deshalb sagt Crawlhäufigkeit nichts über Zitation voraus.

Sofort einsetzbare KI-Prompts

Prompts zum Kopieren und Einfügen, um die Analyse von KI-Crawler-Logs mit einem LLM zu beschleunigen. Prüfen Sie die Ausgabe immer anhand der Rohlogs — LLMs halluzinieren, und eine Verifizierungspipeline, die einer halluzinierten IP-Zuordnung vertraut, ist schlimmer als gar keine.

Einen verifizierungsbewussten Logparser entwerfen

Write a Python script that parses combined-format Nginx access logs and, for each
request whose user-agent matches a known AI bot (GPTBot, OAI-SearchBot,
ChatGPT-User, ClaudeBot, Claude-User, PerplexityBot, Perplexity-User, CCBot,
Bytespider), does the following:

1. Extract timestamp, client IP, request path, status code, user-agent.
2. Fetch and cache OpenAI's current IP lists (gptbot.json, searchbot.json,
   chatgpt-user.json, adsbot.json) and Anthropic's current bots.json list.
3. Mark an OpenAI or Anthropic request VERIFIED only if the user-agent matches AND
   the client IP falls inside the matching provider-published ranges; mark providers
   without an official method UNVERIFIED, not spoofed.
4. Output two CSVs: verified requests and unverified ("spoofed") requests.
5. Print a summary: verified vs. unverified count per bot, and the top 20 fetched
   paths (verified only).

Do NOT count unverified requests in any per-bot metric. Add clear comments.

Einen Statuscode- und Crawl-vs.-Render-Bericht zusammenfassen

I'll paste a table of AI-bot log data (columns: bot, path, status_code,
file_extension). Produce:
- A per-bot status-code breakdown, flagging any 403/429/404 clusters.
- A raw-HTML dependency read: for each bot, the ratio of HTML requests to
  JS/CSS/image requests, and a note on whether the bot appears to fetch only HTML
  in this sample. Treat HTML-only on a JS-rendered page as a dependency risk, not
  proof of a universal no-JavaScript capability.
Keep every conclusion tied to a number from the data — do not infer beyond it.

DATA:
[paste]

Eine verdächtige IP triagieren

A request in my logs claims to be [BOT NAME] from IP [IP ADDRESS]. Walk me through
verifying it: which operator IP-list file to check, how to test whether the IP is
in range, and the reverse+forward DNS fallback if it's not on a published list.
Tell me explicitly what result means "verified" vs. "treat as spoofed." Do not
guess whether this specific IP is legitimate — give me the steps to check.

Tools für die KI-Crawler-Loganalyse

Grob von kostenlos/Rohdaten zu kostenpflichtig/Managed Service:

• grep / PowerShell — der schnellste Weg zu einer Bot-Trefferzahl und einem verifizierungsbewussten Filter über einem Rohzugriffslog. Keine Einrichtung nötig; siehe Tab Skripte.
• Screaming Frog Log File Analyser — Desktop-Importer mit integrierten KI-Bot-Voreinstellungen und einem Schalter „Bots beim Import verifizieren“, der gegen öffentlich bestätigte IP-Listen prüft. Tabs Response Codes, User Agents, URLs (nach Num Events sortieren) und IPs. Am besten für regelmäßige Importe.
• ELK Stack (Elasticsearch / Logstash / Kibana) oder Splunk — kontinuierliche Aufnahme, Dashboards und Alarmierung, sobald ein Desktop-Import zu langsam wird oder laufendes Monitoring nötig ist.
• BigQuery — langfristige Aufbewahrung und SQL im großen Maßstab, häufig gespeist über Cloudflare Logpush oder einen geplanten GraphQL-Abruf aus httpRequestsAdaptiveGroups.
• Cloudflare AI Crawl Control — für Websites hinter Cloudflare: Ansichten zu Crawleraktivität, Bot-Verifizierung und Richtlinienkonformität ohne eigene Pipeline.
• Google Search Console — Crawl Stats — nicht für KI-Bots (nur Googlebot), aber das Vorbild für die Aufschlüsselung nach Crawler und Antwortcode, die Sie für KI-Bots aus Rohlogs nachbauen.
• Bing Webmaster Tools — AI Performance — das Gegenstück auf der Zitationsseite: Grounding Queries und Zitationszahlen mit Ihren Crawl-Eingangslogs verbinden, um den Kreislauf zu schließen.

Behauptete KI-Bot-Traffic-Spitzen über Nacht

Symptom: Anfragen mit dem User-Agent eines bekannten Crawlers springen plötzlich. Wahrscheinliche Ursache: Spoofing, Monitoring-Traffic oder eine echte Crawl-Änderung. Lösung: Quell-IPs anhand der aktuellen veröffentlichten Methode des Betreibers verifizieren, bevor Sie den Traffic zuordnen, und anschließend nach ASN, Pfad, Status und Zeit segmentieren.

Logs zeigen Crawling, aber der Inhalt wird nie zitiert

Symptom: Verifizierte Bots rufen Seiten ab, ohne dass sichtbare Zitationsgewinne entstehen. Wahrscheinliche Ursache: Crawling ist nur ein Beleg für Eignung; Abruf und Auswahl für eine Antwort sind getrennt. Lösung: Bestätigen Sie, dass der Bot substanzielles HTML erhalten hat, und prüfen Sie dann Indexierbarkeit, Passagenqualität, Anfragepassung und externe Bestätigung, ohne die Crawlzahl als Ranking zu behandeln.

Jede Anfrage scheint 200 zurückzugeben

Symptom: Fehlende URLs und blockierte Inhalte werden als Erfolg aufgezeichnet. Wahrscheinliche Ursache: Eine App-Shell, CDN-Regel oder benutzerdefinierte Fehlerseite liefert einen Soft-404. Lösung: Stichproben der Antwortkörper und finalen Header nehmen und anschließend die Statusbehandlung reparieren, statt allein dem Statuscode zu vertrauen.

Verifizierte Bots erhalten eine leere Shell

Symptom: Ein Browser rendert Inhalte, aber Fetches, die anhand der Logs zugeordnet wurden, erhalten kaum brauchbares HTML. Wahrscheinliche Ursache: Die Seite hängt von clientseitigem JavaScript ab, das der Crawler nicht ausführt. Lösung: Roh- und gerenderte Ausgabe vergleichen und kritische Inhalte und Links per SSR, statischem Rendering oder einer anderen zuverlässigen Auslieferungsstrategie im HTML bereitstellen.

Kennzahlen für KI-Crawler-Logs

Ressourcen, die Ihre Zeit wert sind

Meine verwandten Texte

• So führen Sie eine SEO-Logdateianalyse durch (Ahrefs, geprüft von Patrick Stox und Michal Pecánek) — die Vorlage aus der Zeit vor KI, deren KI-spezifische Fortsetzung dieser Artikel ist: Messgrößen, Tools und Bot-Verifizierung.
• Was ist Logdateianalyse? (Ahrefs-Glossar) — die definitorische Ergänzung.
• Die neuen Webcrawler: KI-Bots holen Suchmaschinen-Bots ein — meine Cloudflare-Radar-Analyse des KI-Bot-Crawlanteils.
• Die KI-Bots, die ~140 Millionen Websites am häufigsten blockieren — robots.txt-Blockierungsdaten aus dem offenen Web.
• 80% unseres KI-Suchtraffics fließt auf unsere Startseite, Produktseiten und kostenlosen Tools — Analyse der KI-Aktivität nach Seitentyp, das Gegenstück zur Frage „Welche Seiten werden gecrawlt?“.

Meine Vorträge

• How Search Works (SlideShare) — mein Überblick über Crawling, Rendering, Indexierung und Ranking, hilfreich für die Auswertung dessen, was Bots in Ihren Logs tun. (Der übliche Hinweis gilt: Das ist mein Verständnis der Systeme, keine Garantie auf 100-prozentige Vollständigkeit oder Richtigkeit.)

Aus der Branche

• Warum Logdateianalyse für KI-Crawler und Suchsichtbarkeit wichtig ist — Lauren Busby (Trebletree), Search Engine Land: „Logs sind die fehlende Schicht“, Aufbewahrungsfenster sowie 403/429-Einordnung.
• 81,8 % meines „KI-Assistenten“-Traffics war gefälscht. Die Googlebot-Zahl war noch schlimmer — Duane Forrester, Search Engine Journal: die herausragende Fallstudie und Methode zur Verifizierung aus erster Hand.
• Perplexity, heimliches KI-Crawling und die Auswirkungen auf GEO und Logdateianalyse — Clint Spaulding, Seer Interactive: warum blockierte Bots mit menschenähnlichem Erscheinungsbild wieder auftauchen.
• KI-Bots im Log File Analyser überwachen — Screaming Frog: praktische Tool-Anleitung mit Verifizierung beim Import.
• Die Lücke zwischen Crawling und Klicks: Cloudflare-Daten zu KI-Bots, Training und Verweisen — Cloudflare: netzwerkweite Crawl-to-Referral-Verhältnisse und die Trennung von Training und Suche.
• Crawlt Anthropic Daten aus dem Web? — Anthropics aktuelle Dokumentation zu Botzweck und robots-Steuerung.
• OpenAI-Bot-/Crawler-Dokumentation — User-Agent-Zeichenfolgen und veröffentlichte IP-Dateien zur Verifizierung.

Zitierwürdige Statistiken

• Spoofing-Rate — 5,7 % über 16 KI-Crawler. Die zweiwöchige Analyse von HUMAN Security zu Traffic, der behauptete, von einem von 16 bekannten KI-Crawlern zu stammen, ergab, dass etwa jede 18. Anfrage gefälscht war (vom Anbieter stammend und über SEJ weitergegeben).
• Spoofing-Rate — 81,8 % in den Logs eines Praktikers. Duane Forresters eigener Audit ergab, dass 27 von 33 Live-Fetch-Anfragen von IPs kamen, welche die Anbieter nicht veröffentlichen; seine Googlebot-Zahl war zu etwa 87 % gefälscht (SEJ).
• Crawl-to-Referral, ClaudeBot gegenüber OpenAI. Cloudflares Daten für die Woche vom 25. Mai bis 1. Juni 2026 ergaben etwa 11 122 gecrawlte Seiten pro Referral bei ClaudeBot und 857:1 bei OpenAI gegenüber ungefähr 5:1 bei Googlebot (Cloudflare).
• Training treibt den größten Teil der KI-Bot-Aktivität. Laut Cloudflare treibt Training inzwischen fast 80 % der KI-Bot-Aktivität, gegenüber 72 % ein Jahr zuvor — ein Kontext dafür, warum starkes Crawling ohne Referral normal ist (Cloudflare).
• Ein echtes Logfenster: 288 566 Zeilen, 12 099 Bot-Anfragen, 48 Tage. WISLRs Fallstudie — mit GPTBots Schub von 152 Anfragen in 3 Minuten und ChatGPT-Users null Bild-/CSS-/JS-Fetches (WISLR).

Testen Sie sich selbst: KI-Crawler-Loganalyse

Fünf kurze Fragen zum Abrufen und Lesen von KI-Bot-Logs. Wählen Sie jeweils eine Antwort und prüfen Sie anschließend.

Änderungsprotokoll