robots.txt & llms.txt für KI-Crawler

Wer in ChatGPT, Perplexity oder den Google AI Overviews als Quelle auftauchen möchte, muss den richtigen KI-Crawlern Zugang gewähren – und die falschen gezielt steuern. Das entscheidet sich an wenigen technischen Stellen: robots.txt, llms.txt, HTTP-Header, CDN-Konfiguration und die Frage, ob Ihre Inhalte überhaupt im ausgelieferten HTML stehen. Dieser Leitfaden führt Sie durch die Konfiguration, die für Ihre KI-Sichtbarkeit den Unterschied macht.

Die wichtigste Unterscheidung vorweg: Training-Crawler und Retrieval-Crawler sind nicht dasselbe. Wer pauschal alle KI-Bots blockiert, sperrt oft genau die aus, die für Zitate in KI-Antworten sorgen.

Training-Crawler vs. Retrieval-Crawler: der entscheidende Unterschied

KI-Anbieter setzen unterschiedliche Bots für unterschiedliche Zwecke ein. Diese Unterscheidung ist die Grundlage jeder sinnvollen Konfiguration:

• Training-Crawler sammeln Inhalte für das Training künftiger Modelle. Sie beeinflussen nicht, ob Sie heute in einer Antwort zitiert werden. Beispiele: GPTBot (OpenAI), Google-Extended (Gemini-Training), ClaudeBot (Anthropic), CCBot (Common Crawl), Applebot-Extended.
• Retrieval-Crawler rufen Ihre Seite live ab, wenn ein Nutzer eine Frage stellt, und liefern die Grundlage für die zitierte Antwort. Beispiele: ChatGPT-User und OAI-SearchBot (OpenAI), PerplexityBot (Perplexity).

Daraus folgt die zentrale Regel: Wenn Sie in KI-Antworten sichtbar sein wollen, sollten Sie die Retrieval-Crawler unbedingt erlauben. Ob Sie Training-Crawler zulassen, ist eine strategische und teils urheberrechtliche Entscheidung, die Ihre aktuelle Zitierbarkeit aber nicht direkt betrifft.

Übersicht relevanter KI-Crawler

robots.txt richtig konfigurieren

Die robots.txt liegt im Stammverzeichnis Ihrer Domain (https://www.ihre-domain.de/robots.txt) und teilt Crawlern mit, welche Bereiche sie abrufen dürfen. Sie ist eine Richtlinie, die seriöse Anbieter respektieren – kein technischer Zwang.

Grundsyntax

User-agent: GPTBot
Disallow: /

User-agent: ChatGPT-User
Allow: /

• User-agent benennt den Crawler exakt (Groß- und Kleinschreibung beachten) oder * für alle.
• Disallow sperrt Pfade, Allow hebt eine Sperre für Unterpfade auf.
• Der erste passende User-agent-Block gilt; ohne Disallow ist standardmäßig alles erlaubt.

Empfohlene Ausgangskonfiguration für KI-Sichtbarkeit

Wer zitiert werden möchte, erlaubt Such- und Retrieval-Bots und entscheidet über Training-Bots bewusst:

# Retrieval / Antworten – erlauben
User-agent: OAI-SearchBot
Allow: /

User-agent: ChatGPT-User
Allow: /

User-agent: PerplexityBot
Allow: /

# Training – hier bewusst entscheiden (Beispiel: erlauben)
User-agent: GPTBot
Allow: /

User-agent: Google-Extended
Allow: /

Wichtig: Sperren Sie niemals versehentlich Googlebot oder Bingbot, denn deren Index speist auch die AI Overviews und Copilot. Ein pauschales User-agent: * / Disallow: / für sensible Verzeichnisse ist in Ordnung, sollte aber öffentliche, zitierwürdige Inhalte nicht mit erfassen.

Häufige Fehler in der robots.txt

Kleine Konfigurationsfehler haben große Wirkung, weil sie Zugriffe still unterbinden. Achten Sie besonders auf diese Punkte:

• Falscher Speicherort: Die Datei muss im Stammverzeichnis liegen und mit Statuscode 200 erreichbar sein, nicht in einem Unterordner.
• Abweichende Schreibweise der User-Agents: Verwenden Sie exakt die offizielle Bezeichnung, sonst greift die Regel nicht.
• Versehentliches Aussperren von Such-Bots wie Googlebot oder Bingbot, deren Index auch KI-Antworten speist.
• Blockierte Ressourcen wie CSS oder für den Inhalt nötige Dateien, die das Verständnis der Seite beeinträchtigen.
• Widerspruch zur Realität: Eine Disallow-Regel verhindert das Crawling, nicht zwingend das Erscheinen einer bereits bekannten URL – für verlässliches Ausschließen aus Ergebnissen ist noindex das richtige Mittel.

Testen Sie Änderungen vor dem Livegang und prüfen Sie anschließend in den Logs, ob die gewünschten Crawler weiterhin Zugriff haben.

llms.txt: Content-Landkarte, kein Türsteher

Die llms.txt wird häufig mit der robots.txt verwechselt, erfüllt aber einen völlig anderen Zweck. Es handelt sich um eine vorgeschlagene Markdown-Datei im Stammverzeichnis, die KI-Systemen eine kuratierte Übersicht Ihrer wichtigsten Inhalte anbietet. Sie ist ein Angebot zur besseren Auffindbarkeit und Einordnung, kein Zugriffs- oder Sperrmechanismus.

Eine llms.txt ist in einfachem Markdown aufgebaut:

# Musterfirma München

> Kurzbeschreibung des Unternehmens und der wichtigsten Angebote in ein bis zwei Sätzen.

## Kernseiten
- [Leistungen](https://www.example.de/leistungen/): Überblick der Angebote
- [Über uns](https://www.example.de/ueber-uns/): Team und Standort München

## Ratgeber
- [GEO-Grundlagen](https://www.example.de/blog/geo/): Einführung in die KI-Suche

Ergänzend kann eine llms-full.txt ausführlichere Inhalte bündeln. Da der Standard sich noch entwickelt und nicht von allen Anbietern ausgewertet wird, gilt: llms.txt ergänzt eine saubere Website-Struktur, ersetzt sie aber nicht. Wie diese Struktur aussieht, behandeln wir im Beitrag zu technischer GEO, Schema und Seitenarchitektur.

HTTP-Header für KI-Crawler

Während robots.txt und llms.txt den Zugang regeln, steuern HTTP-Header, wie Ihre Inhalte verarbeitet und wie aktuell sie eingeschätzt werden.

X-Robots-Tag

Der X-Robots-Tag steuert die Verarbeitung auf HTTP-Ebene – auch für Nicht-HTML-Dateien. Relevante Direktiven:

• index, follow – Inhalt darf verwendet und Links gefolgt werden.
• max-snippet:-1 – keine Längenbegrenzung für übernommene Textausschnitte.
• max-image-preview:large – große Bildvorschau erlaubt.

Cache-Control, Last-Modified und ETag

KI-Systeme bevorzugen aktuelle Informationen. Freshness-Signale helfen ihnen, die richtige Crawl-Frequenz zu wählen und Ihre Seite bei zeitkritischen Anfragen zu berücksichtigen:

• Cache-Control signalisiert, wie oft sich Inhalte ändern (etwa public, max-age=3600 für häufig aktualisierte Seiten).
• Last-Modified und ETag ermöglichen bedingte Anfragen: Der Crawler lädt nur neu, wenn sich wirklich etwas geändert hat – das schont Ihre Ressourcen und macht das Crawling effizienter.

Content-Type korrekt setzen

Ein häufiger Fehler mit großer Wirkung: Geben Sie den Zeichensatz immer mit an.

• Falsch: Content-Type: text/html
• Richtig: Content-Type: text/html; charset=utf-8

Rate-Limiting sauber signalisieren

Wenn Sie die Zugriffsfrequenz begrenzen müssen, antworten Sie mit dem Statuscode 429 oder 503 und einem Retry-After-Header, statt Anfragen kommentarlos zu verwerfen. So bleibt der Crawler kooperativ und kehrt kontrolliert zurück.

CDN und WAF: die häufigste unsichtbare Blockade

Viele Websites sperren KI-Crawler unbeabsichtigt – nicht in der robots.txt, sondern in der Firewall oder im CDN. Aggressive Bot-Management-Regeln oder ein pauschaler "KI-Bots blockieren"-Schalter im CDN können genau die Retrieval-Crawler aussperren, die Sie zitieren sollen.

Empfehlungen:

• Legitime KI-User-Agents in der WAF freigeben, statt sie im Bot-Schutz mitzublockieren.
• Echtheit verifizieren über die von den Anbietern veröffentlichten IP-Bereiche oder Reverse-DNS, da User-Agents gefälscht werden können.
• Edge-Caching und Kompression nutzen, um konsistent schnelle Antworten und stabile 200-Statuscodes auszuliefern.
• Rate-Limiting maßvoll einstellen, damit legitime Crawler nicht fälschlich gedrosselt werden.

JavaScript-Rendering: der stille Sichtbarkeitskiller

Der wohl folgenreichste technische Punkt: Die meisten KI-Crawler führen kein oder nur eingeschränkt JavaScript aus. Anders als der Googlebot, der Seiten rendert, werten Bots wie GPTBot, PerplexityBot oder ClaudeBot in der Regel nur das initial ausgelieferte HTML aus.

Für Websites, die Inhalte clientseitig nachladen (klassische Single-Page-Apps), bedeutet das: Der eigentliche Content ist für diese Crawler unsichtbar. Die Lösung liegt im Rendering-Ansatz:

• Server-Side-Rendering (SSR) oder Static-Site-Generation (SSG) liefern den Inhalt direkt im HTML.
• Prerendering kann für bestehende SPAs eine Übergangslösung sein.
• Prüfen Sie im Zweifel den Quelltext (nicht das gerenderte DOM): Steht Ihr Kerninhalt bereits dort, sehen ihn auch KI-Crawler.

Log-Analyse: sehen, wer wirklich crawlt

Ob Ihre Konfiguration wirkt, zeigen die Server-Logs – nicht das Bauchgefühl. Sie sind die einzige verlässliche Quelle für tatsächliche Crawler-Zugriffe.

• Nach User-Agents filtern wie GPTBot, ChatGPT-User, OAI-SearchBot, PerplexityBot, ClaudeBot.
• Statuscodes prüfen: Liefern diese Zugriffe 200, oder blocken 403/429 sie unbeabsichtigt?
• Echtheit gegen die offiziellen IP-Bereiche abgleichen.
• Werkzeuge wie Log-File-Analyzer, GoAccess oder ein ELK-Stack helfen bei größeren Datenmengen; auf CDN-Ebene liefern die Analytics von Cloudflare & Co. einen schnellen Überblick.

KI-Traffic in Analytics richtig einordnen

Ein verbreitetes Missverständnis: KI-Crawler tauchen kaum in Google Analytics 4 auf. Der Grund ist derselbe wie beim Rendering – GA4 basiert auf JavaScript, das diese Bots nicht ausführen. Crawler-Aktivität gehört deshalb in die Server-Logs, nicht in GA4.

Was Sie in GA4 dagegen sehen, ist der Referral-Traffic von Menschen, die aus einer KI-Antwort auf Ihre Seite klicken – etwa von chatgpt.com, perplexity.ai oder gemini.google.com. Richten Sie dafür eine Erkennung dieser Quellen ein (etwa über eine Referral-Segmentierung), um den Wertbeitrag Ihrer KI-Sichtbarkeit zu messen. Welche Kennzahlen darüber hinaus zählen, zeigt unser Beitrag zu den wichtigsten KPIs für Ihre GEO-Strategie.

Crawler verifizieren statt blind vertrauen

User-Agent-Strings lassen sich fälschen. Wer wichtige Entscheidungen an einen Bot knüpft – etwa erweiterten Zugriff oder Sonderbehandlung im Cache – sollte dessen Echtheit prüfen. Seriöse Anbieter veröffentlichen dafür die IP-Bereiche ihrer Crawler oder erlauben eine Verifikation per Reverse-DNS-Lookup mit anschließender Vorwärtsauflösung.

Praktisch bedeutet das: Ein Zugriff, der sich als GPTBot oder PerplexityBot ausgibt, aber aus einem nicht dokumentierten IP-Bereich stammt, ist mit Vorsicht zu behandeln. So verhindern Sie, dass sich unerwünschte Scraper hinter den Namen bekannter KI-Crawler verstecken und Ihre Freigaben ausnutzen.

Mobile Ladezeit und User Experience

KI-Crawler und die Nutzer, die über KI-Antworten auf Ihre Seite gelangen, teilen eine Erwartung: schnelle, mobil nutzbare Seiten. Eine niedrige Time-to-First-Byte verbessert die Effizienz, mit der Crawler Ihre Seiten abarbeiten, und eine gute mobile Darstellung senkt die Absprungrate der Besucher, die aus einer Antwort kommen.

Konkret zahlen sich diese Maßnahmen doppelt aus – für Crawling und für Conversion:

• Schnelle Server-Antwort durch Caching, Kompression und ein performantes CDN.
• Optimierte Assets (Bilder, Schriften, Skripte), damit die sichtbaren Inhalte früh bereitstehen.
• Mobile-first-Layout, da ein Großteil der Zugriffe von mobilen Geräten kommt.

Da diese Nutzer bereits eine konkrete Antwort erhalten haben, sind sie oft hoch qualifiziert. Eine langsame oder unübersichtliche Seite verspielt genau diesen Vorteil.

Zusammenspiel mit Content und Ladezeit

Technische Freigaben sind die Eintrittskarte, nicht die Garantie für Zitate. Ein KI-Crawler muss nicht nur zugreifen dürfen, er muss auch schnell bedient werden und verwertbaren Inhalt vorfinden. Eine niedrige Server-Antwortzeit und mobile-first optimierte Seiten verbessern die Crawl-Effizienz; klar strukturierter, extrahierbarer Text sorgt dafür, dass der Zugriff sich in Sichtbarkeit übersetzt. Wie Sie Inhalte dafür aufbereiten, lesen Sie unter Content für generative KI schreiben, und wie KI-Systeme daraus Antworten formen, erklärt der Beitrag dazu, wie KI-Suchergebnisse generiert werden.

Häufige Fragen

Sollte ich GPTBot blockieren oder erlauben?

GPTBot ist ein Training-Crawler und beeinflusst nicht direkt, ob Sie heute in ChatGPT zitiert werden – das leisten ChatGPT-User und OAI-SearchBot. Ob Sie GPTBot zulassen, ist eine strategische Entscheidung: erlauben Sie ihn, fließen Ihre Inhalte potenziell ins Modelltraining ein; sperren Sie ihn, bleibt Ihre aktuelle Zitierbarkeit über die Retrieval-Bots erhalten.

Was ist der Unterschied zwischen robots.txt und llms.txt?

Die robots.txt steuert den Zugriff von Crawlern und wird von seriösen Anbietern respektiert. Die llms.txt ist dagegen eine kuratierte Markdown-Landkarte Ihrer wichtigsten Inhalte, die KI-Systemen die Orientierung erleichtert. Sie regelt keinen Zugriff und ersetzt die robots.txt nicht.

Warum sehen KI-Crawler meine Inhalte nicht, obwohl nichts blockiert ist?

Sehr wahrscheinlich liegt es am JavaScript-Rendering. Führt Ihre Seite den Inhalt erst clientseitig zusammen, bleibt er für Crawler unsichtbar, die kein JavaScript ausführen. Prüfen Sie, ob der Kerninhalt bereits im initial ausgelieferten HTML steht, und setzen Sie auf Server-Side-Rendering oder statische Generierung.

Kann ich KI-Crawler über die robots.txt zuverlässig aussperren?

Die robots.txt ist eine Richtlinie, keine technische Sperre. Reputable Anbieter halten sich daran, weniger seriöse Bots ignorieren sie möglicherweise. Für verbindlichen Schutz kombinieren Sie sie mit Maßnahmen auf Server- oder CDN-Ebene wie User-Agent- oder IP-basierten Regeln.

Tauchen KI-Bots in Google Analytics auf?

In der Regel nicht. GA4 misst über JavaScript, das KI-Crawler nicht ausführen. Deren Zugriffe finden Sie in den Server-Logs. In GA4 sichtbar wird nur der Referral-Traffic von Nutzern, die aus einer KI-Antwort auf Ihre Seite klicken.

Welche HTTP-Header sind für KI-Crawler am wichtigsten?

Zentral sind der X-Robots-Tag zur Steuerung der Verarbeitung, Cache-Control sowie Last-Modified/ETag als Freshness- und Effizienzsignale und ein korrekter Content-Type mit charset=utf-8. Bei Rate-Limiting sollten Sie mit 429/503 und Retry-After antworten.

Sperre ich mit einer CDN-Firewall versehentlich KI-Crawler aus?

Das ist ein häufiger Fehler. Aggressives Bot-Management oder pauschale "KI-Bots blockieren"-Optionen im CDN können Retrieval-Crawler aussperren. Geben Sie legitime KI-User-Agents gezielt frei und verifizieren Sie deren Echtheit über die offiziellen IP-Bereiche.