Serverprotokolle sind die einzige ehrliche Aufzeichnung von KI-Crawlern: ein Audit-Playbook mit Querverweisen
Hier ist die unangenehme Wahrheit, die Ihnen die meisten “KI-Sichtbarkeits”-Dashboards nicht sagen: Das Analyseprodukt Ihres Vertrauens kann die Crawler, die Sie zu messen versuchen, nicht sehen.

Google Analytics 4 feuert bei der Ausführung von JavaScript. AI-Crawler führen fast ausnahmslos kein JavaScript aus. Sie fordern das rohe HTML an, nehmen sich, was sie wollen, und verschwinden wieder. Das bedeutet, dass die einzige Quelle der Wahrheit darüber, was GPTBot, ClaudeBot, PerplexityBot und der Rest tatsächlich auf Ihrer Website getan haben, in einer Datei liegt, die Ihr Entwickler wahrscheinlich alle 14 Tage rotiert und löscht: das Serverzugriffsprotokoll.
Die Analyse der Logdateien von KI-Crawlern ist die einzige ehrliche Aufzeichnung darüber, wer was wann abgerufen hat und ob diese Daten überhaupt echt waren. Alles andere sind Schlussfolgerungen. Dies ist das Prüfungsschema, das ich anwende, wenn ein Kunde wissen will, was die Antwort-Maschinen mit seiner Website machen und warum die meisten der “unsere Inhalte werden trainiert”-Panik entweder ungeprüft oder schlichtweg falsch ist.
Warum sind GA4 und die meisten Analyseprogramme strukturell blind für KI-Bots?
GA4 ist ein Client-seitiges Messinstrument. Es lädt ein Tag, das Tag wird in einer browserähnlichen Umgebung ausgeführt, und ein Ereignis wird gesendet. Keine JavaScript-Ausführung, kein Ereignis. AI-Crawler verhalten sich wie klassische HTTP-Clients: Sie geben einen GET ab, parsen das Markup serverseitig und berühren Ihr Tag nicht. Ihre Verhaltensanalyse zeigt also null Sitzungen von GPTBot an, auch wenn Ihre Protokolle Zehntausende von dessen Anfragen ausweisen. Daraus wird gefolgert: “Die KI crawlt uns nicht”. Sie tut es. Sie messen nur mit dem falschen Instrument.
Dies ist derselbe architektonische Grund, warum Ihre kritischen Inhalte im rohen HTML und nicht in einer vom Client gerenderten Shell vorliegen müssen. Wenn eine Passage erst nach der JavaScript-Hydrierung erscheint, wird ein KI-Crawler, der JS nicht ausführt, sie nie aufnehmen. Die Protokolle machen dies auf eine Art und Weise sichtbar, wie es kein Rendering-Test kann: Sie sehen genau, welche URLs der Bot aufgerufen hat, und durch Querverweise auf die von Ihrem Server zurückgegebene Antwort, welche Bytes er genau erhalten hat.
Schulungs-Crawler vs. Live-Retrieval-Agenten: Hören Sie auf, beide als eine Sache zu behandeln
Der größte analytische Fehler, den ich sehe, ist, alle KI-Benutzer-Agenten in einen “KI-Bot”-Eimer zu werfen. Sie haben völlig unterschiedliche Funktionen und verlangen von Ihnen unterschiedliche Entscheidungen. Im Großen und Ganzen gibt es zwei Klassen.
Ausbildung der Crawler Inhalte sammeln, um Grundmodelle zu erstellen oder zu verfeinern. Sie arbeiten massenhaft, systematisch und es ist ihnen gleichgültig, ob ein Mensch wartet. Zu dieser Gruppe gehören GPTBot (OpenAI), ClaudeBot (Anthropisch), CCBot (Common Crawl, das viele Modelle nachgelagert einlesen), und der Zugriff, der durch Google-Extended (Googles Token für das Gemini-Training, bei dem es sich um eine robots.txt-Anweisung und nicht um einen separaten Crawling-Benutzer-Agenten handelt). Wenn Sie diese blockieren, wirkt sich das darauf aus, ob Ihre Inhalte in das nächste Modell einfließen. Es hat keinen Einfluss darauf, ob Sie heute in einer Live-Antwort erscheinen.
Live-Abrufagenten eine Seite abrufen, weil ein Nutzer gerade eine Frage gestellt hat und die Suchmaschine jetzt ein Zitat benötigt. Dies ist die Gruppe, die die Sichtbarkeit von KI-Empfehlungen tatsächlich vorantreibt: ChatGPT-Benutzer (OpenAIs On-Demand-Fetch, wenn ein Benutzer ChatGPT zum Durchsuchen auffordert), OAI-SearchBot (OpenAIs Index für ChatGPT-Suchergebnisse), und PerplexityBot (Abruf der Perplexität). Wenn Sie diese blockieren, entziehen Sie sich selbst der Antwort. Viele Websites blockieren “AI” pauschal in robots.txt, töten OAI-SearchBot und ChatGPT-User zusammen mit GPTBot und wundern sich dann, warum sie aus ChatGPT-Zitaten verschwunden sind. Sie haben den Boten und den Kunden erschossen.
OpenAI selbst dokumentiert diese Trennung und die unabhängige Kontrolle, die sie Ihnen gibt: Sie können OAI-SearchBot erlauben, in der Suche zu erscheinen, während Sie GPTBot verbieten, aus dem Training auszusteigen.[1] Wenn Sie die beiden Klassen als eine behandeln, ist jede nachgelagerte Entscheidung, die Sie treffen, falsch.
Ein funktionierender Spickzettel für Benutzer-Agenten
| Benutzer-Agent-Token | Betreiber | Klasse | Was eine Sperrung Sie kostet |
|---|---|---|---|
| GPTBot | OpenAI | Ausbildung | Nur aus den Trainingsdaten des zukünftigen Modells |
| OAI-SearchBot | OpenAI | Abruf / Index | Außerhalb der ChatGPT-Suchergebnisse |
| ChatGPT-Benutzer | OpenAI | Live-Abruf | Kann nicht abgerufen werden, wenn ein Benutzer ChatGPT zum Durchsuchen auffordert |
| ClaudeBot | Anthropisch | Ausbildung | Aus den zukünftigen Claude-Trainingsdaten |
| PerplexityBot | Perplexität | Abruf / Index | Antworten und Zitate von Out of Perplexity |
| CCBot | Gemeinsames Kriechen | Ausbildung (vorgelagert) | Aus einem Datensatz nehmen viele Modelle auf |
| Google-Extended | Trainingssteuerung (Roboter Token) | Außerhalb des Gemini-Trainings; wirkt sich nicht auf die Suche aus |
Das Wachstum, das dies zu einer nicht-optionalen Option macht
Vor zwei Jahren war dies eine Fußnote. Jetzt ist es eine Budgetlinie. Die netzwerkweite Analyse von Cloudflare ergab, dass die GPTBot-Anfragen zwischen Mai 2024 und Mai 2025 ungefähr 305% während die Googlebot-Anfragen insgesamt um 96% zunahmen. Die auffälligste Zahl ist die des Live-Abrufs: ChatGPT-Benutzeranfragen stiegen um 2.825% im gleichen Zeitraum, was zeigt, wie oft die Nutzer ChatGPT jetzt bitten, eine Live-Seite aufzurufen.[2]

Eine fast 30-fache Steigerung bei einem Abrufagenten ist kein Geräusch, das man auf einem gemeinsam genutzten Host ignorieren kann. Es handelt sich um echte Bandbreite, echte Ursprungslast und echten Crawl-Budget-Wettbewerb. Damit kommen wir zur zweiten harten Wahrheit: Ein großer Teil des Datenverkehrs, der sich als diese Bots ausgibt, ist gelogen.
Reverse-DNS-Verifizierung: Der meiste “AI-Bot”-Verkehr in Ihren Protokollen ist gefälscht
Ein User-Agent-String ist ein Request-Header. Jeder kann ihn setzen. Einstellung Benutzer-Agent: GPTBot ist eine einzeilige Änderung, und Scraper, Paywall-Jumpers und Konkurrenten machen das ständig, weil das gesamte "allow-by-user-agent"-Modell naiv auf diese Behauptung vertraut. Wenn Sie einen Crawl-Bericht direkt auf der Grundlage des User-Agent-Feldes erstellen, handelt es sich um eine Fiktion. Die Verifizierung ist nicht optional, sondern der erste Filterschritt, bevor eine Zahl, die Sie produzieren, etwas bedeutet.
Es gibt zwei zuverlässige Methoden, die in der Reihenfolge ihrer Anwendung bevorzugt werden.
1. Veröffentlichte IP-Bereichsdateien. Die seriösen Betreiber veröffentlichen maschinenlesbare IP-Listen, die Sie abgleichen können. OpenAI veröffentlicht gptbot.json, searchbot.json und chatgpt-user.json; Common Crawl veröffentlicht seine Bereiche; Google veröffentlicht seine Crawler-IP-Listen. Gleichen Sie die Quell-IP der Anfrage mit der entsprechenden Datei ab. Wenn sie nicht in der Liste steht, ist der User-Agent ein Lügner, Punkt. Dies ist die sauberste Überprüfung, da sie überhaupt nicht von DNS abhängt.
2. Reverse-DNS plus Vorwärts-Bestätigung. Bei Anbietern, die keine IP-Dateien veröffentlichen (der ClaudeBot von Anthropic ist ein bemerkenswerter Fall), verwenden Sie die gleiche vorwärtsbestätigte Reverse-DNS-Technik, die Google seit Jahren zur Überprüfung von Googlebot empfiehlt.[3]
Die Logik: Führen Sie einen Reverse-Lookup für die Quell-IP durch, um einen Hostnamen zu erhalten, bestätigen Sie, dass der Hostname zum beanspruchten Betreiber gehört, führen Sie dann einen Forward-Lookup für diesen Hostnamen durch und bestätigen Sie, dass er zur ursprünglichen IP zurückführt. Beide Richtungen müssen übereinstimmen.
# Schritt 1: Reverse-Lookup der IP, die behauptet, ein Bot zu sein
dig -x 66.249.66.1 +kurz
# -> crawl-66-249-66-1.googlebot.com.
# Schritt 2: Vorwärtssuche nach diesem Hostnamen
dig crawl-66-249-66-1.googlebot.com +kurz
# -> 66.249.66.1 (Treffer: verifiziert)
# Wenn der Hostname nicht zum Betreiber gehört,
# oder der Forward Lookup liefert nicht die ursprüngliche IP,
# ist die Anfrage gefälscht. Verwerfen Sie sie vor der Meldung.
Führen Sie diesen Test mit einer Stichprobe aller Benutzer-Agenten durch, die Sie interessieren. Auf den meisten Websites, die ich überprüfe, wird ein bedeutender Teil der “GPTBot”- und “PerplexityBot”-Treffer nicht verifiziert. Die Meldung nicht verifizierter User-Agents als echte KI-Crawl-Aktivität ist die häufigste Art und Weise, wie diese Audits die Leute, die für sie bezahlen, in die Irre führen.
Der Querverweis: Logs vs Crawl vs Analytics
Eine einzige Datenquelle lügt durch Auslassung. Die Methode, die tatsächlich zu Entscheidungen führt, ist ein dreifacher Abgleich. Jede Quelle beantwortet eine andere Frage, und die Lücken dazwischen sind die Quelle der Erkenntnis.
- Server-Protokolle Antwort: Was haben Bots und Nutzer tatsächlich angefordert, und welchen Statuscode haben wir zurückgegeben? Dies ist die Grundwahrheit für das Verhalten.
- Das eigene Kriechen eines Kriechers (Screaming Frog, Sitebulb oder Ihr Sitemap-Export) antwortet: Welche URLs glauben wir, dass sie existieren und erreichbar sein sollten?
- Analytik und Suchkonsole Antwort: Womit haben sich die Menschen beschäftigt, und was hat den Wert bestimmt?
Legen Sie die drei nebeneinander, verschlüsselt auf URL, und lesen Sie die Unterschiede:
| In Protokollen? | In Crawl/Sitemap? | In der Analytik? | Was es bedeutet |
|---|---|---|---|
| Ja (KI-Bot) | Ja | Kein menschlicher Verkehr | Die KI nimmt sie auf, aber der Mensch landet nicht. Ein Kandidat für reine KI-Inhalte oder dünne Inhalte, für die der Bot Budget verschwendet. |
| Ja (KI-Bot, schwer) | Nein | Nein | Der Bot stürzt sich auf URLs, die Sie nicht einmal auflisten: Parameterexplosionen, Facettenfilter, alter paginierter Müll. Verschwendung von Crawl-Budget. |
| Nein | Ja | Ja | Wichtige Seite, die kein AI-Crawler abgerufen hat. Überprüfen Sie robots.txt, interne Links und dass die Seite in Roh-HTML vorliegt. |
| Ja (gibt 404/5xx zurück) | Ja | k.A. | Sie füttern die AI-Crawler mit Fehlern. Sie erfahren, dass Ihre Website fehlerhaft ist; Abrufagenten lassen Sie aus den Antworten fallen. |
Eine konkrete, wiederholbare Methode: Exportieren Sie Ihr Zugriffsprotokoll für ein sauberes 30-Tage-Fenster, filtern Sie nur verifizierte Bot-Treffer, normalisieren Sie die URL (entfernen Sie Sitzungsparameter, die nicht gezählt werden sollen), und verknüpfen Sie dann Ihre Sitemap und Ihren Search-Console-Export über den URL-Schlüssel. Gruppieren Sie nach User-Agent-Klassen (Training vs. Abruf) und nach Statuscode.
Innerhalb eines Nachmittags werden Sie wissen, welche URLs die Antwortmaschinen tatsächlich abrufen, welche sie mit Anfragen vergeuden und welche Ihrer Geldseiten sie noch nie angefasst haben. Das ist weit entfernt von “KI crawlt uns oft”.”
Erkennen von Verschwendung im Kriechbudget, bevor sie Sie kostet
Das Crawl-Budget war eine Googlebot-Konversation. Jetzt ist es auch eine KI-Bot-Konversation, und die KI-Crawler sind weit weniger diszipliniert. Die Abfallsignaturen sind in den Protokollen der verifizierten Bots zu finden:
- Parameter- und Facettenexplosionen. Zählen Sie unterschiedliche URLs pro Vorlage. Wenn ein Bot 12.000 Varianten von
/shop/?color=&size=&sort=, Das heißt, das Budget wird für Beinahe-Duplikate ausgegeben, anstatt für Ihre Kategorie- und Produktseiten. - Statuscode-Verteilung pro Bot. Ein gesundes Profil besteht zumeist aus 200ern. Ein steigender Anteil von 301/302-Ketten bedeutet, dass der Bot Anfragen auf Weiterleitungen verbrennt; ein steigender Anteil von 404/410 bedeutet, dass er toten URLs hinterherläuft; 5xx bedeutet, dass Ihr Ursprung unter der Last zusammenbricht.
- Wiederholte Abrufe von unveränderten URLs. Wenn ein Retrieval Agent dieselbe Seite stündlich mit einem 200er abruft und Sie sie nicht ändern, werden Ihre Caching- und Conditional-Request-Header (ETag, Last-Modified) nicht beachtet oder gesendet.
- Bot-Treffer auf URLs, die in robots.txt verboten sind. Wohlerzogene Bots respektieren sie; Treffer auf nicht zugelassene Pfade von einer verifizierten IP sind einen genaueren Blick wert, und Treffer von nicht verifizierten IPs bestätigen das oben beschriebene Spoofing-Problem.
Bei gemeinsam genutztem oder bescheidenem Hosting ist dies sogar noch wichtiger. Ein 30-facher Sprung bei einem Abrufagenten, multipliziert mit allen anderen, ist ein Lastprofil, für das Ihr Stack nicht vorgesehen war. Wenn Sie eine Belastung durch Bot-Verkehr feststellen, liegt die Lösung teilweise in der Architektur und nicht nur in der Bearbeitung von robots.txt: Caching, bedingte Anfragen und das Wissen, ob Ihr WordPress-System kann das Anfragevolumen tatsächlich bewältigen bevor Sie noch mehr davon einladen.
Warum die Protokolle und die 2-MB-Regel sich gegenseitig verstärken
Zwei Tatsachen kommen hinzu. Erstens führen KI-Crawler kein JavaScript aus, so dass alles, was nicht im rohen HTML steht, für sie unsichtbar ist. Zweitens haben Crawler Byte-Limits, wie viel eines Dokuments sie tatsächlich lesen können. Googlebot, zum Beispiel, liest nur die ersten 2 MB einer Seite, und aufgeblähter Markup schiebt Ihren echten Inhalt über die Grenze. In Ihren Protokollen wird der Abruf als saubere 200 angezeigt, was gut aussieht, während der Bot im Stillen nur das erste Stück einer 4 MB großen Seite aufgenommen hat. Der Statuscode lügt, weil er zu großzügig ist. Das ist genau der Grund, warum die Log-Analyse mit dem Wissen gepaart werden muss, welche Bytes Sie tatsächlich bereitstellen: Eine 200 ist notwendig, aber nicht ausreichend.
Das Urteil
Die meisten KI-Sichtbarkeitsberichte basieren auf den beiden schwächsten möglichen Fundamenten: einem Analysetool, das den Datenverkehr nicht sehen kann, und einem User-Agent-String, den jeder fälschen kann. Das Serverprotokoll ist das einzige Artefakt, das aufzeichnet, was wirklich passiert ist, und selbst das ist wertlos, solange Sie den Anfragenden nicht verifizieren und Training und Abruf nicht trennen. Führen Sie den Drei-Wege-Querverweis durch, verifizieren Sie jeden Bot, bevor Sie ihn zählen, und Sie hören auf, über KI-Crawler zu raten, und beginnen, sie zu verwalten. Wenn Sie das nicht tun, treffen Sie robots.txt-Entscheidungen, die Sie stillschweigend von den Antworten entfernen, die Ihre Kunden bereits woanders erhalten.
Referenzen
- OpenAI, “Overview of OpenAI crawlers” - dokumentiert GPTBot, OAI-SearchBot und ChatGPT-User und deren unabhängige robots.txt Kontrolle. plattform.openai.de/docs/bots
- Cloudflare, “From Googlebot to GPTBot: who's crawling your site in 2025” - GPTBot ~305% and ChatGPT-User ~2,825% request growth, May 2024 to May 2025. blog.cloudflare.com
- Google Search Central, “Überprüfen von Googlebot und anderen Google-Crawlern” - Reverse-DNS-Methode mit Vorwärtsbestätigung. entwickler.google.de
Entdecke mehr von WpConsults
Melde dich für ein Abonnement an, um die neuesten Beiträge per E-Mail zu erhalten.
