KI-Training per robots.txt ablehnen mit __usage_ai-training: Googles Zuordnung trifft künftig auch das Grounding in Gemini

Die robots.txt dieser Seite hat eine Handvoll Zeilen, und eine davon lautet Content-Signal: ai-train=yes, search=yes, ai-input=yes. Ich habe sie im April eingetragen, zum Teil, um einen Agent-Readiness-Scanner zu bestehen. Am 30. Oktober kamen drei Dinge auf einmal: ein IETF-Entwurf, der einen gemeinsamen robots.txt-Token für KI-Training definiert, ein Post von Google, dass Google ihn beachten wird, und ein Post von OpenAI, der dasselbe sagt. Keiner der drei erwähnt meine Zeile.

Für mich ist das in Ordnung, denn ich will alles erlauben, und erlaubt ist ungefähr das, was passiert, wenn man nichts sagt. Weniger in Ordnung ist es für alle, die Nein zum Training und Ja zu allem anderen sagen wollen. Bei Google reicht der neue Token nämlich weiter als seine eigene Definition.

Was ist der robots.txt-Token __usage_ai-training?

Eine ganz normale robots.txt-Gruppe, deren User-Agent-Zeile einen Zweck statt eines Crawlers nennt. Disallow darunter bedeutet eine Präferenz gegen KI-Training für diese Pfade, Allow eine Präferenz dafür, und fehlt die Gruppe, gibt es gar keine Präferenz. Der Entwurf führt keine neuen Direktiven und keine neue Grammatik ein.

Der Entwurf ist draft-kelley-aipref-training-preference-signal-00, geschrieben von Kevin Kelley von Anthropic und am 30. Oktober veröffentlicht. Es ist eine Einzeleinreichung: Das Dokument sagt selbst, dass die IETF es nicht unterstützt und es keinen formellen Status hat. Die Definition von KI-Training übernimmt es aus dem Vokabular-Entwurf der AIPREF-Arbeitsgruppe. Training heißt dort, ein Asset zu nutzen, „to modify the learned parameters of a generative AI model“. Das Beispiel aus dem Entwurf:

User-Agent: __usage_ai-training
Disallow: /
Allow: /press-kit/

Zwei Regeln darin sind wichtiger als das Beispiel. Der Token ist keine Crawl-Direktive: Ein Crawler, der ihn beachtet, darf die Seite trotzdem abrufen, und Crawl-Grenzen bleiben beim eigenen Produkt-Token des jeweiligen Crawlers. Und die Wildcard-Gruppe zählt nicht:

Wildcard groups (User-Agent: *) MUST NOT be interpreted as
matching the policy token.

Eine Datei, deren einzige Gruppe User-Agent: * mit Disallow: / ist, sagt Crawlern also „crawl mich nicht“ und sagt über Training überhaupt nichts.

Was haben Google und OpenAI zum gemeinsamen KI-Training-Token angekündigt?

Google hat eine Zuordnung und ein Zieljahr angekündigt, OpenAI will „a common signal“ beachten, ohne Token oder Datum zu nennen. Umgesetzt hat noch keiner etwas.

Googles Post von John Mueller sagt, was der Token konkret für Google bedeuten wird:

When a website uses this policy token to opt out of training
in its robots.txt file (and Google-Extended is not explicitly
specified), Google plans to interpret that as if the publisher
had disallowed Google-Extended.

Laut Post will Google den Token „in 2027“ unterstützen. Die am selben Tag aktualisierte Crawler-Dokumentation sagt „early 2027“ und nennt den Token. Bestehende Steuerungen wie Google-Extended funktionieren weiter daneben.

Der Post von OpenAI sagt, OpenAI werde ein gemeinsames Signal in der robots.txt „for foundational generative AI training“ beachten, plane die Umsetzung „in the coming months“ und verspricht einen zweiten Post mit Details. Die bestehenden Crawler-Steuerungen bleiben in Kraft. Wie das Signal mit GPTBot zusammenspielt, soll erst dieser zweite Post klären.

Fliegt eine Seite aus dem Gemini-Grounding, wenn sie KI-Training mit dem gemeinsamen Token ablehnt?

Liest man Googles zwei Dokumente zusammen: ja, sobald die Zuordnung live ist. Der Token lehnt Training ab, Google will daraus ein Disallow für Google-Extended machen, und Google-Extended war nie nur eine Trainingssteuerung. So beschreibt die Crawler-Dokumentation, was es regelt:

Google-Extended is a standalone product token that web
publishers can use to manage whether content Google crawls
from their sites may be used for training future generations
of Gemini models that power Gemini Apps and Vertex AI API for
Gemini and for grounding (providing content from the Google
Search index to the model at prompt time to improve factuality
and relevancy) in Gemini Apps and Grounding with Google Search
on Vertex AI.

Und der Blogpost, einen Absatz nach der Zuordnung:

Websites that specifically allow Google-Extended are eligible
to appear in responses and receive clicks via grounding in
Gemini Apps.

Der Entwurf definiert eine Trainingspräferenz und bezeichnet Nutzungspräferenzen als unabhängig von allem anderen. Google, bisher der einzige Anbieter, der gesagt hat, wie er den Token lesen wird, liest ein Training-Opt-out als Opt-out für Google-Extended. Und Google-Extended bündelt Training mit dem Grounding in den Gemini Apps und auf Vertex AI. Wer nur „trainiere nicht mit meinen Inhalten“ meinte, fällt damit auch aus dem Grounding, das in den Gemini Apps Quellen zitiert und verlinkt. Google stellt das nicht als Kosten dar: Der Post sagt einen Absatz nach der Zuordnung, was ein Allow für Google-Extended einbringt, und überlässt dem Leser die Rechnung. Diese Rechnung ist meine Lesart der beiden Dokumente nebeneinander. Die Google-Suche selbst, inklusive ihrer KI-Funktionen, hat eine eigene Steuerung und ist nicht betroffen.

Der Ausweg steht in der Vorrangregel im selben Satz: Die Zuordnung gilt nur, wenn Google-Extended „is not explicitly specified“. Schreib ein explizites Allow für Google-Extended, und Google liest stattdessen das. Nur deckt dieses Allow auch Training ab. Mit den robots.txt-Steuerungen, die Google heute dokumentiert, sind Gemini-Training und Gemini-Grounding ein einziger Schalter.

OpenAI trennt die beiden. Die Crawler-Dokumentation nennt jede Einstellung „independent of the others“: GPTBot ist die Trainingssteuerung, OAI-SearchBot entscheidet, ob eine Seite in den Antworten der ChatGPT-Suche erscheint. Ein dritter Agent, ChatGPT-User, ruft Seiten ab, wenn ein Nutzer darum bittet, und über ihn sagt OpenAI: „robots.txt rules may not apply“.

Wo gehört Cloudflares Content-Signal neben Google-Extended und dem Token hin?

Content-Signal ist ein eigenes Vokabular von Cloudflare, im September 2025 veröffentlicht, und steht in der Gruppe User-Agent: *. Nach der Wildcard-Regel des neuen Entwurfs spricht nichts in dieser Gruppe für den Token, und weder Google noch OpenAI erwähnen Content-Signal in ihren Posts.

Seine Zeile ist es trotzdem wert: Es ist der einzige der drei Mechanismen mit einem Wort für Grounding. Es definiert drei Signale:

search : building a search index and providing search results
  (e.g., returning hyperlinks and short excerpts from your
  website's contents). Search does not include providing
  AI-generated search summaries.
ai-input : inputting content into one or more AI models (e.g.,
  retrieval augmented generation, grounding, or other real-time
  taking of content for generative AI search answers)
ai-train : training or fine-tuning AI models

Das AIPREF-Vokabular hat ähnliche Kategorien (AI Training, AI Use, Search), deren Definitionen nicht genau passen, und der Entwurf vom 30. Oktober macht nur aus der ersten einen Token. Stand heute:

Content-Signal bringt außerdem einen juristischen Absatz mit: Cloudflares vorgeschlagener Policy-Text nennt jede Einschränkung einen ausdrücklichen Rechtevorbehalt nach Artikel 4 der EU-Urheberrechtsrichtlinie. Der Trainings-Token erhebt keinen solchen Anspruch.

Warum liest ein normaler robots.txt-Parser den Token __usage_ai-training falsch?

Weil ein Standard-Parser eine Crawl-Frage beantwortet, und der Token ist eine Präferenzfrage. Nach RFC 9309 gilt * für jeden Crawler ohne eigene Gruppe. Ein Parser behandelt den Token also als einen weiteren Crawlernamen und gibt Ja oder Nein zurück, wo der Entwurf eine dritte Antwort will: keine Präferenz. Pythons eingebauter Parser, zum Token befragt, gegen vier Dateien:

from urllib.robotparser import RobotFileParser
def check(name, txt, path="/post"):
    rp = RobotFileParser(); rp.parse(txt.splitlines())
    print(name, rp.can_fetch("__usage_ai-training", "https://example.com" + path))
check("star-disallow", "User-Agent: *\nDisallow: /\n")
check("star-allow", "User-Agent: *\nAllow: /\n")
check("token-disallow", "User-Agent: __usage_ai-training\nDisallow: /\n\nUser-Agent: *\nAllow: /\n")
check("draft-example", "User-Agent: __usage_ai-training\nDisallow: /\nAllow: /press-kit/\n", "/press-kit/logo.png")

Ausgabe unter Python 3.12.3:

star-disallow False
star-allow True
token-disallow False
draft-example False

Nach den Regeln des Entwurfs müssten die ersten beiden „keine Präferenz“ ergeben, nicht ein Opt-out und ein Opt-in. Eine Staging-Seite mit Disallow: / für alle hat damit kein Training abgelehnt. Nur das dritte Ergebnis stimmt. Das vierte ist das Beispiel aus dem Entwurf selbst, und hier irrt der Parser aus einem anderen Grund: Er nimmt die erste passende Regel, obwohl nach RFC 9309 der längste Treffer gewinnt, also gilt /press-kit/ als abgelehnt. Ein Prüfer für diesen Token braucht drei Dinge, die eine Crawl-Bibliothek nicht liefert: die Wildcard-Ausnahme, den Vorrang des längsten Treffers und einen Zustand „keine Präferenz“. Wenn du robots.txt-Dateien mit einem fertigen Parser prüfst, sieh dir die Token-Gruppe von Hand an.

Welche robots.txt du 2027 für KI-Training schreiben solltest

Entscheide, welche von drei Absichten du hast, und schreib sie aus. Jeden der impliziten Fälle oben lesen verschiedene Konsumenten verschieden. In jeder Datei trägt die Gruppe * die Standard-Crawlregeln, und die Anbieter-Gruppen sind die Ausnahmen. Der gemeinsame Token erreicht nur teilnehmende Anbieter, deshalb setzt jede Datei auch die heutigen Anbieter-Steuerungen. Die wirken schon jetzt und wirken weiter, wenn der Token kommt.

Kein Training durch teilnehmende Anbieter, und du nimmst in Kauf, das Gemini-Grounding zu verlieren:

User-Agent: __usage_ai-training
Disallow: /
 
User-Agent: Google-Extended
Disallow: /
 
User-Agent: GPTBot
Disallow: /
 
User-Agent: *
Allow: /

Kein Training außer durch Google, um im Gemini-Grounding zu bleiben. Gemini-Training ablehnen und Gemini-Grounding behalten geht nicht. Am nächsten kommt eine Datei, die mit dem Token und GPTBot ablehnt und Google-Extended ausdrücklich erlaubt. Das heißt, Google darf trainieren:

User-Agent: __usage_ai-training
Disallow: /
 
User-Agent: Google-Extended
Allow: /
 
User-Agent: GPTBot
Disallow: /
 
User-Agent: *
Allow: /

Ja zu allem:

User-Agent: __usage_ai-training
Allow: /
 
User-Agent: Google-Extended
Allow: /
 
User-Agent: *
Allow: /
 
Content-Signal: ai-train=yes, search=yes, ai-input=yes

Die letzte ist meine Absicht. Meine Datei hat heute die Gruppe *, die Content-Signal-Zeile und eine Sitemap, aber keine expliziten Gruppen, weil sie älter ist als der Token. Nach den normalen robots.txt-Regeln erlaubt die Gruppe * Google-Extended bereits. Die explizite Gruppe steht wegen eines Worts in Googles Post da: Seiten, die Google-Extended „specifically allow“, kommen für das Grounding in Frage, und der Post sagt nicht, ob ein Standard-Allow zählt.

Zwei Mechaniken solltest du kennen, wenn du das in eine bestehende Datei einbaust: Zwei Gruppen für denselben User-Agent werden zusammengeführt, nicht nach Position überschrieben. Und innerhalb einer Gruppe gewinnt der längste passende Pfad, bei Gleichstand gewinnt Allow.

Was verrät die robots.txt nicht über den Zugriff von KI-Crawlern?

Ob überhaupt jemand reinkommt. Die robots.txt ist eine Präferenz, die du veröffentlichst. Welchen Zugriff du tatsächlich gewährst, entscheidet deine Edge. Letzte Woche, als ich meine eigenen Seiten auf offene Pfade geprüft habe, hat der Bot-Schutz der Plattform die Anfragen hinter eine Challenge gestellt, und der Uptime-Monitor meldete die Seite als down, bis sie wieder aufgehoben war. Eine Datei, die jedem KI-Crawler Ja sagt, kann vor einer Edge stehen, die manchmal Nein sagt. Wenn es dir wichtig ist, von KI-Systemen gelesen zu werden, prüf die Edge-Logs auf die Crawler, die du erlaubt hast, und miss, ob Antworten dich zitieren, statt der Datei zu vertrauen.

Ist das Training-Opt-out per robots.txt der Teil, der für Publisher zählt?

Meine Einschätzung: Für die meisten Seiten ist es die kleinere Hälfte. Training verändert, was die nächste Modellgeneration weiß, langsam und ohne Link zurück. Grounding ist Abruf im Moment der Antwort, der Schritt, in dem eine Antwort eine Seite zitieren und einen Klick schicken kann. Genau diesen Zweck deckt der gemeinsame Token nicht ab, außer bei Google, wo er ihn zusammen mit dem Training abschaltet.

Meine Seite verkauft nichts und hat keine Werbung, also ist jeder Agent, der sie liest, Distribution, und Ja zu allem ist die billige Wahl. Noch liest niemand den Token. Was du heute schreibst, ist eine Wette darauf, wie zwei Anbieter ihn nächstes Jahr umsetzen.