llms.txt: nächster Baustein oder Missverständnis? Eine ehrliche Einordnung für 2026

Nach der robots.txt ist die llms.txt der Kandidat für den nächsten „KI-Baustein“ einer Website. Über kaum eine Datei gehen die Meinungen so weit auseinander – sogar innerhalb von Google. Hier die Geschichte, das Für und Wider und unsere begründete Empfehlung für Elbnetz und unsere Kunden.

Das Wichtigste über llms.txt in Kürze

• llms.txt ist eine vorgeschlagene Konvention (Jeremy Howard, Answer.AI, 3. September 2024) – kein offizieller Standard, keine Zugriffssteuerung und kein Trainings-Opt-out.
• Stand 2026 wertet kein großes Antwortsystem (OpenAI, Anthropic, Google, Perplexity) llms.txt für Ranking oder Zitate aus – in Server-Logs fragen die Crawler die Datei meist nicht einmal ab.
• Der scheinbare Google-Widerspruch ist keiner: Google Search nennt die Datei überflüssig (Index/RAG), während Chrome sie im Lighthouse-Audit „Agentic Browsing“ prüft – zwei Teams, zwei Schichten.
• Drei-Phasen-Modell: Beim Training und beim Finden der Quelle (Index) ist llms.txt irrelevant; nutzbar ist sie allenfalls beim agentischen Abrufen im Moment der Antwort.
• Echten Nutzen hat sie heute bei umfangreicher Entwickler-Doku und für eigene oder Partner-KI-Systeme – für eine klassische Marketing-Website ist sie kein Sichtbarkeits-Hebel.
• Die zwei realen Risiken sind Drift (eine zweite, veraltende Wahrheit) und Cloaking (Maschinen sehen andere Inhalte als Menschen).
• Der bessere Baustein ist eine schema-getriebene Grounding Page: Eine Datenquelle speist JSON-LD und sichtbare Seite – das verhindert Drift und Cloaking by design; die llms.txt zeigt nur darauf.
• Empfehlung: Wenn llms.txt, dann automatisch generiert, akkurat, niemals cloakend, niedrige Priorität nach Schema und Inhalten – und quartalsweise prüfen.

Update vom 18. Juni 2026: Lighthouse prüft llms.txt jetzt sichtbar

Seit Mitte Juni 2026 taucht die llms.txt in PageSpeed Insights beziehungsweise Lighthouse sichtbarer in der Kategorie „Agentic Browsing“ auf. Das ändert unsere grundsätzliche Einschätzung nicht: Die Datei ist weiterhin kein bestätigter Rankingfaktor für Google Search und kein Hebel für bessere Platzierungen oder mehr KI-Zitate.

Neu ist aber: Wer eine llms.txt anbietet, sollte sie nicht als beliebigen Hinweistext verstehen, sondern als saubere Markdown-Datei mit klarer Struktur und echten Links. Lighthouse beanstandet beispielsweise Dateien, die zwar vorhanden sind, aber keine erkennbaren Links enthalten. Genau das zeigt, worum es bei der Datei tatsächlich geht: nicht um Suchmaschinenranking, sondern um Orientierung für KI-Agenten, die eine Website live lesen oder bedienen sollen.

Unsere Empfehlung bleibt deshalb: Für klassische Unternehmenswebsites ist die llms.txt kein Muss. Wenn man sie einsetzt, dann schlank, akkurat, mit Links auf die wichtigsten Seiten, die Sitemap und idealerweise eine kanonische Grounding Page. Keine zweite Wahrheit. Kein KI-Marketingtext. Keine Fantasieangaben.

Eine Datei, zwei gegensätzliche Aussagen – vom selben Konzern

Wer sich 2026 über die llms.txt informiert, stößt schnell auf eine irritierende Lage. Auf der einen Seite schreibt Google Search in seinem offiziellen Leitfaden zur Optimierung für generative KI (Stand Mai 2026) ausdrücklich, man könne „unnötige KI-Textdateien (z. B. llms.txt)“ getrost ignorieren. Auf der anderen Seite führt das Chrome-Team in Lighthouse einen eigenen Audit für genau diese Datei – unter der Rubrik „Agentic Browsing“ – und nennt sie eine „aufkommende Konvention“, ohne die Agenten „mehr Zeit mit dem Crawlen der Seite verbringen“ müssten.

Derselbe Konzern, zwei gegenteilige Botschaften. Das ist kein Versehen und kein interner Streit, sondern der Schlüssel zum Verständnis der ganzen Datei. Wir lösen den scheinbaren Widerspruch in diesem Beitrag auf – und sagen klar, was er für eine WordPress-Website 2026 bedeutet.

Was die llms.txt ist – und was nicht

Die llms.txt liegt wie die robots.txt im Wurzelverzeichnis (https://beispiel.de/llms.txt), ist aber das genaue Gegenteil in der Absicht: Während die robots.txt regelt, wer rein darf, ist die llms.txt eine kuratierte Inhaltsangabe in Markdown, die sagt, was wichtig ist. Sie soll einem KI-System eine saubere, knappe Landkarte der zentralen Inhalte geben – ohne Navigation, Werbung und JavaScript-Ballast.

Genauso wichtig ist, was sie nicht ist:

• Keine Zugriffssteuerung. Sie blockiert nichts und erlaubt nichts. Crawling, Indexierung und Training regelt man weiter über robots.txt, User-Agent-Regeln, noindex und Anbieter-Policies.
• Kein Trainings-Opt-out. Sie hält keinen Bot von irgendetwas ab.
• Kein offizieller Standard. Sie ist eine vorgeschlagene Konvention (llmstxt.org), kein IETF- oder W3C-Standard. Es gibt kein Gremium, das sie durchsetzt.
• Kein bestätigter Ranking- oder Zitations-Faktor. Kein großes Antwortsystem behandelt sie nachweislich als Sichtbarkeitssignal.

Sie ist – in den Worten der Befürworter – eine Orientierungshilfe für die Inferenz: für den Moment, in dem ein Modell eine Frage beantwortet und gezielt sauberen Kontext einsammeln will.

Die Geschichte: aus der Entwickler-Doku geboren

Den Vorschlag machte Jeremy Howard (Mitgründer von Answer.AI und fast.ai) am 3. September 2024. Sein Ausgangsproblem war konkret und technisch: Kontextfenster von Sprachmodellen sind zu klein, um ganze Websites zu fassen, und komplexes HTML mit Menüs, Werbung und Skripten lässt sich nur ungenau in sauberen Text übersetzen. Besonders bei Entwickler-Dokumentationen – wo ein Modell schnell präzise an API-Referenzen kommen soll – ist eine kompakte, expertenartige Fassung Gold wert.

Das Format ist bewusst simpel: eine H1 mit dem Namen, ein Blockzitat als Kurzbeschreibung, dann thematisch gegliederte Listen aus Links mit knappen Erläuterungen, optional ein „Optional“-Abschnitt. Ergänzt wird das oft durch eine llms-full.txt – die gesamte Doku in einer einzigen Markdown-Datei – sowie durch .md-Versionen einzelner Seiten.

Vom Vorschlag zur Verbreitung führte ein einzelnes Ereignis: Im November 2024 aktivierte die Doku-Plattform Mintlify llms.txt für alle gehosteten Doku-Seiten. Praktisch über Nacht unterstützten Tausende Entwickler-Sites – darunter Anthropic und Cursor – das Format. Genau dort, im Umfeld von Entwickler-Tools, KI-Firmen und SaaS-Dokumentation, sitzt bis heute der Großteil der Verbreitung.

Das mentale Modell, das fast jede Verwirrung auflöst: drei Phasen

Der häufigste Denkfehler in der llms.txt-Debatte ist, drei völlig verschiedene Phasen in einen Topf zu werfen, in denen KI mit dem Web interagiert:

1. Training. Modelle werden auf riesigen Web-Snapshots (u. a. Common Crawl) vortrainiert. Eine llms.txt spielt hier keine nennenswerte Rolle.
2. Quelle finden (Index-Retrieval). Ein Antwortsystem entscheidet anhand seines Index, welche URLs für eine Frage relevant sind. Auch hier ist die llms.txt kein relevanter Input – das übernehmen Suchindizes und Ranking-Systeme.
3. Inferenz & agentisches Abrufen. Ein Modell oder ein Agent holt sich im Moment der Beantwortung gezielt Inhalte – oder navigiert sogar live durch eine Seite, um eine Aufgabe zu erledigen. Nur hier kann eine kuratierte Markdown-Landkarte echten Nutzen stiften.

Mit dieser Brille wird der Google-„Widerspruch“ sofort verständlich.

Der Google-„Widerspruch“, aufgelöst

Google Search arbeitet in den Phasen 1 und 2. Die KI-Übersichten und der KI-Modus sind Retrieval-Augmented Generation über den bestehenden Suchindex – sie ziehen relevante Seiten aus dem Index und prüfen sie. Für diesen Mechanismus braucht es keine Extra-Datei; der Googlebot liest die Seite ohnehin. Folgerichtig sagt Google Search: llms.txt ist überflüssig. John Mueller verglich sie öffentlich mit dem alten Keywords-Meta-Tag – einer selbst deklarierten Angabe, die manipulierbar ist und die Suchmaschinen deshalb seit über einem Jahrzehnt ignorieren. Sein Kernsatz im Sommer 2025: „no AI system currently uses llms.txt.“ Gary Illyes bestätigte bei Search Central Live, dass Google die Datei nicht unterstützt und das auch nicht plant. (Als Anfang Dezember 2025 kurzzeitig eine llms.txt in Googles eigener Entwicklerdoku auftauchte und noch am selben Tag wieder verschwand, sorgte das für viel Rätselraten – an der offiziellen Haltung änderte es nichts.)

Chrome dagegen denkt in Phase 3. Das Lighthouse-Audit sitzt bewusst unter „Agentic Browsing“: Es geht um Browser-Agenten, die eine Seite live ansteuern, um dort etwas zu erledigen. Für so einen Agenten kann eine maschinenlesbare Übersicht der Einstiegspunkte tatsächlich Zeit sparen. Das Audit ist „Not Applicable“, wenn keine Datei existiert – die Datei ist also explizit optional und kein Pflichtkriterium.

Die Lehre: Es ist kein Konzern-Streit, sondern zwei Teams, die für zwei verschiedene Schichten optimieren. Wer llms.txt als SEO- oder KI-Sichtbarkeits-Hebel verkauft, verwechselt Phase 3 mit Phase 2.

Für und Wider

Dafür spricht:

• Entwickler-Doku und agentische Tools. Für umfangreiche Dokumentationen und KI-Coding-Umgebungen (Cursor & Co.) ist der Nutzen real: Werkzeuge holen sich sauberes Markdown statt verschachteltes HTML, sparen Tokens und finden schneller das Richtige. Das war der ursprüngliche Zweck – und dort funktioniert er.
• Eigene und Partner-Systeme. Wer einen eigenen RAG-Chatbot, eine Wissensdatenbank oder Partner-Integrationen betreibt, kann diese gezielt auf die llms.txt zeigen lassen. Hier ist man nicht auf das Wohlwollen großer Anbieter angewiesen.
• Günstige Vorarbeit. Die Datei ist billig und risikoarm zu erstellen. Welches Folgeprotokoll der „agentischen“ Zukunft sich auch durchsetzt – sauber strukturierte, maschinenlesbare Inhalte sind nie verkehrt.
• „Standards brauchen Zeit“. Das Gegenargument zur Skepsis: Auch robots.txt und Sitemaps existierten lange vor jeder formalen Verabschiedung. Frühe Verbreitung kann einem Standard den Weg bahnen, bevor ihn jemand offiziell bestätigt.

Dagegen spricht:

• Kein großes Antwortsystem nutzt sie. Es gibt keinen belastbaren Beleg, dass OpenAI, Anthropic, Google oder Perplexity die Datei für Ranking oder Zitate auswerten – und in Server-Logs erscheinen ihre Crawler beim Abruf der llms.txt schlicht nicht. Sie fragen die Datei meist gar nicht erst ab.
• Selbst deklariert = manipulierbar. Muellers Keywords-Meta-Vergleich trifft einen wunden Punkt: Was der Seitenbetreiber über sich behauptet, kann ein Modell genauso gut prüfen, indem es die Seite direkt liest. Warum dann der Umweg über eine zweite Datei?
• Pflegeaufwand und Drift. Eine llms.txt ist eine zweite Quelle der Wahrheit. Veraltet sie oder weicht sie vom tatsächlichen Inhalt ab, ist sie schlechter als gar keine Datei.
• Winzige reale Verbreitung. Erhebungen Ende 2025 fanden die Datei nur auf einem Bruchteil der untersuchten Domains – in einer Analyse bei rund 0,1 %. Die Verbreitung konzentriert sich auf Nischen im Tech-Umfeld.
• Kein Governance-Modell. Erfolgreiche Web-Standards haben ein Trägergremium und eine Durchsetzungslogik – schema.org funktionierte, weil Google, Bing, Yahoo und Yandex dahinterstanden. Bei llms.txt fehlt dieses „Wer macht die Regeln?“.

Die zwei Risiken, die man wirklich kennen muss

Drift. Sobald die llms.txt von der Website abweicht, untergräbt sie genau das Vertrauen, das sie schaffen soll. Eine Datei, die auf eingestellte Angebote, alte Preise oder gelöschte Seiten verweist, richtet mehr Schaden an als Nutzen. Wer sie pflegt, muss sie automatisch aus derselben Quelle erzeugen wie die Website – nicht von Hand danebenher führen.

Cloaking. Die gefährlichere Versuchung ist, KI-Systemen über die llms.txt etwas anderes zu zeigen als menschlichen Besuchern. Das ist Cloaking – dieselbe Manipulationstechnik, die Suchmaschinen seit jeher abstrafen. Genau diese Manipulierbarkeit ist der Grund, warum eine selbst deklarierte, von keinem Gremium kontrollierte Datei schnell zum Spam-Magneten werden kann. Unsere Regel ist deshalb eindeutig: Die llms.txt spiegelt die echten Inhalte – nie eine Sonderversion für Maschinen.

Die saubere Antwort auf beide Risiken: eine Grounding Page aus dem Schema

Drift und Cloaking klingen nach Gründen, die llms.txt zu meiden. Tatsächlich sind sie ein Konstruktionshinweis: Wer maschinenlesbare Inhalte anbietet, sollte sie nie neben der Website pflegen, sondern aus derselben Quelle erzeugen wie die menschenlesbare Seite. Genau das ist die Idee hinter einer Grounding Page – einer kanonischen Faktenseite, die verlässliche Eckdaten über die Organisation bündelt: Basisdaten, Leistungen, Referenzen, Auszeichnungen, Kontakt, offizielle Profile und häufige Fragen.

Wir setzen das bei Elbnetz über ein eigenes mu-Plugin um: Eine einzige Datenschicht speist sowohl das JSON-LD (ein @graph mit über @id vernetzten Entitäten) als auch die sichtbare Grounding Page. Dadurch lösen sich beide Risiken nicht durch Disziplin, sondern durch Architektur:

• Kein Drift, weil sichtbare Seite und strukturierte Daten dieselbe Quelle haben und gar nicht auseinanderlaufen können.
• Kein Cloaking, weil Menschen und Maschinen exakt dieselben Fakten sehen. Die Grounding Page ist damit die ehrliche, überprüfbare Form von Maschinenlesbarkeit – das Gegenteil einer Schattendatei für Bots.

Eine Lehre aus der eigenen Praxis gehört dazu: Eine Faktenseite wirkt nur, wenn sie eine einzige, saubere Entität beschreibt. Selbst ein eingebettetes Drittanbieter-Widget kann das unbemerkt untergraben – etwa ein Bewertungs-Tool, das zusätzlich eine eigene, fehlerhaft typisierte Entität samt Sternebewertung in dieselbe Seite schreibt. Solche Konflikte sieht man der Seite nicht an; sie fallen erst bei einem strukturierten-Daten-Audit auf. Wir prüfen die Grounding Page deshalb regelmäßig darauf, dass dort wirklich nur eine Entität steht.

In dieser Architektur bekommt die llms.txt ihre angemessene, bescheidene Rolle: Sie ist kein Wundermittel, sondern ein Wegweiser, der auf die kanonische Quelle zeigt. Der Wert entsteht nicht durch die Datei, sondern durch die saubere, schema-getriebene Seite dahinter.

Unsere Einschätzung bei Elbnetz – und für unsere Kunden

Wir trennen die Frage sauber nach Geschäftsmodell und Inhaltstyp:

Wann sich eine llms.txt lohnt:

• Bei umfangreicher Dokumentation oder Wissensinhalten, die Entwickler oder Fachnutzer über KI-Tools konsumieren.
• Wenn man eigene oder Partner-KI-Systeme auf die Inhalte zeigen lassen will – hier hat man die Kontrolle und einen sofortigen, messbaren Nutzen.
• Als bewusste, günstige Vorarbeit für eine agentische Zukunft – sofern die Pflege automatisiert ist.

Wann sie heute wenig bringt:

• Für eine klassische Marketing- oder Unternehmenswebsite ist sie kein Sichtbarkeits-Hebel. Wer sich von ihr mehr KI-Zitate oder besseres Ranking verspricht, wird enttäuscht. Auftauchen in KI-Antworten entsteht 2026 über gute Inhalte, saubere Struktur, strukturierte Daten (Schema) und Erwähnungen aus vertrauenswürdigen Quellen – nicht über eine Textdatei im Wurzelverzeichnis.

Unsere konkrete Empfehlung: Wenn llms.txt, dann automatisch generiert (gängige WordPress-Plugins wie Yoast oder Rank Math bieten das inzwischen an), akkurat gehalten, niemals cloakend – und mit niedriger Priorität, klar nach Schema und Inhalten. Sie ist ein „Nice-to-have“ mit Optionswert, kein Wundermittel. Und wie bei der robots.txt gilt: quartalsweise prüfen, weil sich die Lage bewegt.

Für elbnetz.com selbst halten wir es konsequent so: Die llms.txt macht genau eine Sache – sie benennt die Grounding Page als maßgebliche Quelle und setzt grobe Inhaltsprioritäten. Den eigentlichen Wert trägt aber nicht die Datei, sondern die Grounding Page selbst, die aus derselben Schema-Datenquelle erzeugt wird wie unser JSON-LD. Wir erwarten von der llms.txt keinen Ranking-Effekt; wir behalten sie, weil der Aufwand minimal ist und sie – falls das agentische Web (Phase 3) groß wird – sauber auf eine konfliktfreie kanonische Quelle zeigt.

Fazit

Die llms.txt ist der logische nächste Gedanke nach der robots.txt, und beide ergänzen sich sauber: Die robots.txt sagt, wer rein darf, die llms.txt sagt, was wichtig ist – für diejenigen, die sie überhaupt lesen. Genau hier liegt der Haken: Stand 2026 lesen die großen Antwortsysteme sie nicht. Ihr Nutzen ist heute real in der agentischen Nische und in eigenen Systemen, und er ist spekulativ als Wette auf die Zukunft.

Der eigentliche Baustein ist deshalb nicht die Datei, sondern die saubere, schema-getriebene Faktenseite dahinter, die Menschen und Maschinen identisch sehen – mit einer llms.txt, die lediglich darauf verweist. Der scheinbare Google-Widerspruch fasst das gut zusammen: Für die Suche (Index, Ranking) braucht man die Datei nicht – das sagt Google Search zu Recht. Für agentisches Browsing (Live-Handeln auf der Seite) kann sie helfen – das sagt Chrome zu Recht. Wer beides nicht verwechselt, trifft die richtige Entscheidung.

Unsere Haltung bleibt damit dieselbe wie bei der robots.txt: bewusst entscheiden, schlank und akkurat umsetzen, Prioritäten ehrlich setzen – und die Wirkung dort suchen, wo sie nachweislich entsteht: in den Inhalten und der Struktur darunter, nicht in einer Datei, die verspricht, sie zu ersetzen.