Suche erlauben, Training getrennt steuern: KI-Crawler nach Zweck unterscheiden

Zuerst den gewünschten Zweck festlegen

Ein Unternehmen möchte seine öffentlichen Produktinformationen in Suchantworten auffindbar machen, die Nutzung für Modelltraining aber begrenzen. Dieses Ziel ist konkreter als die pauschale Frage, ob KI-Bots erlaubt werden sollen. Ein Suchcrawler erschließt Quellen, ein Trainingscrawler sammelt potenzielles Trainingsmaterial, und ein Nutzerabruf lädt eine Seite auf eine konkrete Anfrage hin. Die Anbieter setzen diese Zwecke technisch unterschiedlich um.

Legen Sie deshalb pro öffentlichem Inhaltsbereich drei Entscheidungen fest: Soll er für Suche zugänglich sein, soll er für die dokumentierte Trainingsnutzung freigegeben sein, und wie sollen direkte Nutzerabrufe behandelt werden? Die folgenden Zuordnungen beruhen auf den verlinkten Herstellerangaben mit Prüfstand 11. September 2026. Sie beschreiben keine eigene Messung des tatsächlichen Bot-Verhaltens.

OpenAI: Suchbot und Trainingsbot getrennt behandeln

OpenAI dokumentiert unabhängige robots.txt-Einstellungen für OAI-SearchBot und GPTBot. Die Kombination Suchzugriff erlauben und Trainingscrawler sperren ist damit ausdrücklich vorgesehen. ChatGPT-User gehört zu einer dritten Kategorie und steuert nicht, ob eine Seite in ChatGPT Search berücksichtigt wird.

• OAI-SearchBot erschließt Inhalte für die Suche in ChatGPT. Eine Sperre kann die Aufnahme in Suchantworten verhindern; ein navigierender Link kann laut OpenAI dennoch erscheinen.
• GPTBot sammelt Inhalte, die zum Training von Grundlagenmodellen verwendet werden können. Wer diese Nutzung begrenzen möchte, setzt eine eigene Sperrregel für GPTBot. Daraus folgt keine nachgewiesene rückwirkende Entfernung früher genutzter Inhalte.
• ChatGPT-User führt bestimmte nutzerinitiierte Seitenabrufe aus. OpenAI erklärt, dass robots.txt bei solchen Abrufen möglicherweise nicht greift. Behandeln Sie diese Datei daher nicht als verlässlichen Zugriffsschutz für diesen Fall.

Google: Google-Extended ist kein reiner Trainingsschalter

Google Search einschließlich AI Overviews und AI Mode baut auf dem Suchzugriff auf. Google-Extended ist ein zusätzlicher Steuertoken in robots.txt, kein eigenständiger HTTP-User-Agent. Er betrifft laut Google sowohl das Training künftiger Gemini-Generationen für Gemini Apps und die Vertex AI API als auch Grounding in Gemini Apps und „Grounding with Google Search“ auf Vertex AI. Grounding bedeutet hier, Antworten durch gefundene Webinhalte zu fundieren.

Eine Google-Extended-Sperre beeinflusst laut Anbieter weder die Aufnahme noch das Ranking in Google Search. Sie ist aber keine Zusage, dass sämtliche anderen KI-Anwendungen weiterhin auf die Inhalte zurückgreifen. Halten Sie diese Einschränkung ausdrücklich in Ihrer Entscheidung fest.

Für mögliche Quellenlinks in den KI-Funktionen von Search muss eine Seite indexiert und für Such-Snippets geeignet sein. Google nennt dafür die üblichen Vorschau- und Indexkontrollen, darunter nosnippet, data-nosnippet, max-snippet und noindex. Verwechseln Sie diese Darstellungsentscheidungen nicht mit einer separaten Trainingspräferenz. Auch korrekt gesetzte Regeln garantieren keine Aufnahme in eine Antwort.

Perplexity: Suchzugriff klar zuordnen, Nutzerabrufe gesondert prüfen

PerplexityBot dient laut Anbieter der Suche und der Verlinkung von Quellen, nicht dem Training von Grundlagenmodellen. Perplexity-User ruft Seiten auf Nutzeranfrage ab und wird ebenfalls nicht als Trainingscrawler beschrieben. Eine Sperre von PerplexityBot sollte deshalb als Entscheidung über den Suchzugriff begründet werden.

Für Perplexity-User sind die am Prüfdatum erreichbaren Anbietertexte nicht widerspruchsfrei: Die Crawler-Dokumentation sagt, dass robots.txt bei Nutzerabrufen im Allgemeinen ignoriert wird. Das Help Center erklärt dagegen, dass die frühere URL-Zusammenfassung trotz robots-Sperre deaktiviert wurde. Eine pauschale Zusicherung zum Verhalten aller Nutzerabrufe lässt sich daraus nicht ableiten.

Unsere redaktionelle Schlussfolgerung: Halten Sie diese Unsicherheit fest und prüfen Sie tatsächliche Abrufe in Ihren Serverprotokollen. Das Help Center weist außerdem darauf hin, dass bei blockierten Seiten weiterhin etwa Domain und Überschrift bekannt sein können. Eine Crawlsperre ist somit kein Nachweis vollständiger Unsichtbarkeit.

Anthropic: Auch der Nutzer-Bot hat eine eigene dokumentierte Regel

Anthropic unterscheidet ClaudeBot für potenzielles Trainingsmaterial, Claude-SearchBot für Suchzwecke und Claude-User für Abrufe auf Nutzeranfrage. Nach der Anbieterbeschreibung beachten diese Bots robots.txt. Übertragen Sie die von OpenAI beschriebene mögliche Ausnahme für Nutzerabrufe deshalb nicht automatisch auf Claude-User.

Für das Ziel Suchzugriff erlauben und künftige Trainingssammlung begrenzen kommen getrennte Regeln für Claude-SearchBot und ClaudeBot infrage. Entscheiden Sie zusätzlich über Claude-User. Die Regeln sind für jede betroffene Subdomain zu prüfen; eine Präferenz auf der Hauptdomain ersetzt keine Prüfung des Hilfecenters auf einer anderen Subdomain.

Ein konkretes Regelbeispiel mit bestehender Pfadsperre

Das folgende hypothetische Beispiel nimmt eine öffentliche Website mit dem Pfad /intern/ an. Suchzugriff soll möglich bleiben, die dokumentierte Trainingssammlung durch GPTBot und ClaudeBot soll gesperrt werden. Für Google wird zusätzlich akzeptiert, dass die Google-Extended-Sperre auch dessen beschriebene Grounding-Nutzungen betrifft. Das Beispiel ist eine Konfigurationshilfe, keine bereits auf dieser Website umgesetzte Regel.

Jeder der folgenden Punkte beschreibt eine eigene robots.txt-Gruppe. Der Pfeil steht für einen Zeilenumbruch; zwischen den Gruppen erleichtert eine Leerzeile die Lesbarkeit. Die Pfadsperre ist hier eine Crawl-Präferenz. Vertrauliche Inhalte unter /intern/ benötigen darüber hinaus eine echte Zugangskontrolle.

• Allgemeine Gruppe: User-agent: * → Disallow: /intern/
• OpenAI-Suche: User-agent: OAI-SearchBot → Allow: / → Disallow: /intern/
• OpenAI-Training: User-agent: GPTBot → Disallow: /
• Google-Extended-Nutzungen: User-agent: Google-Extended → Disallow: /
• Anthropic-Suche: User-agent: Claude-SearchBot → Allow: / → Disallow: /intern/
• Anthropic-Training: User-agent: ClaudeBot → Disallow: /
• Perplexity-Suche: User-agent: PerplexityBot → Allow: / → Disallow: /intern/

Warum eine neue Allow-Gruppe alte Sperren aushebeln kann

Nach dem Robots Exclusion Protocol kann die spezifisch passende Bot-Gruppe anstelle der allgemeinen Stern-Gruppe gelten. Eine neue Gruppe mit ausschließlich Allow: / übernimmt eine bisherige Disallow-Regel aus der Stern-Gruppe daher nicht automatisch. Im Beispiel wird /intern/ für die ausdrücklich erlaubten Suchbots erneut ausgeschlossen. Übertragen Sie dieses Prinzip auf Ihre tatsächlich vorhandenen Pfade und prüfen Sie schon bestehende Gruppen desselben Bots.

Die Nutzer-Bots sind im Beispiel bewusst nicht einzeln konfiguriert. Das stellt keine universelle Erlaubnis oder Sperre für Nutzerabrufe her: Vor einer vollständigen Einführung müssen Sie deren gewünschte Behandlung pro Anbieter festlegen und gegen die dokumentierten Grenzen prüfen. Ändern Sie vorhandene Regeln nicht durch blindes Anhängen des Beispiels.

Wenn das eigentliche Ziel die Entfernung aus Google Search ist, genügt eine robots-Sperre nicht zuverlässig. Google muss eine noindex-Anweisung abrufen können, um sie zu verarbeiten. Wenn das Ziel dagegen Vertraulichkeit ist, brauchen Sie Authentifizierung und Berechtigungen. Das sind jeweils andere Aufgaben als die Steuerung einer Trainingspräferenz.

Die Umsetzung in fünf getrennten Schritten prüfen

Die folgende Prüffolge ist eine redaktionelle Empfehlung. Sie trennt die beabsichtigte Regel von ihrer Auslieferung und vom beobachteten Ergebnis. Arbeiten Sie mit wenigen repräsentativen öffentlichen und ausgeschlossenen URLs; eine Prüfung der Startseite allein deckt ein Hilfecenter oder andere Hosts nicht ab.

• 1. Entscheidung sichern: Verantwortliche Person, betroffene Hosts, Inhaltsbereiche, erlaubte Zwecke und akzeptierte Einschränkungen dokumentieren. Eine Kopie der bisherigen Konfiguration für die Rücknahme aufbewahren.
• 2. Ausgelieferte Regel lesen: Die tatsächliche robots.txt jedes Hosts prüfen, passende Gruppen und Pfade auflösen und unbeabsichtigte Freigaben ausschließen. Eine korrekt bearbeitete Datei im Projekt beweist noch nicht ihre Auslieferung.
• 3. Weitere Zugriffshürden prüfen: CDN, Firewall, Bot-Schutz und Login können einen erlaubten Suchabruf weiter verhindern. Ein Test mit nachgebildetem User-Agent zeigt nur, wie das System auf diesen Test reagiert.
• 4. Echte Abrufe zuordnen: Den User-Agent mit den aktuellen Verifikationsangaben des Anbieters abgleichen. OpenAI, Perplexity und Anthropic verlinken IP-Bereiche; Google dokumentiert zusätzlich die zusammengehörige Prüfung von Reverse- und Forward-DNS. Ein Botname allein beweist keine Herkunft.
• 5. Ergebnis getrennt belegen: Erreichbarkeit, verifizierten Abruf, Indexierung und konkrete Quellenverwendung einzeln protokollieren. Ein erfolgreicher Abruf beweist keine spätere Zitierung; ein ausbleibender Abruf beweist nicht allein, dass die Regel fehlerhaft ist.

Welche Entscheidung am Ende dokumentiert sein sollte

Ein brauchbares Ergebnis lautet beispielsweise: Öffentliche Produktseiten bleiben für die ausgewählten Suchcrawler zugänglich; bestimmte Trainingszwecke werden über die dokumentierten Bot-Regeln ausgeschlossen; die zusätzliche Google-Extended-Einschränkung ist akzeptiert; Nutzerabrufe und vertrauliche Bereiche erhalten eine gesonderte Behandlung. Dazu gehören der Quellenstand, die ausgelieferte Konfiguration und die tatsächlichen Prüfergebnisse.

Überprüfen Sie diese Zuordnung erneut, wenn ein Anbieter Zwecke oder Steuertokens ändert, ein zusätzlicher Host online geht oder Ihr Bot-Schutz angepasst wird. Regeln schaffen eine überprüfbare Zugriffsentscheidung. Wie häufig und mit welchen Aussagen Ihre Inhalte in KI-Antworten erscheinen, muss separat beobachtet werden.