News · Google · robots.txt
Gemeinsames KI-Trainingssignal in robots.txt: Was Googles Plan für 2027 bedeutet
Google will ein gemeinsames Signal für KI-Training in robots.txt unterstützen. Der Vorschlag ist noch nicht in Kraft: Der zugrunde liegende IETF-Entwurf ist ein individueller Arbeitsstand, und Google peilt die Unterstützung mit weiteren Anbietern für 2027 an.
Kurzfassung
Am 30. Oktober 2026 kündigte Google an, ein gemeinsames maschinenlesbares Signal für KI-Training in robots.txt unterstützen zu wollen. Der Entwurf verwendet den Token __usage_ai-training. Google nennt 2027 als Ziel für die Unterstützung gemeinsam mit weiteren KI-Anbietern.
Für das gemeinsame Signal ändert sich heute noch nichts: Der Token ist kein etablierter, branchenweit unterstützter Standard. Der IETF-Datensatz führt den konkreten Vorschlag als individuellen Internet-Draft ohne formalen Status im Standardisierungsprozess. Googles bestehender Token Google-Extended bleibt bis auf Weiteres die dokumentierte Google-Steuerung für Training und Grounding außerhalb von Google Search.
Inhaltsverzeichnis
Kernaussage
Den neuen Token jetzt nicht als wirksame Sperre einplanen.
Die Richtung ist relevant, aber Support und Standardstatus fehlen noch. Erst festlegen, welche Nutzung erlaubt sein soll; die technische Umsetzung folgt, wenn Anbieter ihre Unterstützung bestätigt haben.
1. Was Google angekündigt hat
In seiner Ankündigung vom 30. Oktober beschreibt Google einen gemeinsamen Policy-Token für robots.txt. Website-Betreiber sollen damit ihre Präferenz zum KI-Training gegenüber mehreren teilnehmenden Anbietern mit einem Signal ausdrücken können, statt für jeden Anbieter eine eigene Regel zu pflegen. Einzelne Anbieter-Controls wie Google-Extended sollen daneben bestehen bleiben.
Die Ankündigung vom 30. Oktober ist ein Plan, kein Rollout-Bericht. Google peilt die Unterstützung im Jahr 2027 an und sagt, dass es den Fortschritt weiter kommunizieren will. Es gibt damit noch keine Grundlage dafür, dass ein heute ergänzter gemeinsamer Token von allen relevanten Crawlern oder KI-Anbietern ausgewertet wird.
| Punkt | Stand am 06.11.2026 | Bedeutung |
|---|---|---|
| Google-Ankündigung | Unterstützung ist geplant; Ziel ist 2027. | Noch keine sofort wirksame neue Google-Regel. |
| IETF-Dokument | Individueller Internet-Draft, nicht formell von der IETF bestätigt. | Arbeitsstand, kein verabschiedeter Standard. |
| Bestehender Google-Control | Google-Extended ist dokumentiert verfügbar. | Kann separat von Google Search bewertet werden. |
2. Was der Token im Entwurf bedeutet
Der am 30. Oktober veröffentlichte IETF-Draft zeigt die Regel mit einem eigenen User-Agent-Token. Im Beispiel ist KI-Training für alle Pfade unerwünscht, außer für das Medienkit:
User-agent: __usage_ai-training
Disallow: /
Allow: /press-kit/Das Beispiel beschreibt eine Nutzungspräferenz: Der Inhalt soll nicht zum Training verwendet werden, mit einer Ausnahme für /press-kit/. Der Draft ergänzt keine neue Direktive und verändert auch nicht die üblichen Regeln zur Pfadzuordnung.
Wichtig: Der Code ist ein Beispiel aus einem Entwurf
Die Regel heute einzutragen garantiert keine Wirkung. Laut IETF-Datensatz ist der Draft nicht von der IETF bestätigt und hat keinen formalen Status im Standardisierungsprozess. Ein Anbieter muss den Token tatsächlich unterstützen und die Präferenz auswerten.
Der Policy-Token ist außerdem kein Crawler-Name: __usage_ai-training muss nicht im HTTP-User-Agent einer Anfrage erscheinen. Wer Server-Logs nach diesem String filtert, sieht dadurch also nicht automatisch, welcher Bot eine Seite abgerufen hat.
3. Crawling und Nutzung sauber trennen
Ein häufiger Denkfehler: Ein Signal zu KI-Training wird als Bot-Sperre behandelt. Der Draft sagt ausdrücklich, dass der Policy-Token keine Direktive für das Crawling ist. Regeln für die Verwendung von Inhalten und Regeln für den Abruf einer URL sind zwei verschiedene Steuerungen.
| Steuerung | Wofür sie steht | Wofür sie nicht steht |
|---|---|---|
| Crawler-Regel für einen Anbieter | Teilt regelkonformen Crawlern mit, welche Pfade sie abrufen dürfen. | Keine technische Zugriffssperre für nicht regelkonforme Bots. |
| Gemeinsamer Policy-Token | Drückt im Entwurf eine Präferenz zur Nutzung für KI-Training aus. | Stoppt nicht automatisch HTTP-Anfragen oder das Crawling. |
| Authentifizierung und Zugriffsschutz | Begrenzt den Zugriff auf geschützte Inhalte. | Wird durch robots.txt nicht ersetzt. |
RFC 9309 hält ausdrücklich fest, dass robots.txt-Regeln keine Zugriffserlaubnis darstellen. Für vertrauliche, bezahlte oder personenbezogene Inhalte braucht es Zugriffskontrollen auf Server- oder Anwendungsebene. Für unerwünschte Bot-Last sind Rate Limits, Firewall-Regeln und verlässliche Bot-Prüfung die passenden Werkzeuge; ein Trainingstoken erfüllt diese Aufgaben nicht.
4. Was heute schon mit Google-Extended gilt
Google dokumentiert Google-Extended in der Übersicht seiner Crawler und Fetcher als eigenständigen Token in robots.txt. Google beschreibt ihn als Steuerung dafür, ob abgerufene Inhalte zum Training künftiger Gemini-Modelle und zum Grounding in Gemini Apps sowie bestimmten Vertex-AI-Anwendungen genutzt werden können. Für Google Search gilt diese Steuerung laut Google nicht: Sie beeinflusst weder die Aufnahme einer Website in die Suche noch das Ranking.
Damit sind drei Entscheidungen getrennt zu treffen: Soll Googlebot eine Seite für Search abrufen? Soll Google-Extended Inhalte für die dokumentierten Gemini- und Vertex-AI-Zwecke verwenden? Und was soll für Training bei anderen Anbietern gelten? Das angekündigte gemeinsame Signal soll künftig die letzte Frage übergreifender abbilden; es hebt die anbieterspezifischen Regeln nicht auf.
Keine Garantie auf AI-Sichtbarkeit
Ein erlaubter Abruf oder ein erlaubtes Grounding ist keine Zusage, dass eine Seite in einer Antwort erscheint. Umgekehrt ist Google-Extended laut Google kein Schalter für die normale Google-Suche.
5. Was SEO- und Webteams jetzt tun sollten
Die Ankündigung ist ein guter Anlass, die eigene Steuerung zu ordnen. Eine vorschnelle globale Sperre kann Suchzugriff und AI-Nutzung vermischen; ein neues Token ohne Anbietersupport kann falsche Sicherheit erzeugen.
- Bestehende Regeln erfassen: Prüft
robots.txt, Meta-Robots, HTTP-Header, Login-Schranken und Bot-Schutz getrennt voneinander. - Inhalte nach Zweck sortieren: Öffentliche Ratgeber, Produktdokumentation, exklusive Daten und geschützte Bereiche können unterschiedliche Freigaben benötigen.
- Google-Extended bewusst entscheiden: Bewertet Training und Grounding in Gemini/Vertex getrennt von der Sichtbarkeit in Google Search.
- Den Draft beobachten: Wartet auf bestätigte Implementierungsdetails und dokumentierte Unterstützung der Anbieter, bevor ihr den gemeinsamen Token als Control behandelt.
- Änderungen protokollieren: Haltet fest, wer Regeln ändert, welche Inhalte betroffen sind und wie sich Abrufe und Sichtbarkeit danach entwickeln.
Für Inhalte, die nicht öffentlich abgerufen werden sollen, bleibt Zugriffsschutz die unmittelbare Maßnahme. Für öffentlich indexierbare Inhalte ist die zentrale Frage eine redaktionelle und geschäftliche: Welche Nutzungen wollt ihr erlauben, und welche Reichweite könnte eine Einschränkung kosten?
6. FAQ
Ist das gemeinsame KI-Trainingssignal schon ein offizieller IETF-Standard?
Nein. Der konkrete Token steht in einem individuellen Internet-Draft, der laut IETF-Datensatz nicht von der Organisation bestätigt wurde und keinen formalen Status im Standardisierungsprozess hat.
Sollte ich __usage_ai-training jetzt in meine robots.txt aufnehmen?
Nicht mit der Erwartung, damit bereits Anbieter zu steuern. Google peilt die Unterstützung für 2027 an. Wartet auf konkrete Anbieterangaben und prüft den finalen Stand des Standards.
Blockiert Google-Extended eine Website in Google Search?
Laut Google nein. Google-Extended wirkt sich nicht auf die Aufnahme einer Website in Google Search oder auf das Ranking aus.
Verhindert robots.txt, dass Bots geschützte Inhalte abrufen?
Nein. RFC 9309 stellt klar, dass robots.txt keine Zugriffskontrolle ist. Vertrauliche Inhalte müssen mit Authentifizierung oder einer anderen wirksamen Zugriffssperre geschützt werden.
7. Primärquellen
Stand der Einordnung: 06.11.2026. Aussagen sind anhand der Dokumentation von Google, IETF und RFC Editor eingeordnet.
- Google Search Central: Supporting a shared AI training control for websites — Ankündigung vom 30. Oktober 2026, Grundidee des gemeinsamen Tokens und Googles Ziel für 2027.
- IETF Datatracker: Machine-Readable Training Preference Signal — Arbeitsentwurf, Beispielsyntax und Status als individueller, nicht bestätigter Internet-Draft.
- Google Crawling Infrastructure: Google’s common crawlers — Dokumentation zu Google-Extended und zur geplanten Unterstützung des gemeinsamen Signals.
- RFC 9309: Robots Exclusion Protocol — Geltender Standard für robots.txt und Klarstellung, dass dessen Regeln keine Zugriffserlaubnis darstellen.
Robots-Regeln nach Suchziel statt pauschal setzen
Wer Search-Crawling, KI-Training, Bot-Last und geschützte Inhalte getrennt betrachtet, kann Reichweite und Zugriff sauberer steuern.
Weiterführende Links für diese Seite