KI-Crawler gezielt über robots.txt erlauben oder blockieren

1. Warum KI-Crawler eine eigene Steuerung brauchen

Klassische robots.txt-Konfigurationen unterscheiden meist nur zwischen "alle Bots" und einzelnen Suchmaschinen wie Googlebot oder Bingbot. Mit dem Aufstieg generativer KI-Systeme ist eine neue Kategorie von Crawlern entstanden, die eigene, klar benannte User-Agents mitbringen: GPTBot von OpenAI, ClaudeBot von Anthropic, PerplexityBot von Perplexity, Google-Extended für Trainingsdaten von Google und CCBot vom Common Crawl-Projekt, das wiederum viele KI-Anbieter als Trainingsdatenquelle nutzen. Jeder dieser KI-Crawler hat einen anderen Zweck und andere Konsequenzen, wenn man ihm Zugriff gewährt oder verweigert.

Der zentrale Unterschied zu klassischen Suchmaschinen-Crawlern: ein KI-Crawler, der für das Training eines Sprachmodells Daten sammelt, hat eine andere Wirkung als ein KI-Crawler, der in Echtzeit für eine konkrete Nutzerfrage Content abruft und zitiert. Erstere Kategorie beeinflusst, was ein Modell irgendwann einmal "weiß", Letztere beeinflusst, ob die eigene Seite in der aktuellen Antwort als Quelle auftaucht. Eine undifferenzierte robots.txt-Regel, die alle KI-Crawler pauschal blockiert, kappt beide Wirkungen gleichzeitig, auch die gewollte.

Die Entscheidung, welche KI-Crawler man zulässt, ist deshalb keine rein technische Frage, sondern eine strategische: Will man in KI-Trainingsdaten vorkommen? Will man in Echtzeit-Antworten zitiert werden? Ist beides erwünscht, nur eines, oder keines? Die folgenden Abschnitte liefern die technischen Grundlagen und konkrete robots.txt-Direktiven, um diese Entscheidung präzise umzusetzen, statt sie einem pauschalen Alles-oder-nichts zu überlassen.

2. Trainingscrawler versus Retrieval-Crawler

Für eine sinnvolle KI-Crawler-Steuerung muss man zwei grundsätzlich verschiedene Kategorien unterscheiden. Trainingscrawler sammeln Content, der später in ein Sprachmodell einfließt, oft mit erheblicher zeitlicher Verzögerung zwischen Crawling und tatsächlichem Modelltraining. GPTBot und CCBot fallen primär in diese Kategorie. Ein Blockieren dieser KI-Crawler verhindert, dass der eigene Content in zukünftigen Modellversionen als Trainingsgrundlage dient, hat aber keinen unmittelbaren Effekt auf aktuelle Zitationen.

Retrieval-Crawler dagegen rufen Content in Echtzeit oder nahezu in Echtzeit ab, meist ausgelöst durch eine konkrete Nutzeranfrage, um eine aktuelle, faktenbasierte Antwort zu erstellen. PerplexityBot arbeitet überwiegend in diesem Modus, ebenso der Retrieval-Teil hinter ChatGPT mit aktivierter Websuche. Ein Blockieren dieser KI-Crawler hat direkte Konsequenzen: die eigene Seite kann nicht mehr als Quelle für tagesaktuelle KI-Antworten herangezogen werden, was der Sichtbarkeit in generativer Suche unmittelbar schadet.

Manche KI-Crawler bedienen beide Zwecke oder wechseln ihre Funktion über die Zeit, was die Einordnung erschwert. Google-Extended etwa steuert primär, ob Content für das Training von Gemini und andere KI-Funktionen von Google genutzt wird, unabhängig vom klassischen Googlebot-Crawling für die Suche. Diese Trennung erlaubt es, bei Google weiterhin klassisch gefunden zu werden, ohne automatisch Trainingsdaten für generative Google-Produkte bereitzustellen, sofern man Google-Extended gezielt blockiert.

3. robots.txt-Grundsyntax für KI-User-Agents

Die robots.txt-Datei liegt im Root-Verzeichnis einer Domain und wird von wohlverhaltenen KI-Crawlern vor dem eigentlichen Zugriff abgerufen. Jede Regel besteht aus einem User-agent-Block, gefolgt von Allow- oder Disallow-Zeilen. Wichtig für die Steuerung von KI-Crawlern: jeder Anbieter definiert einen eigenen, spezifischen User-Agent-String, den man exakt referenzieren muss, ein genereller User-agent: *-Block erfasst nicht automatisch alle KI-Crawler mit derselben Absicht, wenn zusätzlich spezifische Blöcke existieren.

Robots.txt ist eine freiwillige Konvention, kein technischer Zugriffsschutz. Seriöse KI-Anbieter wie OpenAI, Anthropic und Perplexity respektieren die Datei nachweislich, dokumentieren ihre User-Agents öffentlich und bieten teils sogar granularere Steuerung über HTTP-Header an. Weniger seriöse Scraper, die sich fälschlich als bekannter KI-Crawler ausgeben oder robots.txt schlicht ignorieren, lassen sich über diese Datei nicht aufhalten, dafür braucht es serverseitige Maßnahmen wie IP- oder User-Agent-Filterung auf Infrastrukturebene.

# robots.txt syntax basics for AI crawler control
# Location: https://example.com/robots.txt

# Specific blocks take precedence over generic User-agent: * blocks
User-agent: GPTBot
Disallow: /internal/
Allow: /

User-agent: *
Disallow: /admin/
Allow: /

4. Die wichtigsten KI-Crawler im Detail

GPTBot ist der Trainingscrawler von OpenAI und sammelt Webinhalte für zukünftige Modellversionen. Ein separater User-Agent, OAI-SearchBot, wird für die Echtzeit-Websuche innerhalb von ChatGPT genutzt und sollte bei der Entscheidung getrennt betrachtet werden, da beide unterschiedliche Zwecke erfüllen. Wer bei ChatGPT als Quelle für aktuelle Antworten erscheinen will, aber nicht zwingend Trainingsdaten liefern möchte, kann GPTBot blockieren und OAI-SearchBot zulassen.

ClaudeBot von Anthropic crawlt primär für Trainingszwecke, während für Echtzeit-Websuche innerhalb von Claude andere Mechanismen zum Einsatz kommen, deren User-Agent-Dokumentation sich mit den Produktupdates weiterentwickelt, weshalb es sich lohnt, die offizielle Anthropic-Dokumentation vor der finalen robots.txt-Konfiguration zu konsultieren. PerplexityBot ist überwiegend ein Retrieval-Crawler, der direkt für Nutzeranfragen innerhalb von Perplexity arbeitet, ein Blockieren wirkt sich hier besonders unmittelbar auf die eigene Sichtbarkeit in KI-Antworten aus.

Google-Extended steuert, wie oben beschrieben, ausschließlich die Nutzung für generative KI-Funktionen von Google, getrennt vom klassischen Suchindex. CCBot gehört zum gemeinnützigen Common Crawl-Projekt, dessen Datensätze von zahlreichen KI-Anbietern, auch kleineren und Forschungsinstitutionen, als Trainingsgrundlage genutzt werden. Ein Blockieren von CCBot betrifft daher potenziell mehr Modelle als das Blockieren eines einzelnen kommerziellen KI-Crawlers, weil man den Content aus einer ganzen Kette nachgelagerter Nutzungen ausschließt.

5. Praktische robots.txt-Beispiele für unterschiedliche Strategien

Für Unternehmen, die maximale Sichtbarkeit in KI-Antworten anstreben und den Einsatz für Modelltraining akzeptieren, eignet sich eine offene Konfiguration, die alle bekannten KI-Crawler ausdrücklich zulässt. Diese Strategie passt zu B2B-Anbietern, deren Content-Marketing-Ziel genau darin besteht, in möglichst vielen KI-Antworten zitiert zu werden, und die den Trainingsdaten-Beitrag als akzeptablen Preis für Reichweite betrachten.

Für Unternehmen mit sensiblem oder monetarisiertem Content, etwa Verlage mit Abo-Modell, eignet sich eine differenzierte Strategie: Retrieval-Crawler wie PerplexityBot und OAI-SearchBot zulassen, um in aktuellen KI-Antworten präsent zu bleiben, reine Trainingscrawler wie GPTBot, ClaudeBot und CCBot dagegen blockieren, um die eigenen Inhalte nicht unkompensiert als Trainingsgrundlage bereitzustellen.

# robots.txt: Strategy A, maximum AI visibility, training allowed
User-agent: GPTBot
Allow: /

User-agent: ClaudeBot
Allow: /

User-agent: PerplexityBot
Allow: /

User-agent: Google-Extended
Allow: /

User-agent: CCBot
Allow: /

# ---

# robots.txt: Strategy B, allow real-time retrieval, block training crawlers
User-agent: GPTBot
Disallow: /

User-agent: ClaudeBot
Disallow: /

User-agent: CCBot
Disallow: /

User-agent: Google-Extended
Disallow: /

User-agent: OAI-SearchBot
Allow: /

User-agent: PerplexityBot
Allow: /

6. Sichtbarkeit versus Content-Schutz abwägen

Die Entscheidung zwischen Offenheit und Content-Schutz ist keine rein technische Frage, sondern eine Geschäftsentscheidung mit realen Trade-offs. Wer alle KI-Crawler blockiert, schützt seinen Content maximal vor unkompensierter Weiterverwendung, riskiert aber, dass die eigene Marke bei generativen Antworten in der eigenen Branche schlicht nicht mehr vorkommt, während Wettbewerber, die KI-Crawler zulassen, diesen Sichtbarkeitsraum füllen.

Bei rein informativem Marketing-Content, der ohnehin frei zugänglich ist und dessen Zweck Reichweite und Markenbekanntheit ist, überwiegt in den meisten Fällen der Nutzen der Sichtbarkeit den Schutzgedanken. Bei redaktionellem Premium-Content mit direktem Monetarisierungsmodell, etwa Fachartikel hinter einer Paywall, kann die Abwägung anders ausfallen, insbesondere wenn ein KI-Crawler den Content für Trainingszwecke abgreift, ohne dass daraus Traffic oder Umsatz für den Ersteller entsteht.

Ein Mittelweg, der sich in der Praxis etabliert: Retrieval-Crawler zulassen, weil sie direkten, nachweisbaren Sichtbarkeitswert liefern, reine Trainingscrawler dagegen kritischer prüfen, besonders wenn der Anbieter keine Kompensationsmodelle oder Attribution anbietet. Diese differenzierte KI-Crawler-Steuerung erfordert regelmäßige Pflege, weil neue Anbieter neue User-Agents einführen und bestehende ihre Funktion verändern können.

{
  "crawler_policy_internal_note": "b2b-domain",
  "reviewed": "2026-07-23",
  "decisions": [
    { "agent": "GPTBot", "purpose": "training", "decision": "block", "reason": "no compensation model" },
    { "agent": "OAI-SearchBot", "purpose": "retrieval", "decision": "allow", "reason": "direct citation value" },
    { "agent": "ClaudeBot", "purpose": "training", "decision": "block", "reason": "no compensation model" },
    { "agent": "PerplexityBot", "purpose": "retrieval", "decision": "allow", "reason": "direct citation value" },
    { "agent": "Google-Extended", "purpose": "training", "decision": "block", "reason": "no compensation model" },
    { "agent": "CCBot", "purpose": "training", "decision": "block", "reason": "downstream usage unclear" }
  ]
}

7. llms.txt: ein neuer, ergänzender Standard

Parallel zur robots.txt-Steuerung hat sich ein neuer, noch nicht universell unterstützter Vorschlag namens llms.txt etabliert. Die Idee: eine Markdown-Datei im Root-Verzeichnis, die Sprachmodellen und KI-Assistenten eine kuratierte, kompakte Übersicht der wichtigsten Seiten und Informationen einer Domain liefert, ähnlich einer für Sprachmodelle optimierten Sitemap. Anders als robots.txt steuert llms.txt keinen Zugriff, sondern liefert zusätzlichen Kontext und priorisiert relevante Inhalte.

Der praktische Nutzen von llms.txt ist Stand heute begrenzt, weil noch nicht alle großen KI-Anbieter die Datei systematisch auswerten, dennoch kostet die Erstellung wenig Aufwand und schadet nicht. Für Domains mit umfangreicher, komplexer Struktur kann llms.txt helfen, Sprachmodellen die wichtigsten Fachseiten direkt zu benennen, statt auf eine vollständige Crawling-Analyse der gesamten Seitenstruktur angewiesen zu sein.

# llms.txt: placed at https://example.com/llms.txt
# Markdown format, curated overview for AI assistants

# Beispielfirma

> B2B-Anbieter fuer Integrationsloesungen mit Fokus auf API-first-Architektur.

## Kernseiten

- [Produktuebersicht](https://example.com/produkte): Alle Kernprodukte im Vergleich
- [Technische Dokumentation](https://example.com/docs): Vollstaendige API-Referenz
- [Preismodelle](https://example.com/preise): Aktuelle Tarife und Konditionen

## Wissensbasis

- [Integrationsleitfaden](https://example.com/wissen/integration): Schritt-fuer-Schritt-Anleitung
- [FAQ](https://example.com/faq): Haeufige technische und vertragliche Fragen

8. Crawler-Zugriffe prüfen und verifizieren

Eine robots.txt-Regel zu setzen reicht nicht aus, ohne zu prüfen, ob sie tatsächlich wirkt. Serverlogs zeigen, welche User-Agents die eigene Domain tatsächlich besuchen, und ein Abgleich mit der robots.txt-Konfiguration deckt auf, ob geblockte KI-Crawler die Regel respektieren oder nicht. Zusätzlich lohnt sich eine Prüfung auf gefälschte User-Agents: manche Scraper geben sich als bekannter KI-Crawler aus, ohne die zugehörige IP-Range zu nutzen, ein Hinweis darauf, dass robots.txt allein nicht als Schutzmaßnahme ausreicht.

Anbieter wie OpenAI, Anthropic und Perplexity veröffentlichen öffentliche IP-Ranges oder Reverse-DNS-Verifikationsmethoden für ihre offiziellen KI-Crawler. Eine Kombination aus User-Agent-Prüfung und IP-Verifikation liefert deutlich verlässlichere Daten darüber, wer tatsächlich crawlt, als sich allein auf den gemeldeten User-Agent-String zu verlassen.

#!/usr/bin/env bash
# verify-ai-crawlers.sh: cross-check logged AI user agents against
# access log entries and flag suspicious hits for manual review

set -euo pipefail

readonly ACCESS_LOG="/var/log/nginx/access.log"
readonly KNOWN_AGENTS=("GPTBot" "ClaudeBot" "PerplexityBot" "CCBot" "Google-Extended")

for agent in "${KNOWN_AGENTS[@]}"; do
  count=$(grep -c "$agent" "$ACCESS_LOG" || true)
  echo "[$agent] requests logged: $count"
done

echo "---"
echo "Reminder: cross-check source IPs against each provider's published"
echo "IP ranges before trusting the User-Agent string alone."

9. Grenzen von robots.txt als Steuerungsinstrument

Robots.txt bleibt eine freiwillige Konvention. Sie steuert zuverlässig das Verhalten seriöser, dokumentierter KI-Crawler großer Anbieter, hat aber keine technische Durchsetzungskraft gegen Akteure, die die Datei ignorieren. Wer Content wirklich vor jeder Form des Abrufs schützen will, braucht zusätzliche Maßnahmen: Rate-Limiting, IP-Blocklisten, Zugriffsschutz für sensible Bereiche oder rechtliche Nutzungsbedingungen, die zumindest eine Grundlage für spätere Ansprüche schaffen.

Zudem ändert sich die Landschaft der KI-Crawler schnell. Neue Anbieter, neue User-Agents und veränderte Crawling-Strategien bestehender Anbieter erfordern eine regelmäßige Überprüfung der eigenen robots.txt-Konfiguration, mindestens quartalsweise, idealerweise gekoppelt an eine Beobachtung der offiziellen Dokumentation der wichtigsten KI-Anbieter. Eine einmal gesetzte Konfiguration veraltet in diesem sich schnell entwickelnden Umfeld innerhalb weniger Monate.

10. Zusammenfassung

KI-Crawler lassen sich nicht sinnvoll mit einer pauschalen Blockade oder Freigabe steuern. GPTBot, ClaudeBot und CCBot dienen primär dem Modelltraining, PerplexityBot und OAI-SearchBot dem Echtzeit-Retrieval für aktuelle KI-Antworten, Google-Extended steuert speziell die Nutzung für Googles generative Funktionen getrennt vom klassischen Suchindex. Eine differenzierte robots.txt-Konfiguration erlaubt es, gezielt zwischen Trainingsdaten-Beitrag und Echtzeit-Sichtbarkeit zu unterscheiden, statt beides gleichzeitig zu gewähren oder zu verweigern.

Die Entscheidung, welche KI-Crawler zugelassen werden, bleibt eine strategische Abwägung zwischen Reichweite und Content-Schutz, die je nach Geschäftsmodell unterschiedlich ausfällt. llms.txt ergänzt robots.txt um eine kuratierte Kontextebene für Sprachmodelle, ersetzt aber keine Zugriffssteuerung. Regelmäßige Prüfung der Serverlogs und Anpassung an neue KI-Crawler bleibt notwendig, weil die Landschaft sich kontinuierlich weiterentwickelt.

11. FAQ: KI-Crawler und robots.txt-Steuerung