Zum Inhalt springen
Zurück

llms.txt v2 ist da: Was sich geändert hat und was Sie aktualisieren sollten

Veröffentlicht:  at  10:00 AM

llms.txt v2 ist da: Was sich geändert hat und was Sie aktualisieren sollten

Am 10. August 2026 hat Jeremy Howard die v2 des llms.txt-Vorschlags veröffentlicht, die erste Überarbeitung seit dem Start des Formats im September 2024. Zwei Jahre Praxis haben eine klare Liste hervorgebracht: was fehlte, was mehrdeutig war und was schlicht nicht so genutzt wurde, wie die Spezifikation es annahm.

Zuerst die beruhigende Nachricht: Ihre bestehende llms.txt ist weiterhin gültig. Das Dateiformat selbst hat sich nicht geändert. Geändert hat sich alles drumherum, vor allem die Antwort auf eine Frage, die Tausende Anwender immer wieder gestellt haben.

Das Problem, das v2 löst

v1 sagte Ihnen, Sie sollten eine llms.txt voller Links veröffentlichen und saubere Markdown-Versionen Ihrer Seiten unter page.html.md ausliefern. Aber die beiden Enden wurden nie verbunden.

Howard formuliert es so: Die Datei “verwies Agenten auf Seiten, aber nichts in der Spezifikation sagte ihnen, wo die Markdown-Versionen tatsächlich lagen”.

Ein Agent, der auf https://example.com/docs/auth landete, konnte also zwei einfache Fragen nicht zuverlässig beantworten:

  1. Gibt es eine Markdown-Version dieser Seite, und wo?
  2. Gibt es eine llms.txt, die diese Seite abdeckt, und wo?

Er musste raten: .md anhängen, /llms.txt im Root probieren, auf das Beste hoffen. v2 ersetzt das Raten durch eine Deklaration.

Das ist die zentrale Änderung. v2 empfiehlt zwei standardisierte HTML-Link-Relations:

Sie können sie als <link>-Elemente im <head> ausliefern:

<link rel="alternate" type="text/markdown" href="/docs/page.html.md" />
<link rel="describedby" href="/docs/llms.txt" />

Oder, für die meisten Teams besser, als HTTP-Response-Header Link::

Link: </docs/page.html.md>; rel="alternate"; type="text/markdown", </docs/llms.txt>; rel="describedby"

Warum die Header-Variante wichtig ist: Sie können sie in der Konfiguration Ihres Webservers oder CDN ergänzen, ohne ein einziges Template anzufassen. Sie funktioniert außerdem für Nicht-HTML-Ressourcen, einschließlich der Markdown-Dateien selbst. Wer Cloudflare, Netlify, Vercel oder nginx nutzt, hat hier eine Konfigurationsänderung vor sich, keine Migration.

Und das sind keine erfundenen Konventionen: alternate und describedby sind bereits bei der IANA registrierte Link Relations. v2 nutzt bewusst die vorhandene Web-Infrastruktur, statt eine neue zu erfinden.

Änderung 2: Zwei Markdown-URL-Muster sind jetzt zulässig

v1 legte eine einzige Konvention fest: .md an die vollständige URL anhängen, sodass aus /docs/tutorial.html die Datei /docs/tutorial.html.md wird.

In der Praxis haben viele Publishing-Tools das andere Naheliegende getan und die Endung ersetzt: /docs/tutorial.md. v2 akzeptiert beides.

MusterOriginalMarkdown-Version
.md anhängen/docs/tutorial.html/docs/tutorial.html.md
Endung ersetzen/docs/tutorial.html/docs/tutorial.md
URL ohne Endung/docs/tutorial//docs/tutorial/index.html.md oder /docs/tutorial/index.md

Die Spezifikation merkt dazu an, die Praxis sei “auf eine Weise von v1 abgewichen, die es zu segnen lohnt”. Das ist ein gesunder Umgang mit einem Standard. Kein Muster wird bevorzugt, nutzen Sie also das, was Ihr Stack ohnehin erzeugt, und deklarieren Sie es mit rel="alternate".

Änderung 3: Die Abdeckung von Unterpfaden ist jetzt präzise definiert

Eine llms.txt deckt die URLs unterhalb ihres eigenen Pfads ab, und wenn mehrere Dateien zutreffen, sollen Agenten die spezifischste verwenden. /docs/llms.txt deckt also alles unter /docs/ ab und hat für diese Seiten Vorrang vor einer /llms.txt im Root.

Das ist mehr als eine Klarstellung. Es ist der Grund, warum llms.txt in einem Pfad liegt und nicht unter /.well-known/ (RFC 8615). Well-Known URIs existieren nur im Origin-Root, und viele Autoren kontrollieren lediglich ein Unterverzeichnis: eine GitHub-Pages-Projektseite, einen Docs-Ordner auf einem geteilten Host, den Bereich eines Teams innerhalb einer Firmendomain. Unter v2 kann jeder, der eine Datei in einem Pfad veröffentlichen kann, dafür auch eine llms.txt veröffentlichen.

Wenn Sie Doku, Blog und Marketing-Site unter einer Domain betreiben, können Sie jedem Bereich eine eigene, klar abgegrenzte Datei geben und wissen genau, welche gewinnt.

Änderung 4: llms_txt2ctx fliegt raus, ebenso die “Optional”-Mechanik

v1 lieferte ein CLI-Tool mit, llms_txt2ctx, das eine llms.txt zu einem großen Kontextblock expandierte, wobei der Abschnitt ## Optional eine mechanische Bedeutung trug (bei knappem Kontext überspringen).

v2 entfernt beides aus der Spezifikation. Nicht weil Kontext-Expansion schlecht wäre, sondern weil Agenten sich nicht so verhalten. Echte Agenten sichten oder durchsuchen die llms.txt und folgen dann nur den Links, die sie brauchen. Die Datei bleibt klein genug für den Kontext; die Details liegen hinter den Links und werden bei Bedarf geholt.

## Optional gibt es weiterhin, aber rein als Konvention: sekundäre Links, die ein Agent überspringen kann, wenn er einen kürzeren Kontext will. Ohne angehängte Tooling-Semantik.

Änderung 5: Die Einordnung hat die Realität eingeholt

Der Hintergrundabschnitt von 2024 war eine Vorhersage: dass Agenten routinemäßig Websites lesen würden. v2 schreibt ihn als Beschreibung um, denn das ist inzwischen Alltag.

Die Spezifikation nennt jetzt die Belege: Tausende Sites veröffentlichen die Datei, Dokumentationsplattformen generieren sie automatisch, Chromes Lighthouse prüft im Rahmen seiner Agentic-Browsing-Checks darauf, und die KI-Labore veröffentlichen ihre eigene, OpenAI, Anthropic und das Gemini-Team von Google liefern llms.txt für ihre Entwicklerdokumentation aus.

Was das Format weiterhin verlangt (unverändert)

Eine Wiederholung lohnt sich, denn genau hier passieren die Fehler, und in v2 hat sich davon nichts bewegt:

Jede Dateiliste ist eine Markdown-Liste, in der jeder Eintrag einen Pflicht-Link enthält, optional gefolgt von einem : und Anmerkungen:

# Titel

> Optionale Beschreibung steht hier

Optionale Details stehen hier

## Abschnittsname

- [Linktitel](https://link_url): Optionale Linkdetails

## Optional

- [Linktitel](https://link_url)

Ihre v2-Checkliste

  1. Behalten Sie Ihre bestehende Datei. Sie ist weiterhin spezifikationskonform. Nicht neu schreiben.
  2. Liefern Sie Markdown-Versionen Ihrer wichtigen Seiten aus, in einem der beiden URL-Muster.
  3. Ergänzen Sie die zwei Link Relations, idealerweise als HTTP-Link:-Header auf CDN- oder Serverebene, dann entfallen Template-Änderungen komplett.
  4. Grenzen Sie Ihre Dateien nach Pfad ab, wenn eine Domain mehrere eigenständige Bereiche beherbergt.
  5. Verlinken Sie auf Markdown, nicht auf HTML. Die Links in der llms.txt sollen zu LLM-freundlichen Inhalten führen. Das galt schon in v1 und ist der häufigste Fehler.
  6. Validieren Sie vor dem Ausliefern, damit die veröffentlichte Datei tatsächlich parst.

Eines hat v2 nicht geändert

llms.txt ist weiterhin ein Vorschlag, kein ratifizierter Webstandard, und weiterhin kein Google-Rankingfaktor. Google hat klar gesagt, dass es die Datei nicht verwendet. v2 macht das Format nützlicher für die Agenten, die es tatsächlich lesen, eine reale und wachsende Gruppe, aber es wird dadurch kein SEO-Hebel.

Wenn Ihnen jemand v2 als Ranking-Upgrade verkauft, lesen Sie zuerst Ist llms.txt ein Google-Rankingfaktor?.

Fazit

v2 ist eine kleine, sinnvolle Überarbeitung, die die eine strukturelle Lücke von v1 schließt: Agenten konnten Ihre Datei lesen, sie aber nicht finden, und auch nicht das Markdown, auf das sie verwies. Zwei Link Relations schließen diese Lücke, und eine davon ist eine Zeile CDN-Konfiguration.

Bereit für das Update? Erzeugen Sie eine spezifikationskonforme Datei mit unserem llms.txt-Generator und prüfen Sie sie anschließend mit dem llms.txt-Validator. Wenn Sie noch abwägen, ob sich die Datei für Ihre Website lohnt, beginnen Sie mit Wann llms.txt sinnvoll ist.



Nächster Artikel
Ist llms.txt ein Google-Ranking-Faktor? Nein. Hier erfahren Sie, wofür es eigentlich gedacht ist