GPTBot, OAI-SearchBot & Co: KI-Crawler technisch verstehen

1. Warum KI-Crawler anders funktionieren als klassische Suchmaschinen-Bots

Ein klassischer Suchmaschinen-Bot wie der Googlebot verfolgt ein einziges Ziel: Seiten für einen Index erfassen, aus dem später eine Trefferliste mit zehn blauen Links entsteht. Ein KI-Crawler verfolgt mehrere unterschiedliche Ziele gleichzeitig, und genau das macht die technische Einordnung komplizierter. Manche KI-Crawler sammeln Trainingsdaten für zukünftige Modellgenerationen, andere holen in Echtzeit Inhalte, um eine konkrete Nutzerfrage in ChatGPT, Claude oder Perplexity zu beantworten. Beide Vorgänge sehen im Server-Log ähnlich aus, haben aber vollständig unterschiedliche Konsequenzen für Sichtbarkeit und Zitierhäufigkeit.

Für Website-Betreiber bedeutet das: Eine pauschale Entscheidung "KI-Bots sperren" oder "KI-Bots erlauben" greift zu kurz. Wer KI-Crawler pauschal aussperrt, verhindert nicht nur Trainingsdatensammlung, sondern häufig auch die Live-Retrieval-Zugriffe, die für eine Zitierung in einer aktuellen Chat-Antwort nötig sind. Wer alle KI-Crawler pauschal zulässt, verliert die Kontrolle darüber, welche Inhalte in Trainingskorpora landen. Die differenzierte Steuerung setzt voraus, dass man die einzelnen Bots an ihrem User-Agent-String erkennt und ihren jeweiligen Zweck kennt.

Dieser Beitrag ordnet die wichtigsten KI-Crawler technisch ein: welche User-Agent-Strings sie verwenden, wie man sie im Server-Log von normalem Traffic unterscheidet, und wie robots.txt sowie das neuere llms.txt-Format genutzt werden, um granular zwischen Training und Live-Retrieval zu unterscheiden.

2. Die wichtigsten KI-Crawler im Überblick

Die aktuell relevantesten KI-Crawler stammen von den großen Anbietern generativer KI-Systeme. GPTBot ist der Trainingscrawler von OpenAI, der Inhalte für zukünftige Modellversionen sammelt. Davon zu unterscheiden ist OAI-SearchBot, der Seiten indexiert, damit ChatGPT sie in der Websuche-Funktion referenzieren kann, sowie ChatGPT-User, der nur dann eine Seite abruft, wenn ein Nutzer in einem konkreten Chat einen Link teilt oder das Modell während der Konversation live nachschlägt.

ClaudeBot von Anthropic übernimmt eine vergleichbare Rolle für das Training der Claude-Modellfamilie, während separate, nutzerausgelöste Abrufe unter eigenen User-Agent-Kennungen laufen, wenn ein Nutzer Claude aktiv nach aktuellen Inhalten fragt. PerplexityBot ist der Crawler von Perplexity AI und arbeitet stärker retrieval-orientiert als reine Trainingscrawler, weil Perplexity als Antwortmaschine bei nahezu jeder Anfrage aktuelle Quellen nachladen muss. Google-Extended ist kein eigenständiger Crawler, sondern ein zusätzliches Steuerungs-Token, mit dem Website-Betreiber getrennt vom regulären Googlebot festlegen können, ob Inhalte für das Training von Gemini und für KI-Overviews verwendet werden dürfen.

CCBot gehört zu Common Crawl, einer gemeinnützigen Organisation, die einen offenen Web-Korpus veröffentlicht. Dieser Korpus wird von zahlreichen KI-Labors als Trainingsgrundlage genutzt, auch wenn Common Crawl selbst kein KI-Unternehmen ist. Das macht CCBot zu einem indirekten, aber einflussreichen KI-Crawler, weil eine Sperrung dort potenziell mehrere nachgelagerte Trainingsanwendungen gleichzeitig betrifft. Anbieter aktualisieren ihre Bot-Listen regelmäßig, ein Blick in die jeweils aktuelle Dokumentation vor der robots.txt-Konfiguration ist deshalb Pflicht.

3. User-Agent-Strings erkennen und im Server-Log identifizieren

Jeder KI-Crawler identifiziert sich über einen eindeutigen User-Agent-String, der beim HTTP-Request im Header mitgesendet wird. Diese Strings folgen meist dem Muster einer Basis-Kennung, gefolgt von einer Versionsnummer und einer URL zur Dokumentation des Anbieters. Die Identifikation im Server-Log ist der erste Schritt jeder GEO-Analyse, denn ohne saubere Zuordnung lässt sich weder feststellen, wie oft ein Modell die eigene Website liest, noch ob eine robots.txt-Regel tatsächlich greift.

Ein häufiger Fehler ist, im Log nur nach dem offensichtlichen Namen wie "GPT" zu suchen. Das übersieht Varianten wie ChatGPT-User oder abweichende Groß-Kleinschreibung. Robuste Suchmuster nutzen deshalb reguläre Ausdrücke, die mehrere bekannte Tokens gleichzeitig abdecken, und werden regelmäßig aktualisiert, sobald ein Anbieter einen neuen KI-Crawler einführt oder einen bestehenden umbenennt.

# Identify AI crawler hits in an nginx access log
# Common access log format: IP - - [date] "METHOD path HTTP/1.1" status size "referer" "user-agent"

grep -E -i '(GPTBot|OAI-SearchBot|ChatGPT-User|ClaudeBot|Claude-User|PerplexityBot|Google-Extended|CCBot)' \
  /var/log/nginx/access.log | tail -n 20

# Count hits per AI crawler over the current log file
grep -E -o -i '(GPTBot|OAI-SearchBot|ChatGPT-User|ClaudeBot|Claude-User|PerplexityBot|Google-Extended|CCBot)' \
  /var/log/nginx/access.log | sort | uniq -c | sort -rn

# Example output:
#   842 GPTBot
#   311 ClaudeBot
#   198 PerplexityBot
#    76 OAI-SearchBot
#    12 ChatGPT-User

4. Training vs. Live-Retrieval: zwei unterschiedliche Zwecke

Der wichtigste konzeptionelle Unterschied zwischen den KI-Crawlern liegt im Zeitpunkt und Zweck des Zugriffs. Trainingscrawler wie GPTBot, ClaudeBot oder CCBot besuchen eine Website unabhängig von konkreten Nutzeranfragen, in periodischen Wellen, um Inhalte in einen Trainingskorpus für zukünftige Modellversionen aufzunehmen. Ein Treffer durch diese Crawler beeinflusst nicht sofort etwas Sichtbares, sondern potenziell erst Monate später, wenn ein neues Modelltraining abgeschlossen und ausgerollt wird.

Live-Retrieval-Crawler wie OAI-SearchBot, PerplexityBot oder nutzerausgelöste Varianten wie ChatGPT-User funktionieren fundamental anders: Sie werden durch eine konkrete Anfrage in Echtzeit ausgelöst, holen die aktuelle Seite, und die Inhalte fließen direkt und meist innerhalb von Sekunden in eine Antwort ein, die der Nutzer sofort sieht. Dieser Unterschied hat direkte GEO-Konsequenzen: Eine Website, die für Live-Retrieval blockiert ist, kann in aktuellen Chat-Antworten faktisch nicht zitiert werden, selbst wenn ihre Inhalte im Trainingskorpus enthalten sind, weil das Modell den zugrundeliegenden Trainingsstand nicht mit einer live überprüften, aktuellen Quelle verwechseln darf.

In der Praxis bedeutet das: Wer aktuelle Preise, Verfügbarkeiten oder Nachrichten über KI-Suchsysteme sichtbar machen will, muss vor allem die Live-Retrieval-KI-Crawler zulassen, während die Entscheidung über Trainingscrawler eine separate, oft eher strategische oder rechtliche Frage ist, die unabhängig von der kurzfristigen GEO-Sichtbarkeit getroffen werden kann.

5. robots.txt: KI-Crawler gezielt steuern

Die robots.txt-Datei bleibt auch für KI-Crawler das primäre Steuerungsinstrument, weil die meisten seriösen Anbieter das Robots-Exclusion-Protokoll respektieren. Der entscheidende Vorteil gegenüber der Steuerung klassischer Suchmaschinen-Bots: Weil jeder KI-Crawler-Zweck einen eigenen User-Agent-Token besitzt, lässt sich granular zwischen Trainingszugriff und Live-Retrieval-Zugriff unterscheiden, ohne den gesamten KI-Traffic pauschal zu blockieren.

Eine typische Konfiguration erlaubt Live-Retrieval-Crawler, weil sie direkte Sichtbarkeit in Chat-Antworten erzeugen, blockiert aber reine Trainingscrawler, wenn ein Betreiber die eigenen Inhalte nicht unkontrolliert in zukünftigen Modellgenerationen wiederfinden möchte. Diese Trennung ist eine bewusste strategische Entscheidung und keine rein technische, denn sie betrifft die Frage, wessen langfristige Kontrolle über die eigenen Inhalte wichtiger ist als kurzfristige GEO-Sichtbarkeit.

# robots.txt, differentiated control of AI crawlers
# Placed at https://example.com/robots.txt

User-agent: Googlebot
Allow: /

# Training crawlers, blocked to keep content out of future model training
User-agent: GPTBot
Disallow: /

User-agent: ClaudeBot
Disallow: /

User-agent: CCBot
Disallow: /

# Live retrieval crawlers, allowed to enable citations in chat answers
User-agent: OAI-SearchBot
Allow: /

User-agent: ChatGPT-User
Allow: /

User-agent: PerplexityBot
Allow: /

# Separate opt-out token for Gemini / AI Overviews training
User-agent: Google-Extended
Disallow: /

Sitemap: https://example.com/sitemap.xml

6. llms.txt: der neue Standard für KI-Zugriffssteuerung

Neben robots.txt hat sich mit llms.txt ein ergänzender, freiwilliger Standard etabliert, der nicht primär Zugriff blockiert, sondern KI-Systemen eine strukturierte, maschinenlesbare Übersicht der wichtigsten Inhalte einer Website liefert. Die Datei liegt analog zu robots.txt im Root-Verzeichnis unter /llms.txt und enthält in Markdown-Syntax eine kuratierte Liste zentraler Seiten, kurz beschrieben, damit ein KI-Crawler mit begrenztem Zeitbudget die relevantesten Inhalte zuerst erfasst.

Anders als robots.txt ersetzt llms.txt keine Zugriffssteuerung, sondern ergänzt sie um eine Priorisierungsebene. Während robots.txt die binäre Frage "darf gecrawlt werden" beantwortet, beantwortet llms.txt die Frage "was ist an dieser Website inhaltlich am wichtigsten". Für Websites mit großem Umfang, etwa Dokumentationsseiten oder umfangreiche Blogs, reduziert eine gepflegte llms.txt-Datei das Risiko, dass ein KI-Crawler sein Zeitbudget mit weniger relevanten Unterseiten verbraucht, bevor er die Kerninhalte erreicht.

# /llms.txt, structured overview for AI crawlers with limited crawl budget
# Markdown syntax, placed in the site root next to robots.txt

# Mironsoft

> Magento 2 & Hyvä development agency based in Germany,
> specializing in performance, GEO and headless commerce.

## Core Pages

- [Services](https://mironsoft.de/leistungen): Magento development,
  Hyvä theme implementation, performance audits
- [Blog](https://mironsoft.de/blog): technical articles on Magento,
  SEO, GEO and DevOps
- [Contact](https://mironsoft.de/contact): direct inquiry form

## Optional

- [About](https://mironsoft.de/ueber-uns): company background

7. Server-Log-Analyse: KI-Traffic auswerten

Die reine Identifikation einzelner Zeilen im Server-Log reicht für eine belastbare GEO-Analyse nicht aus. Erst die Aggregation über Zeit zeigt, ob ein KI-Crawler regelmäßig neue Inhalte abholt, ob bestimmte Seitentypen bevorzugt gelesen werden, und ob die Frequenz nach einer Content-Änderung ansteigt. Diese Auswertung liefert einen der wenigen direkten, serverseitigen Belege dafür, dass eine Website überhaupt als Retrieval-Quelle in Betracht gezogen wird, unabhängig davon, ob am Ende tatsächlich zitiert wird.

In der Praxis lohnt sich ein einfaches Skript, das die Logdateien periodisch parst, Treffer nach Crawler-Typ und aufgerufener URL gruppiert, und die Ergebnisse in einer strukturierten Form ablegt, die sich mit dem Zeitpunkt von Content-Updates korrelieren lässt. Auffällig hohe Zugriffszahlen eines KI-Crawlers auf eine einzelne Seite, gefolgt von wiederholten Besuchen im Wochenrhythmus, deuten auf eine Seite hin, die als potenzielle Zitierquelle im Live-Retrieval-Index gehalten wird.

#!/usr/bin/env bash
# ai-crawler-report.sh, weekly summary of AI crawler activity per URL
set -euo pipefail

LOG_FILE="/var/log/nginx/access.log"
PATTERN='(GPTBot|OAI-SearchBot|ChatGPT-User|ClaudeBot|PerplexityBot|Google-Extended|CCBot)'

echo "== AI crawler hits by bot =="
grep -E -o -i "$PATTERN" "$LOG_FILE" | sort | uniq -c | sort -rn

echo
echo "== Top 10 URLs visited by AI crawlers =="
grep -E -i "$PATTERN" "$LOG_FILE" \
  | awk '{print $7}' \
  | sort | uniq -c | sort -rn | head -n 10

8. IP-Verifizierung und Bot-Spoofing erkennen

Ein User-Agent-String allein ist keine verlässliche Identifikation, weil er clientseitig frei gesetzt werden kann. Manche Scraper geben sich absichtlich als GPTBot oder ClaudeBot aus, um Zugriffsbeschränkungen zu umgehen oder um in Statistiken einen positiven Effekt vorzutäuschen. Die zuverlässige Verifizierung eines echten KI-Crawlers erfordert deshalb einen zusätzlichen Schritt: den Abgleich der Quell-IP-Adresse mit dem offiziell dokumentierten IP-Bereich des jeweiligen Anbieters, meist per Reverse-DNS-Lookup mit anschließendem Forward-Check.

Große Anbieter veröffentlichen ihre IP-Bereiche oder ein Verifizierungsverfahren in der eigenen Bot-Dokumentation, ähnlich wie es Google seit Jahren für den Googlebot praktiziert. Wer belastbare GEO-Kennzahlen erheben will, etwa um den Effekt eines Content-Updates auf die Crawling-Frequenz eines bestimmten KI-Crawlers zu messen, sollte gespoofte Treffer vor der Auswertung herausfiltern, da sie sonst die Statistik verzerren und falsche Schlüsse über die tatsächliche GEO-Relevanz einer Seite nahelegen.

#!/usr/bin/env bash
# verify-crawler-ip.sh, reverse DNS verification to detect UA spoofing
set -euo pipefail

IP="$1"

# Step 1: reverse lookup to hostname
HOSTNAME=$(dig +short -x "$IP" | sed 's/\.$//')

if [[ -z "$HOSTNAME" ]]; then
  echo "[WARN] No PTR record for $IP, likely spoofed or unverifiable"
  exit 1
fi

# Step 2: forward lookup must resolve back to the same IP
FORWARD_IP=$(dig +short "$HOSTNAME" | tail -n 1)

if [[ "$FORWARD_IP" == "$IP" ]]; then
  echo "[OK] $IP verified as $HOSTNAME"
else
  echo "[FAIL] $IP claims $HOSTNAME but forward lookup returns $FORWARD_IP"
fi

9. KI-Crawler im direkten Vergleich

Die folgende Übersicht fasst Zweck, typischen User-Agent-Token und empfohlene Steuerung der wichtigsten KI-Crawler zusammen. Sie ersetzt keine tagesaktuelle Prüfung der Anbieter-Dokumentation, dient aber als schnelle Orientierung bei der robots.txt-Konfiguration.

Die Tabelle zeigt das zentrale Muster: Live-Retrieval-KI-Crawler sollten in den meisten Fällen erlaubt bleiben, weil sie direkte Sichtbarkeit erzeugen, während Trainingscrawler eine strategische Abwägung zwischen langfristiger Content-Kontrolle und potenzieller zukünftiger Sichtbarkeit in neuen Modellgenerationen erfordern.

10. Zusammenfassung

KI-Crawler sind keine homogene Gruppe, sondern erfüllen unterschiedliche Funktionen: GPTBot, ClaudeBot und CCBot sammeln Trainingsdaten für zukünftige Modellgenerationen, während OAI-SearchBot, PerplexityBot und ChatGPT-User in Echtzeit Inhalte für konkrete Nutzeranfragen abrufen. Diese Unterscheidung ist die Grundlage jeder sinnvollen Steuerungsentscheidung, denn nur wer die Zwecke kennt, kann in der robots.txt gezielt zwischen langfristiger Content-Kontrolle und kurzfristiger GEO-Sichtbarkeit abwägen.

Die technische Umsetzung stützt sich auf drei Bausteine: eine differenzierte robots.txt-Konfiguration, eine ergänzende llms.txt-Datei für priorisiertes Crawling, und eine regelmäßige Server-Log-Analyse inklusive IP-Verifizierung, um gespoofte Treffer auszuschließen. Wer diese drei Bausteine kombiniert, gewinnt echte Sichtbarkeit darüber, welche KI-Crawler die eigene Website tatsächlich besuchen, und kann datenbasiert statt aus dem Bauch heraus entscheiden.

11. FAQ: KI-Crawler technisch verstehen und steuern