Eine robots.txt wiegt ein paar hundert Byte. Weniger als ein einzelnes Icon, ein Bruchteil eines Kommas in der Gesamtbilanz einer Website. Und trotzdem ist sie eine der wirksamsten Dateien, die Du überhaupt ablegen kannst. Denn anders als fast alles andere im Web verursacht sie keinen Datenverkehr, sie verhindert ihn.
Die zwei Erfolgskriterien von Guideline 3.13
Erwartete Dateien: Stelle standardmäßig favicon.ico, robots.txt, opensearch.xml, site.webmanifest und sitemap.xml bereit. Nimm weitere Standarddateien auf, sobald sie zum Standard werden.
Nützliche Dateien: Stelle zusätzliche etablierte Dateien bereit, etwa ads.txt, carbon.txt, humans.txt und security.txt. Nimm weitere Standarddateien auf, sobald sie zum Standard werden.
Meine Einordnung
Die Liste im ersten Kriterium wirkt wie Bürokratie und ist in Wahrheit Ökonomie. Fehlt eine dieser Dateien, fragt jeder Browser und jeder Bot sie trotzdem an und bekommt eine Fehlerseite. Das kostet bei jedem Aufruf eine Anfrage, die niemandem nützt. Vorhanden zu sein ist hier billiger als zu fehlen.
Bei zwei Dateien geht der Nutzen weit darüber hinaus, und das ist der eigentliche Grund, warum sie mir wichtig sind. Robots.txt und sitemap.xml lenken den Datenverkehr von Maschinen. In meinen Audits sehe ich regelmäßig, dass ein erheblicher Teil aller Zugriffe gar nicht von Menschen stammt, sondern von Crawlern. Eine Sitemap sagt ihnen, welche Adressen es gibt und wann sie sich zuletzt geändert haben. Eine robots.txt hält sie von Bereichen fern, die keinen Index brauchen. Beides zusammen erspart Deinem Server unter Umständen tausende überflüssige Seitenauslieferungen. Ein paar hundert Byte, die Megabyte verhindern: Ein besseres Verhältnis von Aufwand zu Wirkung kenne ich im Web nicht.
Die security.txt gehört für mich in dieselbe Kategorie. Sie kostet nichts und beantwortet eine einzige Frage: An wen wendet sich jemand, der eine Sicherheitslücke gefunden hat? Ohne diese Datei sucht der Finder im Impressum, schreibt vielleicht an eine allgemeine Adresse und gibt womöglich auf.
Und die carbon.txt, die ich ebenfalls anbiete, ist die jüngste in dieser Reihe. Sie legt maschinenlesbar offen, wie eine Website gehostet wird und woher der Strom kommt. Anders als eine Behauptung im Fließtext ist das prüfbar.
Wo ich weiter gehe
Beide Kriterien enthalten denselben Halbsatz, und der ist mir der wichtigste im ganzen Abschnitt: sobald sie zum Standard werden. Genau hier trennt sich die Guideline von der Reflexhandlung, jede neu diskutierte Datei sofort anzulegen.
Das aktuelle Beispiel ist die llms.txt, die KI-Systemen erklären soll, welche Inhalte einer Website die wichtigsten sind. Die Idee ist bestechend, gerade für mich: eine kurze, kuratierte Datei statt blinden Durchforstens des gesamten HTML wäre gelebte Datensparsamkeit. Nur hält die Praxis noch nicht mit. Sie ist bis heute kein verabschiedeter Standard, sondern ein Vorschlag. Erhebungen aus der Mitte des Jahres 2026 finden sie bei rund einem Zehntel der untersuchten Domains, und Auswertungen von Bot-Zugriffen zeigen, dass die großen KI-Crawler sie fast nie abrufen und stattdessen weiterhin direkt das HTML lesen. Google hat einer Übernahme ausdrücklich eine Absage erteilt.
Nachweislich genutzt wird sie an einer anderen Stelle, und die passt zu ihrer Herkunft: bei technischen Dokumentationen. Entwicklungswerkzeuge mit KI-Unterstützung holen sich dort gezielt die llms.txt, bevor sie einzelne Seiten nachladen. Wer eine Dokumentationsseite betreibt, hat also einen realen Grund. Wer eine gewöhnliche Unternehmensseite betreibt, legt eine Datei an, die derzeit kaum jemand liest, und muss sie trotzdem pflegen.
Meine Haltung dazu ist deshalb weder Ablehnung noch Eile: beobachten, und den Halbsatz der Guideline ernst nehmen. Wenn sie zum Standard wird, kommt sie dazu. Vorher nicht.
Dein erster Schritt heute
Der schnellste Weg zur Bestandsaufnahme führt nicht über eine Prüfliste, sondern über Dein eigenes Serverprotokoll.
Fang dabei mit der robots.txt und der Sitemap an, denn nur diese beiden verhindern aktiv Datenverkehr. Die übrigen beantworten Fragen, die sonst niemand beantwortet.
Die wirksamsten Dateien im Web sind nicht die, die etwas liefern, sondern die, die verhindern, dass etwas Überflüssiges geliefert wird.
Quelle: W3C-Fassung von Guideline 3.13