Mike Bild
Blog

llms.txt: Doku für Maschinen

Kontext für Modelle, nicht fürs Ranking: warum llms.txt und llms-full.txt Coding-Agenten helfen – und was ein MCP-Server daraus macht.

≈ 9 Min. Lesezeit
SoftwareKIMethodik
Markdown In Claude öffnenIn ChatGPT öffnen

Diesen Beitrag anhören (14 Min.)

MP3 herunterladen

llms.txt liegt im Wurzelverzeichnis einer Website und sieht damit aus wie das nächste Signal für Suchmaschinen – ein Nachbar von robots.txt und sitemap.xml, angelegt in der Hoffnung auf Sichtbarkeit. Genau dieser Schluss geht am Zweck vorbei. Die Datei war nie als Ranking-Signal gedacht, und für eine Ranking-Wirkung liegt kein Beleg vor. Ihr Nutzen liegt nicht in Crawler-Signalen, sondern darin, Agenten kuratierten Dokumentationskontext bereitzustellen.

Es gibt zwei Dateien, llms.txt und llms-full.txt. Sie sehen nach Marketing-Infrastruktur aus, und ihr Nutzen liegt an einer anderen Stelle: bei der Frage, wie ein Modell an sauberen, kuratierten Kontext kommt, ohne sich vorher durch Navigationsleisten, Cookie-Banner und JavaScript zu arbeiten. Beide Dateien sind maschinenlesbare Selbstdokumentation eines Produkts.

Zwei Dateien, ein Problem

Den Vorschlag hat Jeremy Howard, Mitgründer von Answer.AI, am 3. September 2024 veröffentlicht; die Beschreibung steht 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 Site 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, was ein Modell bei knappem Platz zuerst weglassen darf. So kompakt sieht das aus:

# 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 konzeptionell schlichter: 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. Ein Agent oder Client kann den gebündelten Inhalt mit einer einzigen Anfrage laden, statt sich Seite für Seite durchzuhangeln – ob davon alles zur konkreten Aufgabe passt, ist eine andere Frage.

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 Seiten, die schon in der Form vorliegen, die ein Modell ohnehin am besten verarbeitet.

Wichtig ist die Abgrenzung, weil hier viel durcheinandergeht. robots.txt regelt, was ein Crawler anfassen darf. sitemap.xml hilft beim Indexieren. llms.txt tut keines von beidem: Die Datei ordnet ein und kuratiert, gedacht für den Moment der Inferenz, nicht für den Crawl. Ein Agent, der sie liest, bekommt eine redaktionelle Aussage darüber, was an einem Produkt zählt – kein Versprechen an eine Suchmaschine. Die drei Dateien schließen sich nicht aus, sie beantworten verschiedene Fragen.

flowchart TD
    A[Coding-Agent] -->|kennt llms.txt| B[llms.txt<br/>kuratierter Index]
    B --> C{Welche Seite<br/>brauche ich?}
    C -->|gezielt| D[seite.md<br/>saubere Markdown-Fassung]
    C -->|alles auf einmal| E[llms-full.txt<br/>gesamter Inhalt]
    A -.->|Alternative ohne llms.txt| F[HTML-Seite crawlen<br/>Navigation, Werbung, JS]
    F -.->|viel Rauschen| G[Kontextfenster voll,<br/>Inhalt verwässert]

Warum das etwas bringt

Beim Anbinden einer fremden Bibliothek lädt ein Agent ohne Markdown-Sicht häufig die vollständige HTML-Seite oder improvisiert fehlende Signaturen. Im ersten Fall zieht er Menü, Fußzeile und drei Codebeispiele herein, die er gar nicht braucht – ein spürbarer Teil des Fensters ist weg, bevor die eigentliche Aufgabe beginnt. Im zweiten Fall rät er. 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. Kuratiertes Markdown ohne Layout-Ballast bedeutet, dass mehr vom Fenster für den eigentlichen Inhalt übrig bleibt. Der Index zwingt außerdem zu einer Entscheidung: Nicht jede Seite ist gleich wichtig, und jemand mit Domänenwissen muss benennen, welche dreißig bis hundert Seiten den Kern ausmachen. Und wenn das Modell die genaue Fehlermeldung oder den exakten Parameter braucht, holt es sich die passende .md-Seite, statt zu improvisieren.

Der Punkt mit der Kuratierung wird oft übersehen. Eine gute llms.txt ist keine beliebige Linkliste, sondern eine redaktionelle Aussage darüber, was an einem Produkt zählt. Diese Festlegung ist die eigentliche Arbeit – nicht die Datei selbst.

Wo es sich lohnt

Für ein Blog oder eine Marketing-Seite bringt llms.txt wenig: Für eine Ranking-Wirkung liegt kein Beleg vor, und wer die Datei in der Hoffnung auf bessere Sichtbarkeit anlegt, wird enttäuscht. Wer eine solche Wirkung verspricht, verspricht zu viel.

Die Ausnahme ist eng, aber real: 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.

Für reine Marketingseiten ohne nachweisbare Agentennutzung rechtfertigt der Pflegeaufwand die Datei meist nicht; bei regelmäßig abgefragter technischer Dokumentation kann er sich lohnen. Server-Logs mit Anfragen auf /llms.txt liefern dafür einen Nutzungshinweis, tragen die Entscheidung aber nicht allein: Ausbleibende direkte Zugriffe belegen nicht zwingend fehlende Nutzung, etwa wenn dieselben Inhalte über andere Wege wie MCP-Ressourcen abgerufen werden.

Aus der Quelle erzeugt, nicht von Hand gepflegt

Ein zentrales Risiko beim Einsatz ist organisatorisch, nicht technisch: zwei Fassungen desselben Inhalts, die getrennt gepflegt werden. Die Seite für Menschen hier, die Markdown-Fassung für Modelle dort. 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 derselben Quelle ist Drift nur eine Frage der Zeit.

Deshalb gehören beide Dateien in den Build, nicht in den Editor. Stand August 2026 zeigt sich das in meinen eigenen Produkten: ContentKit erzeugt pro Site und Locale llms.txt, llms-full.txt und Markdown-Zwillinge aus dem veröffentlichten Stand. WikiKit, WatchKit, WorkKit und CodeKit liefern llms.txt beziehungsweise llms-full.txt jeweils als eigene Selbstdokumentation aus. Entscheidend ist die gemeinsame Quelle für menschliche und maschinenlesbare Ausgaben; eine zweite, von Hand gepflegte Dokumentation würde erneut Drift ermöglichen.

Das ist die zweite Hälfte der Kuratierungsarbeit. Die redaktionelle Entscheidung, was in den Index gehört, trifft ein Mensch. Die Erzeugung der Dateien übernimmt der Build. Wer beides von Hand macht, hat sich eine zweite Doku eingehandelt, die leicht vom veröffentlichten Stand abweicht.

Was ein MCP-Server daraus macht

Bis hierhin ist llms.txt eine statische Datei, die jemand irgendwann abholt. MCP ergänzt den statischen Index um gezielten Zugriff auf Ressourcen und Operationen. Das Model Context Protocol ist das offene Protokoll, das Anthropic Ende 2024 vorgestellt hat und über das ein Agent standardisiert mit externen Werkzeugen und Datenquellen spricht.

llms.txt beschreibt als Index, welche Inhalte es gibt und wo sie liegen; ein MCP-Server stellt Ressourcen und Operationen gezielt bereit. 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.

Ein darauf ausgelegter MCP-Doku-Server kann Kontext gezielt nachladen, Aufrufe protokollierbar machen und Zugriffe beschränken – drei Verbesserungen gegenüber dem bloßen Herunterladen der Datei.

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 – der Bereich zwischen „gar kein Kontext“ und „alles auf einmal“.

Zweitens die Nachvollziehbarkeit. Bei einem Doku-Server wie mcpdoc läuft das Nachladen über Werkzeugaufrufe, die man prüfen kann: welche Adresse geladen wurde und was zurückkam. Für Ressourcenabrufe gilt das nicht automatisch; dort braucht es eine eigene Protokollierung auf der Serverseite. Ein direkter Download der Datei hinterlässt diese Spur im Agenten-Workflow nicht zwangsläufig. Bei interner oder geschützter Dokumentation kann diese Prüfbarkeit den zusätzlichen Betriebsaufwand rechtfertigen.

Drittens die Zugriffskontrolle. Der Server lässt sich auf erlaubte Domains beschränken, und für interne oder geschützte Doku legt man Authentifizierung davor. Wer berechtigungsgebundenen Zugriff braucht, kann die Dokumentation über einen authentifizierten MCP-Server als Ressource anbieten und dort Berechtigungen für jeden Abruf prüfen. Damit trägt die Konvention auch hinter der Firmen-Firewall: Der Server zeigt auf eine private llms.txt, und Modelle im Team bekommen kuratiertes Wissen, ohne dass die Inhalte offen im Netz stehen.

Wie das architektonisch aussieht, wenn beides aus einem Produkt kommt, zeigt ContentKit. Stand August 2026 bietet es neben den erzeugten Dateien eine Remote-MCP-Oberfläche. MCP-Ressourcen sind dort anwendungsverwalteter Kontext, den der Server dem Client als Dokumentation anbietet. Werkzeuge bleiben davon getrennt: Sie bilden domänenbezogene Operationen ab und werden erst mit dem passenden Scope sichtbar. Mehrere der Kits stellen ihre eigene llms.txt-Dokumentation zusätzlich als MCP-Ressource bereit, sodass ein Client Werkzeugmodell und API-Grenzen lesen kann, ohne eine Webseite zu erraten. MCP ergänzt die statische Dokumentation also um gezielten Zugriff und um Operationen; berechtigungsgebunden wird dieser Zugriff erst, wenn der Server Ressourcenabrufe authentifiziert und autorisiert. Die Dokumentation ersetzt MCP nicht – ohne erzeugte, aktuelle Maschinensichten fehlte diesen Dokumentationsressourcen eine verlässliche Grundlage.

flowchart LR
    H[Agent-Host<br/>Cursor, Claude Code] --> M[MCP Docs-Server<br/>z. B. mcpdoc]
    M -->|Quellen auflisten| L[llms.txt<br/>registrierte Indizes]
    M -->|Seite nachladen| P[nur die benötigte<br/>.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. Treffender als „Ersatz für RAG“ ist die Beschreibung als werkzeuggestützte, prüfbare Variante davon: kein unvorhersehbares Ziehen aus einem großen Vektorindex, sondern nachvollziehbarer Zugriff auf kuratierte Seiten.

Wo es hakt

llms.txt ist ein Vorschlag, kein verabschiedeter Standard. Es gibt kein Gremium dahinter und keine Garantie, dass ein bestimmtes Modell die Datei liest. Man stellt sie bereit; erzwingen lässt sich der Konsum nicht.

Die Größe ist eine echte Grenze. Eine mehrere Megabyte große llms-full.txt kann je nach Tokenisierung, Modell und Clientlimit nicht vollständig in den verfügbaren Kontext passen und wird dann nur in Bruchstücken geladen – womit der Vorteil „alles in einer Anfrage“ dahin ist. Für große Sites bleibt es beim kuratierten Index auf die wirklich zentralen Seiten, ergänzt um gezieltes Nachladen einzelner .md-Fassungen.

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, über einen MCP-Server mit Domain-Beschränkung zu gehen, statt beliebige Adressen einzusammeln.

Fazit

llms.txt und llms-full.txt sind maschinenlesbare Selbstdokumentation. 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 bevorzugen. Ein belastbarer Ranking-Faktor ist keines davon, und wer die Dateien mit dieser Erwartung anlegt, misst am falschen Ziel. Ihr Wert entsteht dort, wo Dokumentation auf Agenten trifft – bei SDKs, API-Referenzen und Coding-Werkzeugen.

Daraus folgen zwei Entscheidungen. Erstens: Die Dateien werden aus derselben Quelle erzeugt wie die Dokumentation für Menschen, oder man lässt sie weg – ein handgepflegter Doppelbestand driftet und untergräbt genau das Vertrauen, das er stiften soll. Zweitens: Wer gezielten oder berechtigungsgebundenen Zugriff braucht, kann die Dokumentation über einen authentifizierten MCP-Server als Ressource anbieten und dort Berechtigungen prüfen. MCP kann die statischen Sichten so um dosierten, prüfbaren und – bei serverseitiger Autorisierung – berechtigungsgebundenen Zugriff ergänzen; es bleibt darauf angewiesen, dass die Dokumentation dahinter stimmt.

Weiterführende Quellen

Wie fandest du diesen Beitrag?

Kommentare