OpenAI und IETF AI-Training-Signal 2026: 9 robots.txt-Prüfungen
OpenAI plant Support für ein gemeinsames AI-Training-Signal. Ordne Draft-Status, Crawling und Pfadregeln mit neun Prüfungen sauber ein.
OpenAI hat am 30. Oktober 2026 angekündigt, ein gemeinsames, maschinenlesbares Signal in robots.txt für Präferenzen zum Training generativer AI zu respektieren. Der vorgeschlagene Policy-Token heißt __usage_ai-training. Er stammt aus einem aktuellen Internet-Draft, der an die Arbeit der IETF-Arbeitsgruppe AI Preferences anknüpft.
Für deutsche Publisher, Shops, Agenturen und Unternehmen ist das relevant, weil ein einziges Signal künftig mehreren teilnehmenden Anbietern dieselbe Präferenz mitteilen könnte. Aber die Ankündigung ist kein fertiger Standard und kein technischer Sperrmechanismus. OpenAI plant die Umsetzung erst in den kommenden Monaten; der zugrunde liegende Entwurf kann sich noch ändern.
Diese Anleitung übersetzt die Primärquellen in einen vorsichtigen Rollout. Sie ersetzt keine Rechtsberatung und verspricht weder Schutz vor unbefugter Nutzung noch bessere Rankings, Sichtbarkeit oder Umsätze. Entscheidend ist, Crawling, Suche, generatives Training und private Vereinbarungen getrennt zu behandeln.
Inhaltsverzeichnis
- OpenAI und das IETF AI-Training-Signal: Was neu ist
- Was __usage_ai-training ausdrückt – und was nicht
- Why this matters: Eine Präferenz ist noch keine Durchsetzung
- robots.txt sauber von Crawling und Indexierung trennen
- Neun Prüfungen vor einer Änderung am AI-Training-Signal
- Sieben-Tage-Rollout für Publisher und Website-Teams
- FAQ: OpenAI, IETF und AI-Training-Präferenzen
- Sources: Primärquellen und Grenzen
- Related Resources: AI-Crawler-Governance und Umsetzung
OpenAI und das IETF AI-Training-Signal: Was neu ist
OpenAI beschreibt das Vorhaben als freiwillige gemeinsame Sprache für Website-Betreiber. Bisher mussten Teams häufig einzelne Bots und anbieterspezifische Regeln pflegen. Der neue Ansatz soll eine Präferenz für einen bestimmten Nutzungszweck an Pfade binden, ohne neue robots.txt-Direktiven oder eine neue Grammatik einzuführen.
Der aktuelle Entwurf nutzt einen normalen User-Agent-Eintrag als Policy-Token. Ein vereinfachtes Beispiel lautet: User-Agent: __usage_ai-training und darunter Disallow: /. Damit wird nach dem Entwurf eine Präferenz gegen Training generativer AI für alle Pfade ausgedrückt. Mit einer spezifischen Allow-Regel können einzelne Bereiche, etwa ein Pressekit, ausgenommen werden.
Wichtig: Der IETF Datatracker kennzeichnet das Dokument als individuellen Internet-Draft ohne formalen Status. Es ist nicht von der IETF gebilligt, kann ersetzt werden und läuft in der aktuellen Fassung am 3. Mai 2027 aus. OpenAI sagt lediglich, dass es das gemeinsame Signal in den kommenden Monaten implementieren und später Details veröffentlichen will.
Was __usage_ai-training ausdrückt – und was nicht
Der Entwurf definiert AI Training als Nutzung eines Assets, um gelernte Parameter eines generativen AI-Modells zu verändern. Klassifikation, Ranking oder Scoring fallen nicht automatisch darunter, selbst wenn ein System Erklärungen erzeugt. Deshalb sollte ein Team nicht annehmen, dass der Token jede Form automatisierter Verarbeitung erfasst.
- Disallow für den Policy-Token: Präferenz gegen den beschriebenen Trainingszweck.
- Allow für einen Pfad: Präferenz zugunsten dieses Nutzungszwecks für den passenden Pfad.
- Kein passender Eintrag: Nach dem Entwurf wurde keine Präferenz ausgedrückt.
- User-Agent: *: Darf nicht als Ersatz für den speziellen Policy-Token interpretiert werden.
Das Signal ändert keine Eigentumsrechte, Lizenzen oder Verträge. Der Entwurf sagt ausdrücklich, dass private Vereinbarungen die veröffentlichte Präferenz übersteuern können. Auch ein nicht teilnehmender Anbieter ist technisch nicht gezwungen, den Token auszuwerten. Dokumentation und Governance bleiben deshalb ebenso wichtig wie die Syntax.
Why this matters: Eine Präferenz ist noch keine Durchsetzung
Das Signal kann operative Arbeit reduzieren: Statt für jeden neuen Anbieter eine eigene Zeile zu recherchieren, lässt sich eine gemeinsame Grundpräferenz formulieren. Das hilft vor allem Teams mit mehreren Domains, Sprachversionen, Archiven, Pressebereichen oder lizenzierten Inhalten.
Eine Präferenz ist jedoch keine Firewall. robots.txt ist öffentlich lesbar und basiert auf freiwilliger Befolgung. Der Policy-Token ist laut Entwurf außerdem kein Befehl für das Crawling. Ein Verbraucher kann seine Abrufentscheidung daran ausrichten, muss aber Crawling-Regeln für seinen eigenen Bot weiterhin separat auswerten.
Der praktische Gewinn liegt daher in Klarheit und Wartbarkeit. Ein Publisher kann festhalten, welche Inhalte für generatives Training freigegeben oder abgelehnt werden, wann die Entscheidung getroffen wurde und welcher Verantwortliche sie genehmigt hat. Die technische Datei wird damit Teil eines überprüfbaren Prozesses statt einer einmaligen Symbolhandlung.
robots.txt sauber von Crawling und Indexierung trennen
Vier Ebenen werden leicht verwechselt: Abruf durch einen Crawler, Aufnahme in eine Suchmaschine, Nutzung für generatives Training und Darstellung in einem AI-Produkt. Das neue Signal adressiert nur die definierte Nutzungskategorie. Bestehende OpenAI-Botkontrollen bleiben laut Ankündigung bestehen und sollen weiterhin respektiert werden.
| Ebene | Passender Kontrollpunkt | Was das neue Signal nicht beweist |
|---|---|---|
| Technischer Abruf | Anbieterspezifische Crawler-Regeln | Dass jeder Bot blockiert ist |
| Suchindex | Suchmaschinenrichtlinien, Meta-Robots, HTTP-Header | Dass eine Seite aus der Suche verschwindet |
| Generatives Training | __usage_ai-training nach aktuellem Entwurf | Dass alle Anbieter teilnehmen |
| Vertragliche Nutzung | Lizenz, Vertrag und dokumentierte Rechte | Dass robots.txt einen Vertrag ersetzt |
Wer nur den neuen Token ergänzt, sollte bestehende Such- und Crawler-Regeln nicht ungeprüft umschreiben. Eine fehlerhafte globale Disallow-Regel kann Reichweite oder Monitoring beeinträchtigen. Der sichere Weg ist eine kleine, reversible Änderung mit einer vorherigen und nachträglichen Prüfung der öffentlichen Datei.
Ein weiterer Grenzfall sind Inhalte, die über mehrere Systeme ausgeliefert werden. Ein CMS kann die Hauptseite steuern, während Bilder, Downloads, Dokumentation oder internationale Versionen auf anderen Hosts liegen. Die Präferenz der Hauptdomain sagt dann nicht automatisch etwas über diese Assets aus. Prüfe deshalb Host für Host, welche robots.txt-Datei tatsächlich zuständig ist, welche Cache-Schicht sie ausliefert und ob ein CDN eine ältere Variante hält. Dokumentiere außerdem, ob ein Inhalt aus einer API, einem Feed oder einem separaten Medienserver abrufbar bleibt. Diese Inventur verhindert, dass das Team eine vollständige Abdeckung meldet, obwohl nur ein Teil der veröffentlichten Assets erfasst wurde.
Neun Prüfungen vor einer Änderung am AI-Training-Signal
| Prüfung | Nachweis | Stoppsignal |
|---|---|---|
| 1. Zweck | Training, Crawling und Suche getrennt beschrieben | Ein Token soll „alles AI“ blockieren |
| 2. Rechte | Inhalte und Lizenzen den Pfaden zugeordnet | Unklare Drittinhalte |
| 3. Scope | Domain, Subdomain und Sprachpfade erfasst | Ungeprüfte globale Regel |
| 4. Syntax | Aktueller Draft und exakte Schreibweise geprüft | Veraltetes Beispiel |
| 5. Ausnahmen | Erlaubte Presse- oder Dokumentationspfade begründet | Ausnahme ohne Verantwortlichen |
| 6. Bestehende Bots | Vorhandene Regeln unverändert getestet | Such- oder Monitoring-Ausfall |
| 7. Veröffentlichung | robots.txt öffentlich mit Status 200 abrufbar | Redirect-Schleife oder Cache-Drift |
| 8. Protokoll | Diff, Zeitpunkt und Freigabe gespeichert | Keine Rückrollversion |
| 9. Recheck | Termin für OpenAI- und Draft-Update gesetzt | „Einmal einrichten und vergessen“ |
Die Liste ist bewusst konservativ. Sie hilft, eine neue öffentliche Präferenz zu veröffentlichen, ohne andere Ziele zu beschädigen. Für rechtlich sensible Bestände, Lizenzarchive oder Inhalte von Nutzern sollte zusätzlich eine fachliche Rechtsprüfung erfolgen.
Sieben-Tage-Rollout für Publisher und Website-Teams
- Inventar erstellen. Dokumentiere alle robots.txt-Dateien, Domains, CDN-Regeln und Generatoren, die den Inhalt ausliefern.
- Aktuelle Datei sichern. Speichere Statuscode, Body, Cache-Header und Hash als Rückrollbasis.
- Pfadpolitik entwerfen. Lege fest, ob die Präferenz global gilt oder ob Presse, offene Dokumentation oder lizenzierte Bereiche abweichen.
- Staging prüfen. Teste Parser-Verhalten, Suchcrawler-Regeln, Monitoring und die längste passende Pfadregel.
- Klein veröffentlichen. Beginne mit einer kontrollierten Domain oder einem klaren Inhaltsbereich, sofern die Architektur das zulässt.
- Öffentlich zurücklesen. Prüfe die exakte URL aus mehreren Netzen, ohne die Datei nur aus dem Build-Artefakt abzuleiten.
- Nach 24 und 72 Stunden kontrollieren. Vergleiche Datei, Logs, Suche und vereinbarte Monitoring-Signale. Rolle bei unbeabsichtigten Effekten zurück.
- In sieben Tagen entscheiden. Erweitere, halte oder revidiere den Scope und notiere offene Anbieter- und Standardfragen.
Der Rollout misst technische Integrität, nicht die Befolgung durch jeden Anbieter. Für diese Behauptung bräuchte es anbieterspezifische Dokumentation oder belastbare Readbacks. Bis OpenAI Implementierungsdetails veröffentlicht, sollte der Status als angekündigt und noch nicht vollständig ausgerollt geführt werden.
FAQ: OpenAI, IETF und AI-Training-Präferenzen
Ist __usage_ai-training bereits ein IETF-Standard?
Nein. Der zitierte Text ist ein aktiver individueller Internet-Draft ohne formalen Standardstatus. Er ist „work in progress“ und kann sich ändern.
Respektiert OpenAI das Signal schon heute vollständig?
OpenAI hat angekündigt, es in den kommenden Monaten umzusetzen und später Details zu teilen. Die Ankündigung belegt noch keinen vollständigen aktuellen Rollout.
Blockiert der Token Webcrawler?
Nicht automatisch. Der Entwurf trennt Nutzungspräferenz und Traffic-Steuerung. Für Crawling gelten weiterhin die Regeln des jeweiligen Bot-Produkt-Tokens.
Ersetzt das Signal OpenAI-spezifische Botregeln?
Nein. OpenAI erklärt, dass seine bestehenden Crawler-Kontrollen weiter gelten und respektiert werden sollen.
Kann ich einzelne Pfade erlauben?
Der Entwurf sieht pfadspezifische Regeln und Longest-Match-Verhalten wie bei robots.txt vor. Prüfe vor Veröffentlichung immer die aktuelle Draft-Version.
Sources: Primärquellen und Grenzen
- OpenAI: Making it easier for websites to express AI training preferences, 30. Oktober 2026. Primärquelle für die angekündigte Unterstützung, den geplanten Zeitrahmen und den Fortbestand bestehender Crawler-Kontrollen.
- IETF Datatracker: Machine-Readable Training Preference Signal, Version 00 vom 30. Oktober 2026. Primärquelle für Token, Semantik, Pfadlogik und Draft-Status.
- OpenAI: Overview of OpenAI Crawlers. Offizielle Referenz für die getrennten OpenAI-Crawler-Kontrollen.
Alle Aussagen zum künftigen Support sind als OpenAI-Ankündigung formuliert. Die Checkliste und der Sieben-Tage-Rollout sind redaktionelle Empfehlungen von Crescitaly. Sie garantieren keine Durchsetzung, Rechtswirkung, Indexierung, AI-Sichtbarkeit oder kommerziellen Ergebnisse.
Related Resources: AI-Crawler-Governance und Umsetzung
Als Hintergrund zu früheren, anbieterspezifischen Konflikten hilft die Analyse News Sites AI Crawler Policy 2026. Der neue Artikel behandelt dagegen den konkreten gemeinsamen Token vom 30. Oktober, seinen unfertigen Standardstatus und einen lokalisierten Governance-Rollout für deutsche Website-Teams.
Wenn dein Team Richtlinien, Inhalte und Messung in einen kontrollierten Prozess übersetzen möchte, findest du bei den Services von Crescitaly Unterstützung für Strategie, Content Operations und digitale Sichtbarkeit. Starte mit Inventar, Verantwortlichkeit und Rückrollplan.
Für bereits validierte Kampagnen und operative Social-Media-Ziele kannst du separat das SMM Panel von Crescitaly prüfen. Es ersetzt weder robots.txt-Governance noch Content- oder Rechteentscheidungen und garantiert keine Performance.
