robots.txt für KI-Crawler: Was sie steuert und wo die Grenze liegt

Wer robots.txt für ein Steuerungsinstrument der KI-Sichtbarkeit hält, überschätzt eine Datei, die ausschließlich Abrufe regelt.

Definition: robots.txt ist eine Textdatei im Stammverzeichnis einer Domain. Darin legen Betreiber nach dem Robots Exclusion Protocol (RFC 9309, 2022) fest, welche Crawler welche Pfade abrufen sollen. Bei KI-Crawlern wie GPTBot, ClaudeBot oder PerplexityBot bestimmt sie damit den Abruf durch kooperative Bots. Sie ist weder ein Zugriffsschutz noch eine Steuerung der KI-Suche insgesamt.

Was robots.txt bei KI-Crawlern leistet

Der IETF-Standard RFC 9309 vom September 2022 ist eindeutig: Laut RFC Editor sind die Regeln “not a form of access authorization”, und das Protokoll ist “not a substitute for valid content security measures” (https://www.rfc-editor.org/rfc/rfc9309.html). Vor 2022 war robots.txt seit 1994 eine informelle, weithin befolgte Konvention. Der Standard hat daran nichts verändert, was die Durchsetzung angeht: Ein Bot hält sich daran, weil er will.

Auch für die klassische Suche gilt diese Grenze. Laut Google Search Central ist robots.txt kein Mechanismus, um eine Seite aus Google herauszuhalten. Dafür dienen noindex oder Passwortschutz, und eine per robots.txt gesperrte Seite kann trotzdem indexiert werden, wenn andere Seiten auf sie verlinken (https://developers.google.com/search/docs/crawling-indexing/robots/intro).

Aus beiden Aussagen folgt für die KI-Suche eine Einordnung: Die Datei sagt einem kooperativen Bot, was er abrufen soll. Was andere Seiten über dich schreiben und welche Informationen ein Modell bereits kennt, liegt außerhalb ihrer Reichweite.

Vier Anbieter, getrennte Bots für getrennte Zwecke

Die Anbieter haben ihre Crawler nach Verwendungszweck aufgeteilt. Das macht die Datei brauchbar, verlangt aber, dass du die Namen kennst.

OpenAI unterscheidet laut eigener Dokumentation mehrere Bots mit getrennten Aufgaben: OAI-SearchBot für die ChatGPT-Suche, GPTBot für das Training und ChatGPT-User für nutzerausgelöste Aufrufe. Die Einstellungen sind unabhängig voneinander, du kannst also die Suche erlauben und das Training sperren. Eine robots.txt-Änderung braucht für die Suche etwa 24 Stunden, und bei ChatGPT-User greifen robots.txt-Regeln laut OpenAI womöglich gar nicht (https://developers.openai.com/api/docs/bots).

Anthropic nennt mehrere Bots mit getrennten Zwecken: ClaudeBot für das Training, Claude-User für Abrufe auf Nutzeranfrage und Claude-SearchBot für die Suchqualität. Laut Anthropic gilt die Sperre je Subdomain, und Crawl-delay wird als nicht standardisierte Erweiterung unterstützt (https://support.claude.com/en/articles/8896518-does-anthropic-crawl-data-from-the-web-and-how-can-site-owners-block-the-crawler).

Perplexity trennt PerplexityBot, der Inhalte in die Suchergebnisse aufnimmt und nicht für das Training von Basismodellen gedacht ist, von Perplexity-User für nutzerausgelöste Abrufe. Laut Perplexity-Dokumentation ignoriert der Perplexity-User-Abruf robots.txt-Regeln in der Regel, weil ein Nutzer ihn auslöst (https://docs.perplexity.ai/guides/bots).

Bei Google gibt es den Sonderfall Google-Extended: Laut Google Search Central ist er ein reiner robots.txt-Token ohne eigenen User-Agent-String. Er steuert, ob gecrawlte Inhalte für Gemini genutzt werden, und beeinflusst weder die Aufnahme in die Google-Suche noch das Ranking (https://developers.google.com/search/docs/crawling-indexing/google-common-crawlers). Hier betrifft eine robots.txt-Zeile ausdrücklich die Verwendung der Inhalte und nicht nur den Abruf.

Drei Ansätze im Vergleich: erlauben, trennen, sperren

Ansatz	Vorteil	Nachteil
A: Alles erlauben	Kein Pflegeaufwand, alle Abrufwege bleiben offen	Auch Trainings-Crawler wie GPTBot oder ClaudeBot rufen Inhalte ab
B: Nach Zweck trennen	Entspricht der Aufteilung der Anbieter: Suche offen, Training gesperrt	Pflege je Anbieter und Subdomain, nutzerausgelöste Abrufe bleiben unberührt
C: Alle KI-Bots sperren	Eine einfache Regel, klare Haltung	Schließt auch die Suchbots der Anbieter aus, schützt nicht vor nutzerausgelösten Abrufen

Eine Schwäche von Ansatz A ist, dass du keine Entscheidung über das Training triffst. Bei C kommt hinzu, dass du die Aufnahme in KI-Suchergebnisse bewusst aufgibst, sofern der jeweilige Bot sich an die Regel hält.

Ansatz B sieht in der Datei so aus:

User-agent: OAI-SearchBot
Allow: /

User-agent: PerplexityBot
Allow: /

User-agent: GPTBot
Disallow: /

User-agent: ClaudeBot
Disallow: /

User-agent: CCBot
Disallow: /

Ein Rechenbeispiel (hypothetisch): Liegen Shop, Blog und Dokumentation auf drei Subdomains, wären in diesem Modell drei robots.txt-Dateien zu pflegen, und eine Sperre auf der Hauptdomain würde die beiden anderen Subdomains nach Anthropics Angabe nicht abdecken.

llms.txt: Orientierungshilfe ohne Durchsetzung

llms.txt ist ein freiwilliges Format, das Inhalte für Modelle ordnen soll. Ob und wie stark GPTBot, PerplexityBot, ClaudeBot und andere die Datei auswerten, ist öffentlich nicht einheitlich dokumentiert. Eine Wirkung auf Zitierungen leiten wir daraus nicht ab.

Beide Dateien haben verschiedene Aufgaben. robots.txt formuliert Verbote und Erlaubnisse für den Abruf, llms.txt will Inhalte für Modelle ordnen. Eine Anleitung zum Aufbau findest du in unserem Beitrag llms.txt: So optimierst du deine Website für KI-Crawler. Als Ersatz für eine saubere robots.txt taugt sie nicht, weil sie keine Sperre ausdrückt.

Empfehlung: nach Zweck trennen und erst dann Logs lesen

Wir empfehlen Ansatz B. Aus unserer Sicht zählt zuerst die Frage, welchen Zweck du zulassen willst, weil die Anbieter ihre Bots selbst nach Zweck aufteilen und du deine Regeln an dieser Aufteilung ausrichten kannst. Wer nur Namen sammelt, pflegt eine Liste, die sich mit jeder Anbieterdokumentation ändern kann.

Danach gehört die Wirkung auf den Prüfstand, denn eine Zeile in der Datei beweist nicht, dass sich ein Bot daran hält. Wie du GPTBot und Co. im Server-Log erkennst, beschreibt Log File Analyse: So erkennst du KI-Crawler wie GPTBot im Server-Log. Ob dein CDN oder deine Firewall eigene Bot-Regeln setzt, prüfst du getrennt von der robots.txt, wie wir in Cloudflare blockiert KI-Bots beschreiben.

Inhalte, die nicht abrufbar sein sollen, gehören hinter Authentifizierung. Das folgt aus dem Wortlaut des RFC 9309. Für GEO und SEO gilt damit dieselbe Arbeitsteilung: robots.txt formuliert den Wunsch an kooperative Bots, den Zugriffsschutz setzt der Server durch. Eine Sperre in der Datei ersetzt das nicht.

Häufig gestellte Fragen

Verhindert robots.txt, dass KI-Systeme meine Inhalte nutzen? Nein. Sie regelt nach RFC 9309 den Abruf durch Crawler, die sich daran halten, und ist laut Standard keine Zugriffsautorisierung. Nutzerausgelöste Abrufe wie ChatGPT-User oder Perplexity-User folgen den Regeln laut OpenAI und Perplexity womöglich oder in der Regel nicht.

Kann ich die KI-Suche erlauben und das Training sperren? Bei OpenAI ja: Laut Dokumentation sind OAI-SearchBot und GPTBot unabhängig einstellbar. Anthropic führt mit ClaudeBot, Claude-User und Claude-SearchBot ebenfalls getrennte Bots mit unterschiedlichen Zwecken.

Brauche ich eine llms.txt, wenn meine robots.txt sauber ist? Das ist nicht belegt. llms.txt ist ein freiwilliges Format, und die Auswertung durch einzelne Crawler ist nicht einheitlich dokumentiert. Sie kann als Ergänzung dienen, ersetzt aber keine Zugriffskontrolle.

Wie schnell greift eine Änderung an der robots.txt? Laut OpenAI dauert es für die ChatGPT-Suche etwa 24 Stunden. Für andere Anbieter haben wir keine veröffentlichte Angabe, deshalb prüfst du die Wirkung im Server-Log.