Was llms.txt für Agenten und Docs-Teams bedeutet
Wenn ihr Docs für ein SaaS-Produkt, eine API oder ein KI-Angebot pflegt, habt ihr bereits Struktur für Menschen und Suchmaschinen: Navigation, Sitemap, Quickstarts. llms.txt ist die fehlende Schicht für KI-Agenten — eine kleine, maschinenlesbare Datei, die sagt, welche Dokumentationsseiten wirklich zählen und wo man anfängt.
Technisch ist es Plain Text oder Markdown, meist unter /llms.txt auf dem Docs-Host. Kein neues Protokoll, sondern ein kuratiertes Inhaltsverzeichnis: Produktbeschreibung in einem Satz, dann gruppierte Links mit kurzen Erklärungen. Die Spezifikation auf llmstxt.org (öffnet in neuem Tab) ist knapp — für DACH-Beratungen zählt die redaktionelle Disziplin dahinter.
Steve Baka: Für Agentur-Kunden mit API-Docs oder Help Center ist llms.txt der schnellste Hebel für Agent-Readiness — ohne gleich MCP oder Skills zu bauen.
Was in eine gute llms.txt gehört — und was nicht
Der häufigste Fehler: llms.txt wie eine Sitemap behandeln und jede URL listen. Besser: 10–20 Seiten, die ein neuer Entwickler am ersten Tag braucht — Quickstart, Auth, zentrale API-Einstiege, Fehler, Rate Limits, Webhooks, relevante SDKs.
Gruppierung nach Aufgaben, nicht nach interner Nav-Struktur: Start Here, Häufige Tasks, SDKs. Mehrere Zielgruppen? Getrennte Abschnitte (API vs. Integrationen). Weglassen: Marketing, Changelog-Rauschen, doppelte Versionen, dünne oder veraltete Seiten, alles hinter Login.
Mehr Muster: llms.txt Beispiele in der Praxis. Grenzen der Datei allein: llms.txt reicht nicht — Content Negotiation.
llms.txt vs. sitemap.xml — unterschiedliche Jobs
sitemap.xml ist crawler-orientiert: Vollständigkeit, Änderungsdaten, Indexierung. llms.txt ist kuratiert: Nützlichkeit, Einstiegspfade, redaktionelle Priorität.
Eine gute Sitemap hilft bei Discoverability — sie sagt dem Modell aber nicht, welcher Quickstart kanonisch ist, ob OAuth oder API-Keys der empfohlene Auth-Pfad ist oder wo Webhook-Docs liegen. Genau diese Lücke schließt llms.txt.
Für Dienstleister: Beides parallel pflegen. Sitemap für SEO, llms.txt für Agenten — nicht gegenseitig ersetzen.
Implementierung in fünf pragmatischen Schritten
1. Kanonischen Host wählen — dort, wo Nutzer eure Docs erwarten (docs.kunde.de, nicht Marketing-Domain). 2. Top 10–20 Seiten editorial festlegen. 3. Unter `/llms.txt` ausliefern (Konvention, die Tools erwarten). 4. Mit curl testen — wenn Menschen es schwer lesen, tun es Modelle auch. 5. Pflegen wie Produkt-Infrastruktur: Auth-Modell, Default-SDK oder Quickstart ändert sich → llms.txt mit.
In Next.js oder statischen Generatoren: dynamische Route oder Build-Step aus der Artikel-/Docs-Quelle. CI-Check: gebrochene Links in llms.txt blockieren Deploy.
Nächste Schicht nach dem Index: skill.md als Agent-Skills-Standard und Markdown-Auslieferung statt HTML-Firehose.
# Acme API Docs
Technische Dokumentation für Acme API: Setup, Auth, Endpoints, SDKs, Webhooks.
## Start Here
- [Quickstart](https://docs.acme.com/quickstart): Erster erfolgreicher Request
- [Authentication](https://docs.acme.com/auth): API Keys und OAuth
- [API Overview](https://docs.acme.com/api): Kernkonzepte
## Häufige Tasks
- [Webhooks](https://docs.acme.com/webhooks): Events empfangen und verifizieren
- [Errors](https://docs.acme.com/errors): Fehlercodes debuggen
- [Rate Limits](https://docs.acme.com/rate-limits): Retries und BackoffWas llms.txt allein nicht löst
llms.txt hilft bei Discovery, nicht automatisch bei Consumption. Aufgeblähtes HTML, schwache IA, fehlende Entscheidungstabellen, kaputte Beispiele — das bleibt. Agenten finden die Seite, verbrauchen aber weiter teuren Kontext.
Typische Lücken nach llms.txt: Content Negotiation (Accept: text/markdown), saubere Einzelseiten, optional MCP für Suche und gezieltes Laden. Für Beratungsangebote: llms.txt als Phase-1-Deliverable im Agent-Readiness-Audit, nicht als Endzustand.
Denkweise: Sidebar und Breadcrumbs für Menschen — llms.txt ist dieselbe redaktionelle Urteilsfähigkeit, explizit für Maschinen.
