KI-Crawler blockieren: welche robots.txt-Regel passt

„Diese Zeilen in die robots.txt, dann nimmt sich keine KI mehr deine Texte.“ Der Rat steht in jedem zweiten Forenbeitrag, meist mit einer fertigen Liste zum Kopieren. Die Listen sind oft zwei Jahre alt. Sie enthalten Namen, die es so nicht mehr gibt, und sie sperren in einem Aufwasch Crawler, die mit Modelltraining nichts zu tun haben.

Was dann passiert, fällt erst Wochen später auf — und meist gar nicht. Die Seite verschwindet nicht aus Google. Sie verschwindet aus den Antworten, die ChatGPT und Perplexity ihren Nutzern geben, weil dort ein anderer Crawler zuständig ist als beim Training. Gewollt war das fast nie.

Dieser Beitrag sortiert, wer da anklopft, was eine Sperre jeweils kostet, wie die Regeln konkret aussehen und wo die robots.txt aufhört.

Drei Sorten Crawler, eine Datei#

Die ganze Entscheidung hängt an einer Unterscheidung, die in den meisten Anleitungen fehlt. Hinter den Namen stecken drei verschiedene Aufgaben:

Trainingssammler. Sie laden Inhalte, damit daraus später Modellgewichte werden. GPTBot, ClaudeBot, CCBot und meta-externalagent gehören hierher. Was sie holen, taucht nicht als Link in einer Antwort auf, es verschwindet im Modell. Wer sie sperrt, verliert keine Sichtbarkeit — nur die Aussicht, Teil der nächsten Modellgeneration zu sein.

Abrufer im Moment der Frage. Sie holen eine einzelne Seite, weil gerade jetzt ein Mensch eine Frage gestellt hat, deren Antwort dort steht. ChatGPT-User, Claude-User, Perplexity-User, meta-externalfetcher. Hier landet dein Text unmittelbar in der Antwort, oft mit Quellenangabe. Eine Sperre heißt: Du wirst nicht geöffnet, wenn jemand dich gerade braucht.

Index-Crawler. Sie bauen einen durchsuchbaren Index auf, aus dem die Antwortmaschine sich bedient, bevor sie formuliert. OAI-SearchBot, Claude-SearchBot, PerplexityBot. Das ist Suchmaschinen-Crawling, nur für eine andere Oberfläche. OpenAI schreibt dazu unmissverständlich: Wer OAI-SearchBot aussperrt, wird in den Suchantworten von ChatGPT nicht mehr angezeigt.

Wer alles aussperrt, trifft alle drei Gruppen. Für die meisten Websites ist das die teuerste Variante — sie verhindert Training, das ohnehin schwer zu verhindern ist, und verzichtet gleichzeitig auf Erwähnungen mit Link. Warum diese Erwähnungen überhaupt etwas wert sind und wie man sie sich verdient, steht in in KI-Suchmaschinen gefunden werden.

Wer da anklopft#

Jede Zeile hier steht so in der Dokumentation des jeweiligen Betreibers, geprüft im September 2026. Die Namen ändern sich — vor dem Kopieren nachsehen.

Zwei Muster lohnen den zweiten Blick. Google und Apple haben ihre KI-Nutzung sauber vom Suchindex getrennt: Google-Extended und Applebot-Extended crawlen selbst gar nichts, sie sind reine Schalter. Du sperrst das Training, ohne die Suche anzufassen. Meta hat diese Trennung nicht — dort steht in der eigenen Dokumentation Training oder Indexierung hinter demselben Namen. Wer meta-externalagent sperrt, weiß nicht genau, worauf er verzichtet.

Die drei Haltungen als Datei#

Die robots.txt liegt im Wurzelverzeichnis, also unter https://deine-domain.de/robots.txt, und gilt nur für genau diesen Host und dieses Protokoll. Subdomains brauchen eine eigene.

Haltung 1 — alles zulassen. Keine Regel für KI-Crawler. Das ist die Voreinstellung, wenn nichts dasteht, und für die meisten Websites die richtige. Ein leeres Disallow schreibt man nur hin, um die Absicht zu dokumentieren:

User-agent: *
Disallow:

Sitemap: https://deine-domain.de/sitemap.xml

Haltung 2 — Training sperren, Antworten zulassen. Die Variante, die die meisten eigentlich meinen. Trainingssammler raus, Index- und Abruf-Crawler bleiben:

User-agent: GPTBot
Disallow: /

User-agent: ClaudeBot
Disallow: /

User-agent: Google-Extended
Disallow: /

User-agent: Applebot-Extended
Disallow: /

User-agent: CCBot
Disallow: /

User-agent: meta-externalagent
Disallow: /

Haltung 3 — alles sperren. Sinnvoll nur, wenn deine Inhalte aus einem anderen Grund nicht in fremden Antworten auftauchen sollen: Lizenzmodell, Mandantendaten, Redaktionsarchiv hinter einer Bezahlschranke. Dann kommen die Index-Crawler dazu — OAI-SearchBot, Claude-SearchBot, PerplexityBot, Bytespider — und die Abrufer ChatGPT-User, Claude-User, Perplexity-User und meta-externalfetcher.

Drei Syntaxfallen, die regelmäßig zuschlagen:

1. Ein Crawler befolgt genau eine Gruppe. Trifft ein Bot auf einen Block mit seinem eigenen Namen, ignoriert er die Gruppe unter User-agent: * vollständig. Wer dort allgemeine Ausnahmen pflegt, muss sie in der spezifischen Gruppe wiederholen.
2. Pfade sind groß- und kleinschreibungsempfindlich, die Namen nicht. Disallow: /Presse/ sperrt /presse/ nicht.
3. Bei widersprüchlichen Regeln gewinnt die längere Pfadangabe, nicht die zuerst notierte. Sind beide gleich lang, gewinnt Allow.

Ob die Datei überhaupt sauber ausgeliefert wird und was ein Crawler an deiner Seite sonst vorfindet, zeigt dir das SEO-Audit ohne Anmeldung. Was passiert, wenn eine Regel versehentlich zu weit greift, steht in „Durch robots.txt blockiert“.

Nachsehen, wer tatsächlich vorbeikommt#

Bevor du etwas sperrst, lohnt der Blick ins Server-Protokoll. Dort steht jede Anfrage mit Zeitstempel, Pfad und User-Agent — es ist die einzige Quelle, die zeigt, wer wirklich da war. Bei einer Apache- oder Nginx-Logdatei reicht das hier:

grep -ioE 'GPTBot|OAI-SearchBot|ChatGPT-User|ClaudeBot|Claude-SearchBot|PerplexityBot|CCBot|Bytespider|meta-externalagent' access.log | sort | uniq -c | sort -rn

Das Ergebnis überrascht die meisten: Oft sind zwei oder drei Namen für den Großteil der Zugriffe verantwortlich, und der Crawler, den man unbedingt sperren wollte, war nie da. Dieselbe Zeile zwei Wochen nach der Änderung noch einmal ausführen — dann siehst du, wer sich an deine Regel hält und wer nicht. Wie sich Crawl-Verhalten sonst noch lesen lässt, steht ausführlich in Wie oft crawlt Google meine Seite?

Ein Name im User-Agent ist frei wählbar — jedes Skript kann sich GPTBot nennen. Common Crawl und Perplexity veröffentlichen deshalb ihre IP-Bereiche, Common Crawl zusätzlich Reverse-DNS-Einträge. Wer auf Serverebene sperrt, prüft besser dagegen als gegen die Zeichenkette.

Wo die robots.txt aufhört#

Das Wichtigste zuletzt, weil es die ganze Übung relativiert: Die robots.txt ist eine Bitte. Google formuliert es in der eigenen Dokumentation so, dass es dem Crawler überlassen bleibt, ob er die Anweisungen befolgt — die Datei kann gar nichts erzwingen.

Bei den Abrufern steht das sogar ausdrücklich in den Anbieterdokumenten: Perplexity-User ignoriert robots.txt laut Perplexity grundsätzlich, meta-externalfetcher umgeht sie laut Meta, und OpenAI schreibt zu ChatGPT-User, dass die Regeln bei nutzerausgelösten Abrufen nicht zwangsläufig gelten. Die Begründung ist überall dieselbe: Das sei kein Crawling, sondern ein Mensch, der eine Seite öffnen lässt. Bei Bytespider gibt es nicht einmal eine Dokumentation, an der sich eine Zusage festmachen ließe.

Was technisch sperrt, ist eine Regel eine Ebene tiefer — im Webserver oder im CDN. Ein Beispiel für Nginx:

if ($http_user_agent ~* "(GPTBot|CCBot|Bytespider)") { return 403; }

Cloudflare, Fastly und die übrigen CDN-Anbieter haben dasselbe als Schalter in der Oberfläche. Das ist die einzige Sperre, die den Namen verdient — und auch sie greift nur, solange der Bot sich ehrlich meldet. Deshalb der Hinweis auf die IP-Bereiche weiter oben.

Und selbst eine perfekte Sperre holt nichts zurück. Was bereits in ein trainiertes Modell eingeflossen ist, bleibt dort. Was andere über dich geschrieben haben, bleibt abrufbar. Eine Regel wirkt ab heute, nicht rückwirkend. Diese Nüchternheit gehört zu jeder technischen Entscheidung rund um KI im Unternehmen — der Überblick zur KI-Automatisierung ordnet ein, wo sie sonst noch gebraucht wird.

Und was ist mit llms.txt?#

Die naheliegende Rückfrage, weil die Datei gerade überall empfohlen wird: llms.txt ist weder Ersatz noch Gegenstück zur robots.txt. Sie ist ein Vorschlag für eine Inhaltskarte — eine Datei, die einem Modell zeigt, was auf deiner Seite steht. Sie regelt keinen Zugriff, und kein großer Anbieter hat zugesagt, sie als Erlaubnis oder Verbot zu lesen. Was sie kann und für wen sie sich lohnt, steht in llms.txt.

Häufige Fragen#

Schadet es meinem Google-Ranking, wenn ich GPTBot sperre? Nein. Die Tokens sind getrennt. Google stellt das sogar für den eigenen Schalter ausdrücklich fest: Google-Extended beeinflusst weder die Aufnahme in die Suche noch dient es als Rankingsignal.

Bekomme ich meine Texte aus einem Modell wieder heraus, wenn ich jetzt sperre? Nein. Eine Regel in der robots.txt verhindert künftige Abrufe. Auf das, was bereits trainiert wurde, hat sie keinen Einfluss.

Reicht nicht ein Disallow: / unter User-agent: *? Das sperrt auch Googlebot, Bingbot und jeden anderen. Der Stern ist die Gruppe für alle, die keinen eigenen Block haben — nie der richtige Ort für eine KI-Entscheidung.

Woher weiß ich, ob ein Bot echt ist? Nicht am Namen. Der User-Agent ist eine frei wählbare Zeichenkette. Verlässlich sind nur die veröffentlichten IP-Bereiche und, wo vorhanden, die Reverse-DNS-Einträge des Betreibers.

Brauche ich eine eigene robots.txt pro Subdomain? Ja. Die Datei gilt für genau einen Host und ein Protokoll. shop.example.de liest nicht die Datei von www.example.de.

Wie oft muss ich die Liste prüfen? Zweimal im Jahr reicht. Neue Namen kommen dazu, alte werden umbenannt — die Anbieterdokumentation ist die einzige Quelle, die das verlässlich abbildet.

Kurz gefasst#

KI-Crawler sind nicht eine Gruppe, sondern drei: Training, Suchindex und Abruf im Moment der Nutzerfrage. Nur die erste Gruppe lässt sich ohne Sichtbarkeitsverlust sperren.

Die verbreiteten Kopiervorlagen sperren alle drei auf einmal. Wer das tut, verhindert Training, das ohnehin schwer zu verhindern ist, und verzichtet nebenbei auf die Erwähnung mit Link.

Die robots.txt bleibt dabei eine Bitte. Wer eine Sperre braucht, schreibt sie in den Webserver oder ins CDN — und sieht im Protokoll nach, ob sie wirkt.