Die llms.txt ist tot. Genauer gesagt: ein Rohrkrepierer.

Warum Du sofort aufhören solltest, llms.txt-Dateien zu erstellen — und was stattdessen zu tun ist.

Ich muss Dir etwas sagen, das Du nicht hören willst: Die llms.txt, die ihr letzte Woche mit großem Aufwand erstellt hast, wird von keinem einzigen relevanten KI-Suchsystem gelesen. Von keinem. Nicht von Google. Nicht von ChatGPT. Nicht von Perplexity. Nicht von Claude.

Das ist keine Meinung. Das sind Logfiles.

0,1 Prozent

OtterlyAI hat 90 Tage lang gemessen, was passiert, wenn man eine korrekt implementierte llms.txt bereitstellt. Das Ergebnis: Von 62.100 KI-Bot-Requests gingen genau 84 an die llms.txt. Das sind 0,1 Prozent. Die Datei performte dreimal schlechter als eine durchschnittliche Content-Seite auf derselben Domain. Sie lag auf dem Niveau eines vergessenen PDFs im /assets-Ordner.

Wer 20.000 Domains hostet, berichtet dasselbe: Kein einziger relevanter KI-Agent fordert die Datei an. Der einzige Bot, der sie crawlt, ist BuiltWith — ein Technologie-Erkennungsdienst, der schlicht katalogisiert, welche Dateien existieren. Das ist kein Nutzungssignal. Das ist ein Inventurzettel.

Was Google dazu sagt — und was Google damit tut

Google hat die klarste Position aller Anbieter. John Mueller schrieb auf Bluesky:

„FWIW no AI system currently uses llms.txt.“

Er verglich die Datei explizit mit dem Keywords-Meta-Tag — jenem Tag, das Suchmaschinen seit über einem Jahrzehnt ignorieren, weil es vom Seitenbetreiber kontrolliert wird und daher für Manipulationen anfällig ist. Gary Illyes bestätigte auf der Google Search Central Live: Google unterstützt llms.txt nicht und plant dies auch nicht.

Die Pointe: Am 3. Dezember 2025 tauchte kurzzeitig eine llms.txt in Googles eigenen Developer Docs auf. Die SEO-Community hielt den Atem an. Noch am selben Tag wurde die Datei wieder entfernt. Mueller stellte klar: keine offizielle Unterstützung. Was blieb, war ein kryptisches „hmmn :-/“ auf Bluesky und eine Community, die in dieses Emoticon mehr hineininterpretierte als in manchen Research Paper.

Was der Erfinder eigentlich wollte

An dieser Stelle lohnt sich ein Blick zurück, denn die Entstehungsgeschichte der llms.txt entlarvt das gesamte Missverständnis.

Am 3. September 2024 veröffentlichte Jeremy Howard — Co-Founder von Answer.AI und fast.ai, KI-Forscher und Dozent an den Universitäten Queensland und Stanford — seinen Vorschlag auf answer.ai und llmstxt.org. Das Problem, das er lösen wollte, war klar umrissen und hatte mit GEO nichts zu tun: Context Windows von LLMs sind zu klein für komplette Websites. HTML mit Navigation, Werbung und JavaScript in LLM-freundlichen Text zu konvertieren ist aufwändig und fehleranfällig. Besonders relevant sei das, so Howard explizit, für Development-Umgebungen, in denen LLMs schnellen Zugriff auf Programmierdokumentation und APIs brauchen.

Howards eigenes FastHTML-Projekt war die Referenzimplementierung. Ein Python-Framework mit technischer Dokumentation — genau der Use Case, für den die Idee konzipiert war.

Die Adoption blieb monatelang nischenhaft. Der Wendepunkt kam im November 2024, als Mintlify — ein Hosting-Dienst für Developer-Dokumentation — die llms.txt-Unterstützung für alle gehosteten Docs-Sites ausrollte. Praktisch über Nacht bekamen Tausende Dokumentationsseiten eine llms.txt, darunter Anthropic und Cursor. Die Schlagzeilen interpretierten das als Durchbruch. Was tatsächlich passiert war: Ein Docs-Hoster hatte ein Feature für seine Docs-Kunden aktiviert.

Ab hier begann die Zweckentfremdung. Die SEO- und GEO-Community entdeckte die llms.txt und interpretierte sie als das, was sie gerne hätte: einen neuen Hebel für Sichtbarkeit in KI-Suchsystemen. Yoast baute einen llms.txt-Generator in sein WordPress-Plugin. Agenturen nahmen „llms.txt-Erstellung“ in ihre Leistungskataloge auf. Konferenz-Speaker erklärten die Datei zum Pflichtprogramm.

Das Problem: Jeremy Howard hat llms.txt nie als GEO- oder SEO-Maßnahme vorgeschlagen. Sein Proposal adressiert Inference-Time-Nutzung durch Coding-Tools und KI-Agenten, nicht Sichtbarkeit in generativen Suchsystemen. Wer llms.txt als Ranking-Hebel verkauft, verkauft etwas, das der Erfinder selbst nie versprochen hat.

Die große Verwechslung: Publizieren vs. Konsumieren

Hier wird es interessant, denn hier liegt der Denkfehler, den die halbe GEO-Szene macht:

Ja, Anthropic hat eine llms.txt. Ja, OpenAI hat eine. Ja, Perplexity hat eine. Jede dieser Dateien liegt auf den jeweiligen Developer-Dokumentationsseiten. Sie dienen einem einzigen Zweck: Entwicklern und Coding-Assistenten einen strukturierten Einstiegspunkt in die API-Dokumentation zu geben. Wenn ein Entwickler in Cursor oder Claude Code arbeitet und die Anthropic-API-Docs laden will, ist eine llms.txt dafür ein sinnvolles Format.

Aber das hat absolut nichts damit zu tun, ob ClaudeBot, GPTBot oder PerplexityBot beim Web-Retrieval die llms.txt einer beliebigen Unternehmenswebseite auswertet. Die Existenz einer llms.txt auf docs.anthropic.com beweist nicht, dass Anthropic eure llms.txt auf beispiel-firma.de im Suchprozess berücksichtigt.

Wer diesen Unterschied nicht versteht, verwechselt die Tatsache, dass ein Restaurant eine Speisekarte hat, mit der Behauptung, es würde die Speisekarten anderer Restaurants lesen, bevor es kocht.

Vier Gründe, warum das so ist — und so bleiben wird

1. Manipulationsanfälligkeit

Die llms.txt ist ein vom Seitenbetreiber kontrolliertes Signal. Der Betreiber entscheidet, welche Inhalte ein LLM sehen soll und welche nicht. Das ist exakt das Problem, das Suchmaschinen beim Keywords-Meta-Tag identifiziert haben: Ein Signal, das der Bewertete selbst kontrolliert, ist für den Bewertenden wertlos. Suchsysteme müssen eigene Relevanzurteile fällen. Eine Datei, in der ich selbst kuratiere, was eine Suchmaschine über mich erfahren soll, ist per Definition kein vertrauenswürdiges Signal.

Was hindert jemanden daran, in der llms.txt eine geschönte Version der eigenen Inhalte zu präsentieren? Nichts. Das ist Cloaking mit Markdown-Syntax.

2. Retrieval-Ineffizienz

Stellt euch den hypothetischen Ablauf vor, den eine llms.txt im Retrieval-Stack erzeugen würde:

1. Request an /llms.txt
2. Parsing der Markdown-Struktur
3. LLM-gestützte Interpretation der Anweisungen und Priorisierungen
4. Anpassung der Retrieval-Strategie basierend auf diesen Anweisungen
5. Eigentliches Content-Retrieval
6. Antwortgenerierung

Das sind mindestens zwei zusätzliche Schritte — mit zusätzlicher Latenz, Token-Kosten und Fehleranfälligkeit — in einer Pipeline, die auf Geschwindigkeit optimiert sein muss. Google, OpenAI und Anthropic haben Milliarden in Content-Extraction-Pipelines investiert, die HTML zuverlässig parsen, Boilerplate entfernen und Hauptinhalte identifizieren. Warum sollten sie diesen bewährten Stack durch eine Datei ersetzen, deren Inhalt sie ohnehin verifizieren müssten?

Die Antwort: Würden sie nicht. Tun sie nicht.

3. Redundanz zur robots.txt

Für die Zugriffssteuerung existiert ein funktionierender, seit 1994 etablierter Standard: die robots.txt. Alle relevanten KI-Crawler — GPTBot, ClaudeBot, Google-Extended, PerplexityBot — respektieren robots.txt-Direktiven. Anthropic verweist in der eigenen Dokumentation zur Crawler-Steuerung ausschließlich auf robots.txt. Kein einziger KI-Anbieter hat gesagt: „Nutzt llms.txt statt robots.txt für die Zugriffssteuerung.“ Warum? Weil das Problem bereits gelöst ist.

4. Adoptionsversagen

Ein Standard, den kein relevanter Konsument implementiert, ist kein Standard. Er ist ein Vorschlag, der nicht angenommen wurde. Die robots.txt brauchte Jahre, um vom Vorschlag zum De-facto-Standard zu werden — aber sie wurde von Anfang an von den Suchmaschinen gelesen und respektiert. Die llms.txt wird nach über einem Jahr von keinem großen KI-Suchsystem im Retrieval-Kontext verwendet. Das ist kein „noch nicht“. Das ist ein Signal.

Was eure Agentur euch gerade verkauft

In Pitch-Decks und GEO-Audits sehe ich seit Monaten denselben Punkt: „llms.txt erstellen und optimieren.“ Manchmal als eigener Workstream, manchmal als Teil eines größeren Pakets, immer mit dem impliziten Versprechen, dass diese Datei die Sichtbarkeit in KI-Suchsystemen verbessert.

Das ist Ressourcenverschwendung. Jede Stunde, die euer Team damit verbringt, eine llms.txt zu pflegen, ist eine Stunde, die nicht in tatsächlich wirksame Maßnahmen fließt. Die Opportunitätskosten sind real: Content-Qualität, semantische Strukturierung, Entity-Abdeckung, Zitierfähigkeit — alles Faktoren, für die es tatsächliche Evidenz gibt, dass sie die Sichtbarkeit in generativen Suchsystemen beeinflussen.

Wo llms.txt tatsächlich Sinn ergibt

Fairness gebietet es, den einen Use Case zu benennen, in dem llms.txt einen legitimen Zweck erfüllt: Developer-Dokumentation für Coding-Assistenten und KI-Agenten.

Wenn eure Zielgruppe Entwickler sind, die mit Cursor, Windsurf oder Claude Code arbeiten, und ihr eine umfangreiche API-Dokumentation habt, dann kann eine llms.txt als strukturierter Einstiegspunkt für diese Tools nützlich sein. Das ist der ursprüngliche Vorschlag von Jeremy Howard, und für diesen Kontext ist er nachvollziehbar.

Aber: Das ist Developer Relations. Das ist kein GEO. Das ist kein SEO. Und es betrifft einen Bruchteil aller Websites.

Was stattdessen zu tun ist

Wer seine Sichtbarkeit in KI-Suchsystemen tatsächlich verbessern will, sollte sich auf das konzentrieren, was nachweislich funktioniert:

1. Content-Qualität und Zitierfähigkeit. Generative Suchsysteme zitieren Quellen, die Fakten, Daten und Expertise liefern. Wer zitiert werden will, muss zitierwürdig sein. Das bedeutet: originäre Daten, klare Aussagen, nachprüfbare Fakten.
2. Semantische Strukturierung. Klare Heading-Hierarchien, konsistente Entity-Nutzung und logische Struktur. Diese Signale werden von KI-Crawlern beim regulären Crawling erfasst — ohne Umweg über eine zusätzliche Datei.
3. Topical Authority. Thematische Tiefe und Breite. Wer zu einem Thema die umfassendste und verlässlichste Quelle ist, wird von generativen Systemen bevorzugt herangezogen. Dabei sollte man nicht vergessen: Die großen KI-Suchsysteme nutzen für ihr Grounding klassische Websuche. Wer in der organischen Suche stark ist, hat auch in der generativen Suche die besseren Karten.
4. Monitoring statt Spekulation. Messt, wo und wie euer Brand in KI-generierten Antworten erscheint. Passt eure Strategie auf Basis von Daten an, nicht auf Basis von Konferenz-Slides.

Fazit

Die llms.txt war eine interessante Idee mit einem nachvollziehbaren Kern: Webinhalte maschinenlesbarer machen. Für den spezifischen Kontext von Developer-Dokumentation hat sie ihren Platz.

Als GEO-Maßnahme ist sie gescheitert. Nicht, weil sie schlecht implementiert wird. Nicht, weil sie „noch Zeit braucht“. Sondern weil die fundamentale Prämisse — dass KI-Suchsysteme eine vom Seitenbetreiber kuratierte Inhaltsbeschreibung als vertrauenswürdiges Signal verwenden würden — dem Grundprinzip moderner Suchsysteme widerspricht. Suchmaschinen bewerten. Sie lassen sich nicht bewerten.

Hört auf, llms.txt-Dateien als GEO-Maßnahme zu erstellen. Investiert die Zeit in Inhalte, die es wert sind, von KI-Systemen gefunden und zitiert zu werden. Das ist schwerer. Aber es funktioniert.