# llms.txt: Doku für Maschinen URL: https://www.mikebild.dev/de/blog/llms-txt-und-llms-full-txt/ 97 Prozent. So viele der öffentlich hinterlegten `llms.txt`-Dateien wurden laut einer Ahrefs-Auswertung im Mai 2026 kein einziges Mal abgerufen. Wer nur diese Zahl liest, zieht schnell den falschen Schluss: ein totgeborenes SEO-Gimmick, ein weiterer Eintrag auf der langen Liste gut gemeinter Web-Konventionen, die niemand anfasst. Nur zielt die Zahl am eigentlichen Zweck vorbei. `llms.txt` war nie als Ranking-Trick gedacht – und dort, wo die Datei tatsächlich etwas leistet, taucht sie in solchen Statistiken kaum auf, weil sie nicht von Suchmaschinen-Crawlern angefragt wird, sondern von einem Coding-Agenten mitten in einer Session. Genau diese Verwechslung macht das Thema interessant. Es gibt zwei Dateien, `llms.txt` und `llms-full.txt`, sie sehen nach Marketing-Infrastruktur aus, und ihr wahrer Nutzen liegt an einer ganz anderen Stelle: bei der Frage, wie ein Modell an sauberen, kuratierten Kontext kommt, ohne sich vorher durch Navigationsleisten, Cookie-Banner und JavaScript zu arbeiten. ## Zwei Dateien, ein Problem Den Vorschlag hat Jeremy Howard, Mitgründer von Answer.AI, am 3. September 2024 veröffentlicht; die Beschreibung steht bis heute unter `llmstxt.org`. Der Ausgangspunkt ist eine nüchterne Beobachtung: Modelle stützen sich zunehmend auf Webinhalte, aber ihr Kontextfenster ist zu klein, um eine ganze Website am Stück aufzunehmen. Und rohes HTML in brauchbaren Text zu verwandeln, ist mühsam und ungenau – zwischen dem eigentlichen Inhalt steckt jede Menge Beiwerk, das nur Platz frisst. Die Antwort besteht aus zwei Bausteinen, die man sauber auseinanderhalten sollte. `llms.txt` liegt im Wurzelverzeichnis einer Seite und ist ein kuratierter Index in Markdown. Das Format ist bewusst eng: eine H1-Überschrift mit dem Projektnamen, darunter ein Zitatblock mit einer kurzen Zusammenfassung, optional ein paar Sätze Kontext, danach H2-Abschnitte mit Linklisten. Jeder Link trägt eine knappe Beschreibung. Ein eigener Abschnitt `## Optional` markiert das, was ein Modell bei knappem Platz zuerst weglassen darf. So kompakt sieht das aus: ```markdown # Orderflow API > Orderflow is a REST API for creating, tracking, and refunding orders. > These docs are written for LLMs and coding agents. Every write endpoint accepts an `Idempotency-Key` header, so retries stay safe. ## Core Documentation - [Quick Start](https://docs.example.com/quickstart.md): Authenticate and create your first order - [API Reference](https://docs.example.com/api.md): Endpoints, parameters, and error codes - [Webhooks](https://docs.example.com/webhooks.md): Event types and signature verification ## Optional - [Changelog](https://docs.example.com/changelog.md): Version history and breaking changes ``` `llms-full.txt` ist der zweite Baustein und deutlich schlichter im Konzept: der vollständige Text der wichtigen Seiten, in einer einzigen Markdown-Datei aneinandergehängt. Kein Index mehr, sondern der ganze Inhalt am Stück, ohne HTML-Rauschen: ```markdown # Orderflow API — Full Documentation ## Quick Start Authenticate with a bearer token, then POST to /v1/orders to create your first order. Every response includes an `order_id` you can track. ## API Reference ### POST /v1/orders Creates an order. Requires an `Idempotency-Key` header. Returns 201 on success, 409 when the key was already used. ... ## Webhooks Events are signed with HMAC-SHA256. Verify the `X-Signature` header before trusting the payload. ... ``` Der Reiz liegt auf der Hand: Ein Modell lädt den relevanten Kontext mit einer einzigen Anfrage, statt sich Seite für Seite durchzuhangeln. Ergänzend schlägt Howard vor, einzelne Seiten zusätzlich als saubere Markdown-Fassung unter derselben Adresse mit angehängtem `.md` bereitzustellen – aus `.../api` wird `.../api.md`. Das ist der Klebstoff zwischen Index und Inhalt: Der Index verweist auf `.md`-Seiten, die schon in der Form vorliegen, die ein Modell ohnehin am liebsten liest. Wichtig ist die Abgrenzung, weil hier viel durcheinandergeht. `robots.txt` regelt Zugriff – was ein Crawler anfassen darf und was nicht. `sitemap.xml` hilft beim Indexieren. `llms.txt` macht keins von beidem. Es ordnet ein und kuratiert, gedacht für den Moment der Inferenz, nicht für den Crawl. Die drei Dateien schließen sich nicht aus, sie beantworten verschiedene Fragen. ```mermaid flowchart TD A[Coding-Agent] -->|kennt llms.txt| B[llms.txt
kuratierter Index] B --> C{Welche Seite
brauche ich?} C -->|gezielt| D[seite.md
saubere Markdown-Fassung] C -->|alles auf einmal| E[llms-full.txt
gesamter Inhalt] A -.->|Alternative ohne llms.txt| F[HTML-Seite crawlen
Navigation, Werbung, JS] F -.->|viel Rauschen| G[Kontextfenster voll,
Inhalt verwässert] ``` ## Warum das etwas bringt Der Nutzen wird greifbar, sobald man einem Agenten bei der Arbeit zusieht. Bittet man ein Modell, eine fremde Bibliothek anzubinden, und es hat nur die HTML-Doku, passiert regelmäßig eins von zwei Dingen: Entweder es zieht eine komplette Seite herein – Menü, Fußzeile, drei Codebeispiele, die es gar nicht braucht – und ein spürbarer Teil des Fensters ist weg, bevor die eigentliche Aufgabe beginnt. Oder es rät. Mir ist in einem Code-Review aufgefallen, dass ein Agent eine API-Signatur schlicht erfunden hatte, plausibel und falsch, weil ihm die exakte Referenz zu teuer war, sie sich zu holen. Beides sind Symptome desselben Problems: zu viel Rauschen pro Token, zu wenig verlässliche Substanz. `llms.txt` setzt genau dort an. Der Gewinn lässt sich in ein paar Punkten fassen: - **Weniger Tokens für dasselbe Wissen.** Kuratiertes Markdown ohne Layout-Ballast bedeutet, dass mehr vom Fenster für den eigentlichen Inhalt übrig bleibt – und weniger für Navigationslinks, die niemand braucht. - **Kuratierung statt Vollständigkeit.** Nicht jede Seite ist gleich wichtig. Der Index zwingt dazu, die dreißig bis hundert Seiten zu benennen, die den Kern ausmachen. Diese Entscheidung trifft ein Mensch mit Domänenwissen, kein Ranking-Algorithmus. - **Grounding gegen Halluzination.** Braucht das Modell die genaue Fehlermeldung oder den exakten Parameter, holt es sich die passende `.md`-Seite, statt zu improvisieren. Der Punkt mit der Kuratierung wird oft übersehen. Eine gute `llms.txt` ist keine automatisch generierte Linkliste, sondern eine redaktionelle Aussage darüber, was an einem Produkt zählt. Wer sie schreibt, muss sich festlegen – und das ist die eigentliche Arbeit, nicht die Datei selbst. ## Wo es sich lohnt – und wo nicht Genau hier klärt sich auch die 97-Prozent-Zahl vom Anfang. Für ein Blog wie dieses oder eine Marketing-Seite bringt `llms.txt` heute wenig: Kein großer Modellanbieter hat sich verbindlich darauf festgelegt, die Datei als Signal zu werten, und Google hat sie nie empfohlen. Wer sie in der Hoffnung auf bessere Sichtbarkeit anlegt, wird enttäuscht. Die Ausnahme ist eng, aber real, und dort ist der Nutzen deutlich: technische Dokumentation und Coding-Agenten. Eine API-Referenz, eine Komponentenbibliothek, ein SDK – Inhalte, die ohnehin in Markdown gepflegt werden und die ein Agent in der IDE gezielt nachschlägt. Anbieter wie Stripe, Anthropic, Cursor, Mintlify oder das FastHTML-Projekt haben früh `llms.txt` bereitgestellt, und zwar nicht fürs Ranking, sondern damit Werkzeuge ihre Doku sauber lesen können. Faustregel aus der Praxis: Wird der Inhalt von Menschen überflogen und geteilt, ist `llms.txt` Zierrat. Wird er von einer Maschine mitten in einer Aufgabe konsultiert, ist er ein Werkzeug. Der Aufwand ist bei Doku-lastigen Seiten gering – oft eine knappe halbe Stunde – und lässt sich ehrlich testen: Tauchen im Server-Log Anfragen auf `/llms.txt` auf, lohnt die Pflege; bleiben sie aus, kann man es lassen. ## Was ein MCP-Server daraus macht Bis hierhin ist `llms.txt` eine statische Datei, die jemand irgendwann abholt. Der interessante Sprung passiert in Verbindung mit dem Model Context Protocol – dem offenen Protokoll, das Anthropic Ende 2024 vorgestellt hat und über das ein Agent standardisiert mit externen Werkzeugen und Datenquellen spricht. Man kann sich die Arbeitsteilung als Inhaltsverzeichnis und Hände vorstellen. `llms.txt` ist das Inhaltsverzeichnis: eine kuratierte Übersicht darüber, welche Inhalte es gibt und wo sie liegen. Ein MCP-Server sind die Hände: Er liest dieses Verzeichnis und holt gezielt das, was gerade gebraucht wird. Das LangChain-Team hat mit `mcpdoc` genau so einen Doku-Server gebaut. Er bekommt eine Liste von `llms.txt`-Adressen und stellt dem Agenten zwei Werkzeuge bereit: eines, das die registrierten Quellen aufzählt, und eines, das eine bestimmte Seite daraus nachlädt. ```json { "mcpServers": { "docs": { "command": "uvx", "args": [ "--from", "mcpdoc", "mcpdoc", "--urls", "Orderflow:https://docs.example.com/llms.txt", "--transport", "stdio", "--allowed-domains", "docs.example.com" ] } } } ``` Der Unterschied zum bloßen Herunterladen der Datei ist größer, als er zunächst wirkt. Drei Dinge werden dadurch besser. Erstens die Dosierung. Statt `llms-full.txt` komplett ins Fenster zu kippen, fragt der Agent über den Index nur die eine Seite ab, die zur Aufgabe passt. Das ist der Sweet Spot zwischen „gar kein Kontext“ und „alles auf einmal“. Zweitens die Nachvollziehbarkeit. IDEs wie Cursor oder Claude Code lesen `llms.txt` teils mit eingebauten Mechanismen, deren Tool-Aufrufe man nicht sieht. Über einen eigenen MCP-Server läuft jeder Zugriff durch Werkzeuge, die man prüfen kann – man sieht, welche Adresse geladen wurde und was zurückkam. Für alles jenseits eines Spielprojekts ist diese Prüfbarkeit den Aufwand wert. Drittens die Kontrolle. Der Server lässt sich auf erlaubte Domains beschränken, und für interne oder geschützte Doku legt man Authentifizierung davor. Damit wird aus einer öffentlichen Konvention etwas, das auch hinter der Firmen-Firewall trägt: Man richtet den Server auf eine private `llms.txt` und gibt Modellen im Team Zugriff auf kuratiertes Wissen, ohne die Inhalte offen ins Netz zu stellen. ```mermaid flowchart LR H[Agent-Host
Cursor, Claude Code] --> M[MCP Docs-Server
z. B. mcpdoc] M -->|Quellen auflisten| L[llms.txt
registrierte Indizes] M -->|Seite nachladen| P[nur die benötigte
.md-Seite] P --> H ``` Besonders `llms-full.txt` gewinnt in dieser Kombination. Man kann die Datei direkt als Wissensquelle an einen MCP-Server hängen – ohne Embedding-Pipeline, ohne Vektordatenbank, ohne die übliche RAG-Maschinerie. Die Taiga-UI-Komponentenbibliothek etwa stellt ihre gesamte Doku als `llms-full.txt` bereit und liefert einen MCP-Server mit, der genau darauf zeigt. Treffender als „Ersatz für RAG“ ist die Beschreibung als präzisere, werkzeuggestützte und prüfbare Variante davon: kein unvorhersehbares Ziehen aus einem großen Vektorindex, sondern ein nachvollziehbarer Zugriff auf kuratierte Seiten. ## Wo es hakt So klar der Nutzen im richtigen Umfeld ist, so offen sollte man die Schwachstellen benennen. `llms.txt` ist ein Vorschlag, kein verabschiedeter Standard. Es gibt kein Gremium dahinter, keine Garantie, dass ein bestimmtes Modell die Datei überhaupt liest. Man stellt sie bereit und hofft, dass die Gegenseite mitspielt – erzwingen lässt sich der Konsum nicht. Dann die Pflege. Zwei Fassungen desselben Inhalts – die Seite für Menschen, die Markdown-Fassung für Modelle – bedeuten zwei Dinge, die auseinanderlaufen können. Läuft die `llms-full.txt` der echten Doku hinterher, füttert man Modelle mit veralteten Ständen, und das ist schlimmer als gar keine Datei, weil es falsches Vertrauen erzeugt. Ohne automatische Erzeugung aus der eigentlichen Quelle ist Drift nur eine Frage der Zeit. Auch die Größe ist eine echte Grenze. Eine `llms-full.txt` mit mehreren Megabyte sprengt typische Kontextfenster und wird dann nur noch in Bruchstücken geladen – womit der Vorteil „alles in einer Anfrage“ dahin ist. Für große Sites ist die Vollfassung schlicht unrealistisch; es bleibt beim kuratierten Index auf die wirklich zentralen Seiten. Und schließlich die Vertrauensfrage. Sobald ein Agent eine fremde `llms-full.txt` ungeprüft übernimmt, übernimmt er Inhalt, den er nicht kontrolliert. Das ist dieselbe Angriffsfläche wie bei jeder externen Datenquelle, die in den Kontext wandert – ein guter Grund, gerade über einen MCP-Server mit Domain-Beschränkung zu gehen, statt beliebige Adressen einzusammeln. ## Fazit `llms.txt` und `llms-full.txt` sind keine SEO-Werkzeuge, auch wenn sie oft als solche verkauft werden. Sie sind eine Konvention für Kuratierung und gezieltes Nachladen: der Index sagt, was zählt und wo es liegt; die Vollfassung liefert den Inhalt am Stück; die `.md`-Spiegel geben einzelne Seiten in der Form, die Modelle ohnehin bevorzugen. Ihr Wert entsteht dort, wo Dokumentation auf Agenten trifft – bei SDKs, API-Referenzen und Coding-Werkzeugen –, und bleibt bei klassischen Inhalten überschaubar. Der eigentliche Hebel liegt in der Paarung mit einem MCP-Server. Erst dadurch wird aus einer statischen Datei ein dosiertes, prüfbares und zugriffskontrolliertes Retrieval – nah an dem, was man von einer RAG-Lösung erwartet, nur schlanker und ehrlicher nachvollziehbar. Wer den Aufwand scheut, sollte die Dateien weglassen; wer sie pflegt, sollte sie aus der Quelle erzeugen und nicht von Hand nachziehen. Wie sagt man so schön – das Eisen schmieden, solange es heiß ist: Solange Agenten die Regel sind und nicht die Ausnahme, ist eine gepflegte `llms.txt` an der richtigen Stelle eine kleine Investition mit spürbarer Wirkung. ## Weiterführende Quellen - Der ursprüngliche Vorschlag und die Formatbeschreibung: [llmstxt.org](https://llmstxt.org/) - Repository zum Vorschlag: [AnswerDotAI/llms-txt](https://github.com/answerdotai/llms-txt) - MCP-Doku-Server, der `llms.txt` als Quelle liest: [langchain-ai/mcpdoc](https://github.com/langchain-ai/mcpdoc) - Model Context Protocol: [modelcontextprotocol.io](https://modelcontextprotocol.io/)