Wie richten Sie robots.txt für KI-Crawler ein?

„Soll ich KI-Crawler blockieren?“ lässt sich nicht pauschal beantworten, denn es ist nicht eine Frage. Jedes große KI-Unternehmen betreibt getrennte Crawler für getrennte Aufgaben: Trainings-Crawler füttern die Korpora der Modelle, Crawler für den Suchindex speisen die Antworten, in denen Sie zitiert werden, und Abruf-Crawler auf Nutzeranfrage lesen eine Seite, weil jemand den Assistenten gerade danach gefragt hat. Wer alle mit einer Zeile sperrt, entscheidet nicht über KI-Training, sondern nimmt sich aus den KI-Antworten heraus.

Die Kosten sind ungleich verteilt. Einen Trainings-Crawler zu blockieren ist eine Grundsatzentscheidung, die in den meisten Fällen keinen Preis bei der Sichtbarkeit hat: Google und Apple dokumentieren das ausdrücklich, und bei OpenAI und Anthropic folgt es aus der Trennung der Crawler, denn die Suche läuft über eigene Crawler mit eigens dokumentierten Folgen. Einen Crawler für die Suche oder für Abrufe auf Nutzeranfrage zu blockieren hat dagegen einen direkten, dokumentierten Preis: OpenAI erklärt etwa, dass Websites, die OAI-SearchBot aussperren, „nicht in den Suchantworten von ChatGPT angezeigt werden“. Wie es bei den einzelnen Assistenten funktioniert, behandeln unsere Leitfäden dazu, wie Sie von ChatGPT, Claude und Perplexity zitiert werden; diese Seite ist die vollständige Übersicht.

Zwei Zahlen zeigen, worum es bei diesem Tausch geht. Cloudflare hat gemessen, wie viele Seiten KI-Unternehmen für jeden Besuch crawlen, den sie im Gegenzug zurückschicken: Laut Cloudflare-Radar-Daten für Juni 2025 waren es bei OpenAI rund 1.700 Crawls pro vermitteltem Besuch und bei Anthropic etwa 70.900. Die Verhältnisse sind seither gesunken (das AI-Insights-Dashboard von Cloudflare verfolgt sie live), aber die Grundlogik ist klar: Sie tauschen intensives Crawling gegen Zitate. In der Tabelle unten legen Sie die Bedingungen fest.

Jede Zeile unten ist gegen die Dokumentation des jeweiligen Betreibers geprüft, Stand August 2026. „Token“ bedeutet: Der Name funktioniert nur als robots.txt-Gruppe; einen eigenen Crawler mit diesem User-Agent gibt es nicht.

Aus der Tabelle ergeben sich drei brauchbare Konfigurationen.

Konfiguration 1 – Sichtbarkeit zuerst. Alles ausdrücklich erlauben: eine eigene Allow-Gruppe für jeden dokumentierten Crawler aus der Tabelle (alle außer Bytespider; ein Allow für einen Crawler, der die Datei ignoriert, bringt nichts), dazu eine Sammelregel für alle übrigen. Das passt zu Websites, die davon leben, gefunden und zitiert zu werden: Verlage und Inhaltsanbieter, Agenturen, die meisten B2B-Anbieter. So betreiben wir unsere eigene Datei; siehe „So betreiben wir unsere eigene Datei“ unten.

User-agent: GPTBot
Allow: /

User-agent: OAI-SearchBot
Allow: /

User-agent: ClaudeBot
Allow: /

…und so weiter für jeden Crawler aus der Tabelle. Unsere Produktionsdatei unter get-geo.ai/robots.txt ist die Vollversion.

Konfiguration 2 – kein Training. Die häufigste bewusste Wahl: nicht in die Korpora der Modelle, aber in die Antworten. Sperren Sie die Trainings-Crawler und -Tokens und erlauben Sie den Rest. Zwei Einschränkungen, bevor Sie die Regeln übernehmen: Die Zeile für Bytespider ist nur deklarativ (der nächste Abschnitt erklärt, warum), und die Sperre von Meta-ExternalAgent ist der einzige Ausstieg aus dem Training mit einem Preis bei der Sichtbarkeit: Sie verlassen damit auch den Index von Meta:

User-agent: GPTBot
Disallow: /

User-agent: ClaudeBot
Disallow: /

User-agent: Google-Extended
Disallow: /

User-agent: Applebot-Extended
Disallow: /

User-agent: Meta-ExternalAgent
Disallow: /

User-agent: CCBot
Disallow: /

User-agent: Amazonbot
Disallow: /

User-agent: Bytespider
Disallow: /

User-agent: *
Allow: /

Konfiguration 3 – Komplettsperre. Legitim für Inhalte hinter einer Paywall oder proprietäre Inhalte. In einer robots.txt können sich mehrere User-agent-Zeilen einen Regelblock teilen, das Ganze bleibt also kompakt. Applebot lassen wir hier weg, weil seine Sperre Sie auch aus der Suche von Siri und Spotlight entfernt, und das ist eine größere Entscheidung als KI-Antworten:

User-agent: GPTBot

User-agent: OAI-SearchBot

User-agent: ChatGPT-User

User-agent: ClaudeBot

User-agent: Claude-SearchBot

User-agent: Claude-User

User-agent: PerplexityBot

User-agent: Perplexity-User

User-agent: Google-Extended

User-agent: Applebot-Extended

User-agent: Meta-ExternalAgent

User-agent: Meta-ExternalFetcher

User-agent: CCBot

User-agent: Amazonbot

User-agent: Amzn-SearchBot

User-agent: Amzn-User

User-agent: DuckAssistBot

User-agent: Bytespider
Disallow: /

Lesen Sie den nächsten Abschnitt, bevor Sie das einsetzen: Bei mehreren der Crawler oben ist die Datei eine Bitte, keine Schranke.

Robots.txt ist eine veröffentlichte Richtlinie, kein Mechanismus zur Durchsetzung, und bei einer ganzen Klasse von Crawlern sagen das die Anbieter selbst. OpenAI zu ChatGPT-User: „Da diese Aktionen von einem Nutzer ausgelöst werden, gelten robots.txt-Regeln möglicherweise nicht.“ Meta zu Meta-ExternalFetcher: Er „kann robots.txt umgehen, weil er Abrufe ausführt, die der Nutzer angefordert hat“. Der Abruf-Crawler Perplexity-User „ignoriert robots.txt-Regeln in der Regel“. Amazon zu Amzn-User: Er „befolgt möglicherweise nicht alle robots.txt-Direktiven“. Die Logik ist einheitlich: Ein Mensch hat gefragt, also gilt der Abruf als Besuch dieses Menschen, nicht als Crawl.

Dann gibt es Bytespider, zu dem es gar keine Dokumentation gibt und der die Datei in der gemessenen Praxis ignoriert: Cloudflare stellte fest, dass er mehr geschützte Websites ansteuert als jeder andere KI-Crawler (40,4 % Mitte 2024), und HAProxy maß ihn bei fast 90 % des eigenen KI-Crawler-Traffics und merkte an, dass er robots.txt-Anweisungen ignoriert.

Die Durchsetzung findet deshalb eine Schicht tiefer statt. Prüfen Sie Crawler anhand der IP-Listen, die die meisten Anbieter veröffentlichen (OpenAI, Anthropic, Apple, Common Crawl und DuckDuckGo pflegen JSON-Listen, Amazon veröffentlicht seine Bereiche auf der Entwicklerseite), und sperren Sie am CDN oder an der WAF, was Sie tatsächlich stoppen wollen. Die Prüfung ist wichtiger, als es scheint: HUMAN Security hat gemessen, dass eine von 18 Anfragen mit dem User-Agent eines bekannten KI-Crawlers gefälscht ist.

Unsere eigene robots.txt folgt der Konfiguration „Sichtbarkeit zuerst“: neunzehn ausdrückliche Allow-Gruppen je Crawler (jeder Crawler aus der Tabelle, der die Datei beachtet, dazu die Abruf-Crawler auf Nutzeranfrage, die uns ohnehin willkommen sind, und der klassische Bingbot), gefolgt von einer Allow-Regel für alle übrigen. Im August 2026 haben wir sie in diese Form gebracht und dabei die veraltete Gruppe anthropic-ai entfernt, beim Faktencheck für diesen Leitfaden außerdem eine spekulative Gruppe cohere-ai: Laut der eigenen Dokumentation von Cohere betreibt das Unternehmen derzeit keine Crawler.

Der naheliegende Einwand: Eine einzelne Zeile „User-agent: * / Allow: /“ würde dasselbe Verhalten der Crawler ergeben. Das stimmt. Die ausdrücklichen Gruppen bringen aber drei Vorteile, die die einzelne Zeile nicht bietet. Jeder Anbieter erhält ein eindeutiges Signal unserer Absicht statt nur einer fehlenden Ablehnung. Spätere Änderungen sind sicherer: Ein Disallow, das für einen Crawler ergänzt wird, kann nicht stillschweigend für Crawler gelten, an die niemand gedacht hat. Und die Datei dient zugleich als unsere Prüfliste: Bringt ein Anbieter einen neuen Crawler heraus, wie es OpenAI und Anthropic in den letzten zwei Jahren beide getan haben, ist die Lücke in der Datei selbst und in unseren Crawl-Logs sichtbar.

Unser Leitfaden dazu, wie wir GEO auf unserer eigenen Website anwenden, erklärt die weitere Einrichtung. Ein Verlag mit einem Archiv hinter einer Paywall wählt womöglich stattdessen Konfiguration 2 oder 3. Was auch immer Sie wählen: Prüfen Sie die Datei vierteljährlich. OpenAI hat 2024 OAI-SearchBot ergänzt, Anthropic 2025 Claude-SearchBot, und Amazon hatte sein Crawling bis 2026 auf drei Crawler aufgeteilt. Eine Richtlinie von 2024 deckt die relevanten Crawler womöglich nicht mehr ab.