Ein Access-Log in 30 Minuten lesen: was die KI-Bots wirklich auf Ihrer Website tun

Kein Dashboard sagt einem Herausgeber, ob ChatGPT, Claude oder Perplexity seine Seiten lesen. Die Search Console deckt nur Google ab, und die generativen Suchmaschinen liefern nichts. Die einzige vorhandene Quelle ist das Anfrageprotokoll des Servers, das Access-Log, das jedes Hosting erzeugt und fast niemand öffnet. In einer halben Stunde liest man darin, mit den Werkzeugen jedes Linux-Servers, wer kommt, wozu, und was der Server geantwortet hat. Hier ist die Methode, die wir anwenden, Schritt für Schritt, mit den Befehlen. So teilt sich die halbe Stunde auf: fünf Minuten für die Extraktion, fünf für die Zählung nach Bot, zehn für die Prüfung der Adressen, fünf für die Antwortcodes, fünf für die Pfade und den Takt.

Alle folgenden Befehle setzen ein Log im Combined-Format voraus und laufen auf der in Schritt 1 erzeugten Datei. Sie verwenden nur grep, awk, sort und uniq.

Was eine Zeile enthält

Ein Access-Log im Combined-Format, dem Standard von Apache und nginx, enthält eine Zeile je Anfrage. Jede Zeile gibt der Reihe nach: die IP-Adresse des Clients, Datum und Uhrzeit, die angefragte Methode und den Pfad, den Antwortcode, die gesendete Größe, den Referer und den User-Agent. Für die Bot-Analyse zählen vier Felder:

Erste Prüfung, vor jeder Analyse: Ist die aufgezeichnete IP-Adresse die des Besuchers oder die eines Vermittlers? Hinter einem CDN oder einem Proxy sieht der Server die Adresse des Vermittlers, es sei denn, er ist so konfiguriert, dass er den Header ausliest, der die Ursprungsadresse transportiert. Scheinen alle Anfragen von einigen Dutzend Adressen zu kommen, ist der unten beschriebene Prüfschritt nicht möglich, und die Konfiguration ist vor dem Weitermachen zu korrigieren. Diese Falle haben wir in „Was die Firewall vor Ihren Logs verbirgt“ beschrieben.

Schritt 1: Zeitraum und KI-Bots eingrenzen

Man arbeitet über einen vollständigen Zeitraum, mindestens sieben Tage, denn die KI-Bots kommen nicht jeden Tag, und Schlüsse aus vierundzwanzig Stunden sind fast immer falsch. Danach extrahiert man die Zeilen, deren User-Agent eines der von den Anbietern veröffentlichten Tokens enthält: GPTBot, ChatGPT-User, OAI-SearchBot für OpenAI; ClaudeBot, Claude-User, Claude-SearchBot für Anthropic; PerplexityBot und Perplexity-User für Perplexity; Google-Extended taucht in den Logs nicht auf, da es ein Token der robots.txt ist und kein Bot. Die Referenzlisten sind die von OpenAI, Anthropic und Perplexity.

Ein grep-Filter auf diese Tokens, umgeleitet in eine Arbeitsdatei, genügt. Bei einem mittelgroßen Medium erhält man einige hundert bis einige tausend Zeilen pro Woche.

zcat -f access.log* \
  | grep -E 'GPTBot|ChatGPT-User|OAI-SearchBot|ClaudeBot|Claude-User|Claude-SearchBot|PerplexityBot|Perplexity-User' \
  > ia.log

Schritt 2: nach Bot und nach Rolle zählen

Jeder Anbieter betreibt mehrere Bots, die nicht dasselbe tun, und das ist die nützlichste Unterscheidung der ganzen Analyse. Ein Trainings-Bot sammelt Seiten für künftige Modelle. Ein Such-Bot baut einen Index auf, um Fragen zu beantworten. Ein Bot auf Anfrage holt eine Seite für eine Person, die dem Assistenten eine Frage stellt. Die Rollen und die Tokens haben wir in „robots.txt und KI“ ausgeführt.

Man zählt also die Zeilen je User-Agent und fasst sie in drei Spalten zusammen: Training, Suche, Nutzeragent. Das Ergebnis liest sich so:

• Anfragen allein zum Training bedeuten, dass die Website eingesammelt wird, sagen aber nichts darüber, ob sie zitiert wird.
• Anfragen zur Suche zeigen, dass die Website von der generativen Suchmaschine indexiert ist, die notwendige Bedingung dafür, zitiert zu werden.
• Anfragen eines Nutzeragenten sind das wertvollste Signal: Jede entspricht der Frage eines Nutzers, für die der Assistent diese Seite geholt hat.

grep -oE 'GPTBot|ChatGPT-User|OAI-SearchBot|ClaudeBot|Claude-User|Claude-SearchBot|PerplexityBot|Perplexity-User' ia.log \
  | sort | uniq -c | sort -rn

Schritt 3: prüfen, ob die Bots echt sind

Ein User-Agent wird frei angegeben. Jedes Skript kann sich als GPTBot ausgeben. Vor dem Zählen prüft man, ob die IP-Adressen zu den von jedem Anbieter veröffentlichten Bereichen gehören: OpenAI, Anthropic und Perplexity veröffentlichen Dateien mit Bereichen, und Google dokumentiert die Prüfung seiner Bots per Reverse DNS. Man extrahiert die verschiedenen Adressen je User-Agent, vergleicht sie mit den Bereichen und scheidet aus, was dort nicht steht. Die vollständige Methode mit ihren Fallen steht in „Ist ein Bot wirklich der, für den er sich ausgibt?“.

Auf den meisten Websites, die wir auditieren, finden wir welche: Anfragen, die sich als Googlebot oder GPTBot ausgeben, von Adressen, die weder Google noch OpenAI gehören. Eine veröffentlichungsfähige Volumenangabe dazu haben wir nicht; der Test dagegen kostet einen Befehl. Zählen ohne Prüfen heißt riskieren, getarnte Scraper zu messen.

# die verschiedenen Adressen eines Bots, abzugleichen mit den veröffentlichten Bereichen
awk '/GPTBot/ {print $1}' ia.log | sort -u

Schritt 4: die Antwortcodes lesen

Für jeden echten Bot schlüsselt man die Antwortcodes auf. Die erwartete Tabelle einer gesunden Website besteht fast vollständig aus 200, mit einigen 304, wenn der Server bedingte Anfragen beherrscht, und einigen 404 auf entfernten URLs. Drei Auffälligkeiten verlangen eine Handlung:

Eine Erinnerung zu den Abweisungen: Ein vom Origin-Server gesendeter 403 erscheint im Log. Ein vom CDN gesendeter 403 erscheint dort nicht, da die Anfrage nie ankam. Ein Log ohne jeden Fehler ist also kein Beweis dafür, dass keine Anfrage abgewiesen wird.

# der Antwortcode ist das 9. Feld des Combined-Formats
awk '/GPTBot/ {print $9}' ia.log | sort | uniq -c | sort -rn

Schritt 5: ansehen, welche Seiten gelesen werden

Viele Herausgeber hören vor diesem Schritt auf, dabei bringt er am meisten. Man zählt für jeden Such-Bot und jeden Nutzeragenten die angefragten Pfade und vergleicht sie mit der Liste der veröffentlichten Seiten. Diese Zählung beantwortet Fragen, die kein anderes Werkzeug entscheidet:

1. Welche Seiten werden nie gelesen? Ein seit zwei Monaten veröffentlichter Artikel, den kein Such-Bot angefragt hat, steht wahrscheinlich nicht in der Sitemap oder ist über keinen Link erreichbar.
2. Welche Seiten lesen die Nutzeragenten? Das sind die, die die Assistenten wirklich zitieren. Der Vergleich mit den Seiten, die man zitiert sehen möchte, sagt, wo die Schreibarbeit ansetzen muss.
3. Liest der Bot geänderte Seiten erneut? Wurde eine in der Vorwoche aktualisierte Seite nicht erneut angefragt, kommt das Frischesignal nicht an. Warum, haben wir in „XML-Sitemap: ein identisches lastmod auf allen URLs macht Ihre Sitemap nutzlos“ erklärt.

# die meistgelesenen Pfade des Such-Bots, 7. Feld
awk '/OAI-SearchBot/ {print $7}' ia.log | sort | uniq -c | sort -rn | head -30

Schritt 6: den Takt notieren und die Messung wiederholen

Die letzte Auswertung gilt der Zeit. Für jeden Bot notiert man die Zahl der Besuchstage im Zeitraum, den Abstand zwischen zwei Durchgängen und die gewohnte Uhrzeit. Ein Such-Bot, der täglich vorbeikommt, hat die Website in seinen Zyklus aufgenommen; ein Bot, der einmal kam, um alles zu lesen, und dann nur noch zur Sitemap zurückkehrte, wartet auf ein Änderungssignal. Dieser Takt ist die Referenz, mit der die folgenden Messungen verglichen werden, einmal pro Woche oder einmal pro Monat, je nach Veröffentlichungsrhythmus.

Die Arbeitsdatei ist ebenfalls aufzubewahren. Die Aufbewahrungsdauer hängt vom Hoster und vom Vertrag ab, und sie zählt oft in Tagen statt in Monaten: Prüfen Sie Ihre, bevor Sie sie brauchen. Danach existiert die Angabe nicht mehr, und eine im Dezember gestellte Frage zu dem, was im September geschah, bleibt ohne Antwort.

# Besuchstage, dann die übliche Uhrzeit
awk '/GPTBot/ {print substr($4,2,11)}' ia.log | sort -u
awk '/GPTBot/ {print substr($4,14,2)}' ia.log | sort | uniq -c

Die drei Fehler, die man beim ersten Mal fast immer macht

Der erste ist, aus einer Stichprobe zu schließen: die letzten Stunden, die erste Seite eines Werkzeugs, ein einziger Tag. Ein Bot kann an einem Dienstagabend die ganze Website gelesen haben und acht Tage lang nicht mehr auftauchen. Man sieht sich den ganzen Zeitraum an, bevor man sagt, dass er nicht kommt.

Der zweite ist, vom eigenen Rechner aus zu testen. Eine Anfrage mit dem User-Agent von GPTBot aus einem Büronetz zu senden und einen 403 zu erhalten, beweist nur, dass Hochstapler abgewiesen werden; der echte Bot kann durchaus durchkommen. Der einzige gültige Test ist der Vergleich zwischen dem, was das Log für den echten Bot zeigt, und dem, was man selbst erhält.

Der dritte ist, zu vergessen, was gar nicht bis zum Log gelangt. Eine Website hinter einem CDN, das die KI-Bots abweist, hat ein vollkommen sauberes Access-Log, ohne jede KI. Das Lesen der Logs beginnt beim Lesen der CDN-Konfiguration und bei den Protokollen des CDN selbst, wo sie zugänglich sind.

Was diese halbe Stunde einbringt

Am Ende der Übung weiß ein Herausgeber drei Dinge, die ihm kein Dashboard liefert: welche generativen Suchmaschinen seine Website indexieren, welche Seiten sie lesen, und ob reale Personen über einen Assistenten dort ankommen. Das ist die Grundlage jeder Sichtbarkeitsstrategie in den KI-Diensten, vor den Messungen des Share of Voice, die wir in „Die eigene Sichtbarkeit in den KI-Diensten messen“ beschreiben. Eine redaktionelle Plattform kann diese Auswertung automatisieren und täglich anzeigen; beim ersten Mal aber muss man sie von Hand gemacht haben, um zu wissen, worauf man schaut.