__usage_ai-training in der robots.txt: Was das Signal steuert

Du hast in der robots.txt GPTBot gesperrt und trotzdem die Sorge, dass deine Texte im Training landen, oder du liest vom neuen Signal __usage_ai-training und weißt nicht, ob deine Datei jetzt angepasst werden muss. Dieser Beitrag geht die Umsetzung in fünf Schritten durch und nennt zu jedem Schritt einen Stolperstein.

Definition: __usage_ai-training ist die Bezeichnung für ein robots.txt-Signal, mit dem Website-Betreiber ausdrücken, ob ihre Inhalte für das Training von KI-Modellen genutzt werden sollen. Es ist eine Präferenzangabe, keine technische Sperre. Es regelt das Training und lässt die Frage offen, ob ein KI-System deine Seite zur Beantwortung einer Nutzerfrage abruft.

Eine Einschränkung vorab: Google hat auf dem Search-Central-Blog einen Beitrag mit dem Titel „Supporting a shared AI training control for websites“ veröffentlicht (https://developers.google.com/search/blog/2026/10/ai-training-control). Der Artikeltext war beim Verfassen dieses Beitrags nicht abrufbar. Genaue Syntax, Wertebereich und die Liste unterstützender Anbieter geben wir deshalb nicht wieder. Lies diese Details bitte im Originalbeitrag nach, bevor du etwas in die Produktion übernimmst.

Schritt 1: robots.txt-Dateien inventarisieren

Bevor du ein Signal setzt, brauchst du eine Liste aller Dateien, die gelten. Eine robots.txt gilt immer nur für den Host, unter dem sie liegt. Hat deine Marke eine Hauptdomain, einen Shop auf einer Subdomain und ein Hilfecenter bei einem Dienstleister, sind das drei getrennte Dateien.

Rechenbeispiel (hypothetisch): Angenommen, du betreibst vier Subdomains mit je eigener robots.txt. Dann müsste ein Training-Signal in diesem Modell in vier Dateien einzeln stehen, sonst wäre es nur für einen Teil der Inhalte ausgedrückt.

Stolperstein: Ein vorgeschalteter Dienst kann die Datei ersetzen. Laut Cloudflare (Autor Will Allen, 2025) trennt die Content Signals Policy in der robots.txt die Signale search, ai-input und ai-train, und die verwaltete robots.txt war für über 3,8 Millionen Domains aktiviert (https://blog.cloudflare.com/content-signals-policy/). Ruf deine Datei deshalb im Browser ab und vergleiche sie mit dem, was in deinem CMS steht.

Schritt 2: Training, Abruf und Suche getrennt entscheiden

Für KI-Systeme fallen drei unterschiedliche Nutzungen an. Die Aufnahme in einen Suchindex ist die eine, der Abruf einer Seite als Antwortgrundlage die zweite, das Training eines Modells die dritte. Cloudflares Dreiteilung in search, ai-input und ai-train bildet genau diese Trennung ab (https://blog.cloudflare.com/content-signals-policy/).

Nutzung	Frage an dich	Was du abwägen solltest
Suche	Soll die Seite auffindbar sein?	Auffindbarkeit gegen Zurückhaltung
Abruf als Antwortgrundlage	Darf der Inhalt in Antworten einfließen?	Nennung in Antworten gegen Kontrolle
Training	Darf das Modell daraus lernen?	Beitrag zu künftigen Modellen gegen Kontrolle

Stolperstein: Aus unserer Sicht ist ein pauschales Disallow: / für einen Crawler-Namen ein grobes Werkzeug, wenn du Training und Abruf unterschiedlich behandeln willst. Dafür brauchst du eine Regel, die beides trennt. Wie sauber ein Anbieter diese Trennung umsetzt, ist eine offene Frage, die du in seiner Dokumentation klärst.

Schritt 3: Das Signal in der robots.txt setzen

Setze das Signal erst, wenn du die Syntax aus dem Google-Beitrag oder der Dokumentation des jeweiligen Anbieters geprüft hast. Trage es für jeden Host ein, den du in Schritt 1 gefunden hast, und teste die Datei danach mit einem Parser.

Stolperstein: Die Zeile zu schreiben und ein Erkennen durch den Crawler sind zwei verschiedene Dinge. Das Robots Exclusion Protocol ist laut IETF (M. Koster, G. Illyes, H. Zeller, L. Sassman, RFC 9309, 2022) standardisiert, die Regeln sind aber ausdrücklich „not a form of access authorization“ (https://www.rfc-editor.org/rfc/rfc9309.html). Ein Eintrag drückt also eine Bitte aus und verhindert technisch nichts. Auch Cloudflare schreibt, dass solche Signale nur Präferenzen ausdrücken und einige Firmen sie ignorieren könnten (https://blog.cloudflare.com/content-signals-policy/).

Schritt 4: Bestehende Crawler-Regeln parallel halten

Das neue Signal ersetzt die Regeln für einzelne Bots nicht. GPTBot (OpenAI), ClaudeBot (Anthropic), PerplexityBot und CCBot (Common Crawl) bleiben eigene User-Agents mit eigenen Einträgen. Wie das Verhältnis von Crawler-Regeln und Abruf aussieht, beschreibt unser Beitrag robots.txt für KI-Crawler: Was sie steuert und wo die Grenze liegt.

Bei Google gibt es bereits einen Mechanismus für diesen Zweck. Laut Google Search Central ist Google-Extended ein reines robots.txt-Token ohne eigenen User-Agent-String im HTTP-Request und beeinflusst weder die Aufnahme in die Google-Suche noch das Ranking, es steuert Gemini-Training und Grounding (https://developers.google.com/search/docs/crawling-indexing/google-common-crawlers).

Stolperstein: Wer Google-Extended sperrt und erwartet, in AI Overviews zu verschwinden oder dort zu erscheinen, verwechselt zwei Dinge. Das Token betrifft laut Google die Gemini-Nutzung, die Suche bleibt davon unberührt.

Schritt 5: Wirkung im Server-Log prüfen

Ob ein Crawler sich an deine Datei hält, siehst du nur in deinen Zugriffsprotokollen. Filtere nach den User-Agents, rufe die robots.txt-Zeitstempel ab und prüfe, ob Bots nach einer Änderung weiter auf gesperrte Pfade zugreifen. Wie das geht, steht in Log File Analyse: So erkennst du KI-Crawler wie GPTBot im Server-Log.

Stolperstein: Ein User-Agent-Eintrag im Log beweist nicht, dass der Bot echt ist. Fälschungen sind möglich, ein Abgleich mit veröffentlichten IP-Bereichen schafft Klarheit.

Wenn du Bots zusätzlich auf Netzwerkebene steuerst, lohnt ein eigener Blick darauf. Unser Beitrag Cloudflare blockiert KI-Bots: GEO-Sichtbarkeit ab 15.09.2026 schützen behandelt dieses Thema gesondert.

Was das Signal leistet und was bei dir offen bleibt

Aus den belegten Quellen lässt sich diese Einordnung ableiten: Die robots.txt kann Training als Wunsch ausdrücken, aber nicht durchsetzen, und sie kann Abruf, Suche und Training nur trennen, wenn der jeweilige Anbieter die Trennung versteht. Unsere Einordnung dazu: Wichtiger als die perfekte Syntax ist eine bewusste Entscheidung pro Nutzungsart. Überlege vorab, welche der drei Nutzungen du zulassen willst, und halte das Ergebnis schriftlich fest.

Offen sind aus unserer Sicht zwei Punkte. Wir vermuten, dass sich mehrere Anbieter an einer gemeinsamen Syntax orientieren, nachdem Google sich öffentlich dazu geäußert hat, belegt ist das nicht. Und ob ein Signal rückwirkend auf bereits gesammelte Daten wirkt, geht aus den uns vorliegenden Quellen nicht hervor.

Häufig gestellte Fragen

Verhindert __usage_ai-training das Training technisch? Nein. Laut RFC 9309 (IETF, 2022) ist das Robots Exclusion Protocol keine Zugriffsautorisierung (https://www.rfc-editor.org/rfc/rfc9309.html). Ein Eintrag drückt eine Präferenz aus, die ein Betreiber befolgen oder ignorieren kann.

Muss ich GPTBot, ClaudeBot und CCBot weiter einzeln eintragen? Wenn du bestimmte Crawler steuern willst, ja. Das Signal und die User-Agent-Regeln sind unterschiedliche Mechanismen. Welcher Anbieter welche Zeile auswertet, prüfst du in dessen Dokumentation.

Beeinflusst das Training-Signal meine Platzierung in der Google-Suche? Für Google-Extended nennt Google Search Central ausdrücklich, dass es weder Aufnahme in die Suche noch Ranking beeinflusst (https://developers.google.com/search/docs/crawling-indexing/google-common-crawlers). Zum neuen gemeinsamen Signal haben wir den Artikeltext nicht prüfen können.

Ersetzt eine llms.txt das Signal? Dieser Beitrag behandelt die llms.txt nicht und stützt sich dazu auf keine Quelle. Das Signal gehört, wie oben beschrieben, in die robots.txt. Verlass dich für die Trainingsnutzung deshalb nicht auf eine andere Datei, sondern prüfe die Dokumentation des jeweiligen Anbieters.