Die Wissensseite soll in die Antwort. Ins Training aber nicht. Die Wissensseite soll in die Antwort. Ins Training aber nicht.

Die falsche Regel ist schnell geschrieben

Eine öffentliche Wissensseite soll in einer KI-Antwort auftauchen können. Für das Training eines Grundlagenmodells soll sie nicht freigegeben werden. Wer daraus nur die Frage „KI-Bots erlauben oder sperren?“ macht, hat die eigentliche Entscheidung bereits verloren.

Denn derselbe Anbieter kann eine Seite aus unterschiedlichen Gründen abrufen: für eine Suchfunktion, für mögliche Trainingsdaten, im Auftrag eines Nutzers oder zur Prüfung einer eingereichten Anzeigen-Landingpage. Diese Zugriffe sehen im Server-Log ähnlich aus. Sie bedeuten nicht dasselbe.

Der praktikable Weg ist deshalb weder die pauschale Freigabe noch die pauschale Sperre. Er beginnt mit einer nach Anbieter, Zweck und Seitenklasse abgestuften Crawler-Richtlinie. Quellenstand dieser Prüfung ist der 1. Oktober 2026.

Vier Zugriffe, die gleich aussehen

OpenAI trennt mehrere Rollen. OAI-SearchBot wird für die Suchfunktionen in ChatGPT eingesetzt. GPTBot sammelt Inhalte, die möglicherweise zum Training generativer Grundlagenmodelle verwendet werden. OAI-AdsBot prüft Seiten, die als Anzeigenziele eingereicht wurden; dessen Daten werden laut OpenAI nicht für das Training generativer Grundlagenmodelle verwendet. OpenAI nennt ausdrücklich die Möglichkeit, OAI-SearchBot zu erlauben und GPTBot zu blockieren. Die Dokumentation der OpenAI-Crawler ↗ behandelt diese Einstellungen unabhängig voneinander.

ChatGPT-User gehört nicht in dieselbe Kategorie. Dieser Agent kann Webseiten bei bestimmten Aktionen eines Nutzers abrufen und crawlt das Web nicht automatisch. OpenAI weist zugleich darauf hin, dass robots.txt bei solchen nutzerinitiierten Aktionen möglicherweise nicht gilt. Eine Regel für ChatGPT-User ist daher keine ebenso belastbare Schranke wie die Trennung zwischen OAI-SearchBot und GPTBot.

Anthropic unterscheidet ebenfalls drei Rollen. ClaudeBot sammelt Webinhalte, die möglicherweise zum Modelltraining beitragen. Claude-SearchBot unterstützt die Suche. Claude-User ruft Inhalte auf Veranlassung eines Nutzers ab. Anthropic erklärt, dass diese Bots robots.txt beachten und getrennt behandelt werden können. Die Crawler-Dokumentation von Anthropic ↗ ist auf den 7. April 2026 datiert.

Google zieht die Grenze anders. Google-Extended ist kein eigener User-Agent, der als solcher in den HTTP-Logs erscheint. Es ist ein Steuerungseintrag in der robots.txt. Er betrifft sowohl die Verwendung gecrawlter Inhalte für künftige Gemini-Modelle als auch bestimmte Grounding-Nutzungen aus dem Google-Suchindex. Die klassische Google-Suche und deren Rankings bleiben davon laut Google-Dokumentation zu Google-Extended ↗ unberührt.

Damit lässt sich bei Google nicht über diesen einen Eintrag festlegen: Training nein, das von Google-Extended erfasste Grounding aber ja. Die technische Granularität des Anbieters setzt der eigenen Richtlinie eine Grenze. Der Beitrag Die Antwort ist nicht zu verkaufen ordnet ein, warum Suche, KI-Antworten, Anzeigen und Training auch geschäftlich getrennt betrachtet werden sollten.

Die Seite entscheidet vor dem Bot

Eine Botliste allein beantwortet noch nicht, welche Inhalte zugänglich sein sollen. Zuerst müssen die Seitenklassen feststehen. Sonst trifft die robots.txt unbemerkt eine redaktionelle, vertriebliche oder datenschutzrechtliche Entscheidung.

robots.txt kann diese Ordnung abbilden. Sie kann sie nicht durchsetzen. Cloudflare beschreibt die Direktiven als Crawling-Signal ohne formale Zugriffskontrolle. Die Cloudflare-Auswertung für 2025 ↗ trennt Training, Suche und nutzerinitiierte Abrufe ebenfalls als unterschiedliche Zwecke.

Ein vertrauliches PDF wird deshalb nicht geschützt, indem sein Pfad in der robots.txt steht. Die Datei selbst ist öffentlich abrufbar und kann unerwünschte Pfade sogar sichtbar machen. Was nicht öffentlich sein darf, benötigt eine echte Zugriffssperre.

So wird aus einer Präferenz eine Richtlinie

1. Das Ziel ohne Botnamen formulieren. Zum Beispiel: Öffentliche Fachseiten dürfen für Suche und Antworten abgerufen werden. Sie sollen nicht für das Training von Grundlagenmodellen freigegeben werden. Geschützte Inhalte bleiben unabhängig vom anfragenden Agenten unzugänglich.
2. Reale URL-Klassen erfassen. Prüfen Sie HTML-Seiten, PDFs, Bilder, Feeds, Subdomains und externe Asset-Hosts. Eine offene Wissensseite hilft wenig, wenn ihr entscheidendes Diagramm von einer gesperrten Bilddomain kommt.
3. Die Anbieterzwecke dokumentieren. Notieren Sie für jeden Dienst den robots.txt-Token, den beschriebenen Zweck, verfügbare IP-Informationen und die gewünschte Behandlung. Halten Sie ausdrücklich fest, wenn ein Anbieter Zwecke koppelt oder robots.txt nicht in jedem Abruffall zusichert.
4. robots.txt und Infrastruktur gemeinsam testen. CDN, WAF, Bot-Schutz, JavaScript-Prüfungen oder Firewalls können einen erlaubten Crawler dennoch abweisen. OpenAI empfiehlt für Anzeigenziele, diese Ebenen gemeinsam zu prüfen. Die Hinweise für erreichbare Anzeigen-Landingpages ↗ nennen insbesondere robots.txt, Webschutz und Anti-Bot-Logik.
5. Verantwortung und Änderungsanlass festlegen. SEO und Redaktion bestimmen den gewünschten Zugang. Datenschutz und Security prüfen die Inhaltsklassen und Grenzen. Web-Engineering setzt die Regeln um. Eine benannte Rolle entscheidet bei Zielkonflikten und veranlasst die erneute Prüfung.

Beispiel: /wissen/ offen, Trainings-Crawler gesperrt

Redaktionelles Beispiel, kein Kundenfall: Ein B2B-Unternehmen veröffentlicht Fachartikel unter /wissen/. Ausgewählte Anzeigenziele liegen unter /loesungen/. Der Kundenbereich befindet sich unter /konto/ und ist serverseitig geschützt.

Die Wissensseiten sollen für dokumentierte Suchdienste erreichbar sein. GPTBot und ClaudeBot sollen keinen Zugriff erhalten. Eine mögliche Ausgangskonfiguration lautet:

User-agent: OAI-SearchBot
Allow: /wissen/
Allow: /loesungen/
Disallow: /

User-agent: GPTBot
Disallow: /

User-agent: OAI-AdsBot
Allow: /loesungen/
Disallow: /

User-agent: Claude-SearchBot
Allow: /wissen/
Disallow: /

User-agent: Claude-User
Allow: /wissen/
Disallow: /

User-agent: ClaudeBot
Disallow: /

User-agent: Google-Extended
Disallow: /

Die OpenAI-Regeln erlauben den Suchzugriff auf die vorgesehenen Pfade und blockieren GPTBot. OAI-AdsBot erhält nur Zugang zu den beispielhaften Anzeigenzielen. ChatGPT-User fehlt bewusst in der Konfiguration: OpenAI sagt für nutzerinitiierte Abrufe keine durchgängige Anwendung der robots.txt zu. Eine scheinbar präzise Pfadregel würde hier mehr Kontrolle ausdrücken, als der Anbieter dokumentiert.

Bei Anthropic bleiben Claude-SearchBot und Claude-User für den Wissenspfad zugelassen, während ClaudeBot gesperrt wird. Google-Extended ist vollständig blockiert. Die klassische Google-Suche bleibt offen; zugleich werden jedoch sowohl die erfassten Trainings- als auch Grounding-Nutzungen ausgeschlossen. Das ursprüngliche Ziel „Antwort ja, Training nein“ ist bei Google über diesen Token also nur teilweise umsetzbar.

/konto/ erscheint nicht als angeblich geschützter Spezialfall. Der Bereich braucht Login, Autorisierung und serverseitige Zugriffskontrolle. robots.txt kann dort höchstens ergänzend verhindern, dass regelkonforme Crawler unnötige Anfragen stellen.

Der Name im Log beweist noch nichts

Ein User-Agent ist zunächst eine Zeichenfolge im Request-Header. Wer einen Crawler verifizieren will, sollte deshalb nicht nur nach dem Namen suchen. OpenAI veröffentlicht für OAI-SearchBot, GPTBot, OAI-AdsBot und ChatGPT-User eigene IP-Listen. Anthropic verweist auf eine Liste von Quelladressen, anhand derer sich Zugriffe dem Anbieter zuordnen lassen.

Die Prüfung sollte mindestens User-Agent, Quelladresse, angefragten Pfad, HTTP-Status und Zeitpunkt zusammenführen. Danach folgt die Gegenprobe: Erreichen erlaubte Dienste die vorgesehenen Seiten? Werden sie von der WAF herausgefordert oder blockiert? Rufen gesperrte Trainings-Crawler die ausgeschlossenen Pfade trotzdem ab?

Bei Google-Extended funktioniert diese Suche anders. Weil kein eigener HTTP-User-Agent existiert, kann im Log kein „Google-Extended-Besuch“ verifiziert werden. Der Token steuert eine zulässige spätere Verwendung von Inhalten, die Google mit bestehenden Agenten crawlt. Das ist eine Nutzungspräferenz, keine separat beobachtbare Crawlspur.

Was sich nicht konfigurieren lässt

Eine selektive robots.txt kann eine belastbare Präferenz ausdrücken. Sie beweist weder die rückwirkende Entfernung aus früheren Datensätzen noch eine Änderung bereits trainierter Modelle. Die verlinkten Anbieterdokumentationen beschreiben vor allem künftige Abrufe und Verwendungen.

Auch die Freigabe eines Such-Crawlers garantiert keine KI-Sichtbarkeit. Sie schafft einen möglichen Zugangsweg. Ob eine Seite indexiert, ausgewählt, zitiert oder von einem Menschen besucht wird, ist eine andere Messfrage.

Schließlich können sich Botnamen, IP-Bereiche und Anbieterzwecke ändern. Je genauer die Richtlinie wird, desto wichtiger wird ihre Wartung. Präzision in der Datei ist nur dann ein Vorteil, wenn ihre Annahmen dokumentiert und regelmäßig überprüft werden.

Fertig ist die Richtlinie erst im Server-Log

Nach der Veröffentlichung beginnt der Test. Die zuständigen Teams sollten dokumentierte Test-URLs abrufen, Statuscodes prüfen und WAF-Ereignisse mit den Server-Logs abgleichen. Erst dann ist sichtbar, ob die beabsichtigte Trennung auch technisch besteht.

Danach folgt eine zweite, bewusst getrennte Frage: Hat ein erlaubter Bot-Abruf zu einer Nennung, einem menschlichen Besuch oder einem geschäftlich relevanten Folgeereignis geführt? Der Journalbeitrag Ein Bot war hier. War das schon Nachfrage? setzt an dieser Messgrenze an.

Der praktische Unterschied liegt am Ende nicht in einer längeren Botliste. Er liegt in einer genaueren Entscheidung: Welcher dokumentierte Dienst darf zu welchem Zweck auf welche Seitenklasse zugreifen – und welcher beobachtbare Serverzustand bestätigt, dass diese Regel tatsächlich wirkt?