Die robots.txt ist seit Jahrzehnten die einfachste Steuerungsdatei im Web: eine Textdatei im Wurzelverzeichnis einer Domain, in der Betreiber festlegen, welche automatisierten Programme welche Bereiche abrufen dürfen. Mit dem Aufkommen von KI-Crawlern – also Programmen, die Inhalte nicht für die Suche, sondern für das Training von Sprachmodellen einsammeln – ist diese Datei unübersichtlich geworden. Für nahezu jeden Anbieter existiert ein eigener Bezeichner, der einzeln eingetragen werden muss.

Google will das ändern. Nach übereinstimmenden Berichten treibt der Konzern ein anbieterübergreifendes Token voran, das in der IETF standardisiert werden soll. Die IETF (Internet Engineering Task Force) ist das Gremium, in dem grundlegende Internetstandards abgestimmt werden – auch das Robots Exclusion Protocol, also die robots.txt selbst, wurde dort formal beschrieben. Ab 2027 soll Google ein solches gemeinsames Token auswerten.

Ein Eintrag statt vieler Einzelregeln

Der praktische Kern der Änderung ist schnell erklärt: Statt für jeden KI-Anbieter eine eigene Regel zu pflegen, soll ein einziger Eintrag genügen, um die Nutzung der eigenen Inhalte fürs KI-Training zu untersagen oder zu erlauben. Das reduziert Pflegeaufwand und senkt die Fehlerquote, denn jede manuell gepflegte Liste veraltet in dem Moment, in dem ein neuer Anbieter auf den Markt kommt.

Der bisherige Google-spezifische Bezeichner Google-Extended bleibt laut den vorliegenden Angaben erhalten. Er dient künftig für Ausnahmen – also für den Fall, dass Betreiber für Google eine andere Regel setzen möchten als für den Rest des Marktes. Damit entsteht ein zweistufiges Modell: eine allgemeine Grundsatzentscheidung über das neue Token, darunter bei Bedarf feinere Regeln pro Anbieter.

Das bekannte Grundproblem: Freiwilligkeit

Die zweite Quelle setzt einen anderen Akzent und verweist auf die Schwachstelle des Verfahrens: Die robots.txt wird von vielen KI-Crawlern schlicht ignoriert. Sie ist kein technischer Zugriffsschutz, sondern eine Absichtserklärung. Wer sich nicht daran hält, wird technisch nicht gehindert – die Datei liegt öffentlich lesbar auf dem Server und enthält lediglich Anweisungen, deren Befolgung freiwillig ist.

Genau deshalb wird diskutiert, das Verfahren verbindlicher zu machen. Ein in der IETF verabschiedeter Standard schafft zunächst Klarheit darüber, wie ein Opt-out technisch korrekt auszudrücken ist. Welche Durchsetzungskraft daraus tatsächlich entsteht und wie viele Anbieter sich anschließen, lässt sich aus den vorliegenden Informationen nicht ableiten. Vorsichtig formuliert: Ein einheitliches Token beseitigt die Uneindeutigkeit auf Seiten der Websitebetreiber, nicht aber automatisch das Verhalten unkooperativer Crawler.

Was Betreiber jetzt sinnvoll vorbereiten können

Auch ohne feststehende Details lohnt es sich, die eigene Ausgangslage zu klären. Die folgenden Punkte sind unabhängig vom konkreten Token-Namen nützlich:

  • Bestandsaufnahme: Welche robots.txt-Dateien existieren überhaupt – pro Domain, pro Subdomain, pro Staging-Umgebung? In gewachsenen Setups sind das oft mehr, als die Verantwortlichen vermuten.
  • Verantwortlichkeit klären: Wer entscheidet im Unternehmen darüber, ob Inhalte fürs KI-Training freigegeben werden? Diese Frage ist strategisch und nicht rein technisch – sie berührt Marketing, Recht und Geschäftsführung.
  • Pflegbarkeit herstellen: Die robots.txt sollte nicht als statische Datei im Deployment festbetoniert sein, sondern über das CMS oder eine versionierte Konfiguration änderbar bleiben. In TYPO3 lässt sich die Auslieferung der Datei konfigurativ lösen, statt sie manuell auf dem Server abzulegen.
  • Monitoring der Zugriffe: Serverlogs zeigen, welche Bots tatsächlich unterwegs sind. Ohne diese Datenbasis bleibt jede Diskussion über Crawler-Steuerung theoretisch.
  • Unterscheidung treffen: Suchmaschinen-Crawling und KI-Training sind zwei verschiedene Dinge. Ein pauschales Aussperren kann Sichtbarkeit kosten, wenn die Regeln zu grob formuliert sind.

Zeitlicher Rahmen

Als Zeitpunkt für die Auswertung des neuen Tokens durch Google wird 2027 genannt. Bis dahin bleiben die heutigen anbieterspezifischen Einträge die einzige Möglichkeit, Präferenzen auszudrücken. Wer bereits heute ein Opt-out gesetzt hat, sollte es bestehen lassen und später ergänzen, statt vorzeitig umzustellen.

Einordnung für Web- und Softwareprojekte

Für laufende Projekte heißt das vor allem: Die robots.txt wird von einer technischen Nebensache zu einem Artefakt mit geschäftlicher Relevanz, über das bewusst entschieden werden sollte. Wer die Datei heute so aufsetzt, dass sie ohne Deployment änderbar und klar dokumentiert ist, kann ein künftiges Standard-Token in wenigen Minuten nachziehen. Und wer parallel die tatsächlichen Bot-Zugriffe auswertet, trifft diese Entscheidung auf Basis von Daten statt auf Basis von Annahmen.

Quellen