llms.txt v2: was sich geändert hat
Veröffentlicht:
Der llms.txt-Vorschlag wurde im August 2026 überarbeitet, fast zwei Jahre nach dem Original. Das Dateiformat selbst hat sich nicht geändert — eine v1-Datei ist weiterhin eine gültige v2-Datei. Geändert hat sich alles rund um die Datei: wie Agenten sie finden und welche Werkzeuge die Spezifikation erwartet.
Das Format bleibt unverändert
Die vorgeschriebene Struktur ist genau wie zuvor: eine optionale BOM, ein H1 mit dem Projektnamen (immer noch das einzige zwingend erforderliche Element), eine Blockquote-Zusammenfassung, optionaler Fließtext ohne Überschriften, danach null oder mehr H2-Abschnitte mit Markdown-Linklisten. Wenn Ihre Datei nach v1 100 Punkte erreichte, erreicht sie sie weiterhin.
1. Link-Relationen, damit Agenten nicht mehr raten müssen
Das ist die substanzielle Ergänzung, und sie beantwortet die häufigste Rückmeldung aus zwei Jahren Praxis: Wie findet ein Agent zu einer Seite deren Markdown-Version oder die llms.txt, die sie abdeckt, ohne URLs zu erraten?
v2 antwortet mit zwei standardisierten Link-Relationen:
rel="describedby"— verweist auf die llms.txt, die diese Seite abdeckt.rel="alternate" type="text/markdown"— verweist auf die Markdown-Version dieser Seite.
Beide können ein HTML-<link>-Element sein:
<link rel="describedby" href="/llms.txt"> <link rel="alternate" type="text/markdown" href="/docs/page.html.md">
… oder ein HTTP-Response-Header, was die einzige Möglichkeit für Nicht-HTML-Ressourcen wie die Markdown-Dateien selbst ist und sich in der Webserver- oder CDN-Konfiguration setzen lässt, ohne eine einzige Seite anzufassen:
Link: </docs/page.html.md>; rel="alternate"; type="text/markdown", </docs/llms.txt>; rel="describedby"
Falls Sie bisher dem Rat gefolgt sind, die Datei mit rel="alternate" type="text/plain" anzukündigen — auch früheren Fassungen unserer eigenen Anleitungen —, ersetzen Sie das durch rel="describedby". Das war eine vernünftige Konvention, solange die Spezifikation keine hatte; jetzt hat sie eine.
2. Beide .md-URL-Formen sind nun erlaubt
v1 legte eine einzige URL-Form für das Markdown-Pendant einer Seite fest: .md an die vollständige Seiten-URL angehängt, aus page.html wurde also page.html.md. In der Praxis ersetzten mehrere Publishing-Werkzeuge stattdessen die Endung und erzeugten page.md. v2 segnet beides ab. Bei URLs ohne Dateinamen hängen Sie index.html.md oder index.md an.
Hier gibt es nichts zu migrieren — welche Form Sie schon ausliefern, ist jetzt korrekt.
3. Dateien in Unterpfaden sind klar definiert
v1 erlaubte eine llms.txt außerhalb des Roots, sagte aber nie, was das bedeutet. v2 definiert es: eine Datei deckt die Seiten unterhalb ihres Pfads ab, und wenn mehrere zutreffen, verwenden Agenten die spezifischste. /docs/llms.txt deckt also alles unter /docs/ ab, und ein Agent, der eine Doku-Seite liest, zieht sie der Root-Datei vor.
Das ist wichtig für alle, die einen Pfad, aber keinen Host kontrollieren — eine GitHub-Pages-Projektseite, ein Doku-Bereich auf einer geteilten Domain — und es ist der Grund, warum die Spezifikation bei einem konventionellen Dateinamen bleibt statt /.well-known/, das immer nur im Origin-Root existiert.
Praktische Folge: Wenn Ihre Dokumentation der Teil ist, der Agenten interessiert, ist eine darauf zugeschnittene /docs/llms.txt nun eine erstklassige Option und keine Grauzone.
4. Kontext-Expansions-Werkzeuge sind raus (und „Optional“ verlor seine Mechanik)
v1 beschrieb llms_txt2ctx, ein Werkzeug, das eine llms.txt zu einem einzigen LLM-Kontext expandierte. v2 lässt es fallen und formuliert die Erwartung stattdessen direkt: Agenten sehen oder durchsuchen die llms.txt und folgen dann den Links, die sie brauchen — die Links sollten also auf LLM-freundliche Inhalte zeigen, und die Datei selbst bleibt klein genug, um in den Kontext zu passen.
Mit diesem Werkzeug entfällt auch die mechanische Bedeutung des Abschnitts ## Optional, die existierte, um solchen Werkzeugen zu sagen, was sie auslassen sollen. Optional-Abschnitte sind weiterhin erlaubt und weiterhin eine nützliche Konvention für sekundäre Links, die ein Agent überspringen kann — sie steuern nur nichts Automatisches mehr.
Beachten Sie: llms-full.txt war in keiner der beiden Versionen Teil der Spezifikation. Es ist eine weit verbreitete Branchenpraxis und für große Dokumentationsbestände eine gute — behandeln Sie es nur nicht als Pflicht.
Was Sie diese Woche konkret tun sollten
- Fügen Sie
rel="describedby"mit Verweis auf Ihre llms.txt hinzu — eine Zeile im Layout oder eine Header-Regel im CDN. - Wenn Sie Markdown-Pendants veröffentlichen, kündigen Sie sie mit
rel="alternate" type="text/markdown"an. - Ersetzen Sie jeden
rel="alternate" type="text/plain"-Hinweis durchrel="describedby". - Wenn Ihre Doku der wertvolle Teil ist, erwägen Sie eine darauf zugeschnittene
/docs/llms.txt. - Lassen Sie den Validator erneut laufen — er meldet jetzt, ob Ihre Seiten die v2-Relationen ankündigen, und folgt Dateien in Unterpfaden so, wie v2 es für Agenten vorsieht.
Warum es überhaupt eine Revision gab
Weil die Prämisse aufhörte, spekulativ zu sein. Als llms.txt im September 2024 vorgeschlagen wurde, war „Agenten werden Ihre Website lesen“ eine Prognose. Heute erzeugen Doku-Plattformen die Datei automatisch, Chromes Lighthouse prüft Websites im Rahmen seiner Agentic-Browsing-Checks darauf, und die KI-Labore veröffentlichen llms.txt-Dateien für ihre eigenen Entwicklerdokumentationen. v2 ist, wie ein Vorschlag aussieht, nachdem seine Annahmen von echter Verbreitung getestet wurden.