Muster schlagen Syntax — welcher Docs-Typ ihr seid
Die Syntax von llms.txt ist trivial: Überschriften und Links. Schwierig ist die redaktionelle Form — abhängig davon, ob ihr API-Referenz, Help Center oder Developer Portal betreibt. Ein universelles Template wirkt valide, hilft Agenten aber selten.
Kernfrage: Welchen Job soll die Datei für das Modell erledigen? Erste erfolgreiche API-Anfrage, Support-Diagnose oder mentales Modell einer Plattform — drei verschiedene Antworten, drei verschiedene Strukturen.
Grundlagen: Was ist llms.txt?. Wenn der Index steht, folgt oft Content Negotiation.
Muster 1: API-Dokumentation
Agenten fragen typischerweise: Wie authentifiziere ich mich? Welcher Endpoint? Pflichtfelder? Fehler und Rate Limits? Welches SDK? Die llms.txt optimiert auf ersten erfolgreichen Request und wiederkehrende Implementations-Tasks.
Struktur: Kurzintro → Start Here (Quickstart, Auth, API-Overview) → Kern-Tasks (konkrete Endpoints/Guides) → Betrieb (Errors, Rate Limits, Pagination) → SDKs. Meinung statt Spiegelbild der Sidebar — Authentication und Webhooks vor abstrakten Kategorien wie „Resources“.
Typischer Fehler in Beratungsprojekten: Top-Level-Nav 1:1 übernehmen. Agenten profitieren von task-orientierten Gruppen, nicht von interner Taxonomie.
# Acme API
REST-API für Zahlungen, Webhooks und Reporting.
## Start Here
- [Quickstart](https://docs.acme.com/quickstart): Erster Request in 5 Minuten
- [Authentication](https://docs.acme.com/auth): API Keys (empfohlen) und OAuth
- [API Overview](https://docs.acme.com/api): Ressourcen und Idempotency
## Kern-Tasks
- [Create Payment](https://docs.acme.com/payments/create)
- [Webhooks](https://docs.acme.com/webhooks)
## Betrieb
- [Errors](https://docs.acme.com/errors)
- [Rate Limits](https://docs.acme.com/rate-limits)Muster 2: Help Center
Help Center sind diagnostisch: Warum geht X nicht? Wo stelle ich Y ein? Was bedeutet Fehler Z? Wie verbinde ich Integration A? Die llms.txt priorisiert Workflows, Troubleshooting und Account-Themen — nicht API-Primitive.
Sinnvolle Abschnitte: Start Here (Getting Started, Workspace, Team einladen) → Häufige Probleme (Login, Berechtigungen, Integrationen) → Schlüssel-Workflows (Billing, Rollen, Slack o. ä.).
Vermeiden: interne Team-Ownership-Labels (Accounts, Workspace, Integrations) als oberste Struktur — Nutzer und Modelle formulieren in Problemen, nicht in Org-Charts.
Muster 3: Developer Docs (Plattform, CLI, Deployment)
Developer Docs liegen zwischen API-Referenz und Produktguidance: Konzepte, lokales Setup, CLI, Deployment, Architektur. Die llms.txt baut ein mentales Modell, nicht nur den ersten Endpoint.
Struktur: Quickstart, Local Development, Auth → Kern-Konzepte (Architektur, Datenmodell, Umgebungen) → Build & Ship (CLI, Deployments, Webhooks) → Referenzen (REST, SDKs). Konzeptseiten weglassen bei trivialen APIs; bei Plattformen und CLIs sind sie Pflicht.
Für DACH-Agenturen: Wenn der Kunde Convex, eigene Agenten oder Multi-Env-Setup dokumentiert — Konzept-Links in llms.txt, sonst raten Modelle falsche Pfade.
Editorial-Test und schrittweiser Rollout
Vor Go-Live: Würde ein erfahrener Engineer in 60 Sekunden genau diese Link-Liste einem Agenten geben? Wenn nein — weiter schneiden. llms.txt ist komprimiertes redaktionelles Urteil, kein Compliance-Häkchen.
Start klein: Intro, ein Start Here, ein bis zwei Task-Gruppen, 10–20 Links. Nach echten Agent-Fragen und Support-Tickets nachschärfen. Nicht zwischen Mustern mischen — API-Sections im Help Center helfen niemandem.
Nächste Layer: skill.md für Nutzungslogik, MCP für live Suche — siehe MCP für Docs und SaaS.
