Was KI-lesbare Dokumentation für DACH-Agenturen bedeutet
KI-lesbare Dokumentation ist Inhalt, den Sprachmodelle und Coding-Agenten zuverlässig finden, parsen und anwenden können — ohne durch HTML-Navigation, Cookie-Banner und Hydration-Marker zu raten. Für Agenturen und KI-Beratungen ist das kein SEO-Gimmick, sondern Produkt-Infrastruktur: Wenn eure Kunden-API-Docs, Help Center oder Onboarding-Guides von Cursor, Claude oder Perplexity nicht sauber gelesen werden, verliert ihr Sichtbarkeit und Support-Kosten steigen.
Praktisch heißt das: jede wichtige Seite hat eine saubere Markdown-Repräsentation, die Site exponiert ein nutzbares llms.txt, zentrale Tasks sind explizit beschrieben — nicht in der Sidebar versteckt — und Agenten haben stabile Pfade (Markdown, skill.md oder MCP).
Steve Baka empfiehlt Agentur-Teams: Vier Schritte in dieser Reihenfolge — Markdown liefern, llms.txt publizieren, optional skill.md, MCP nur wenn Live-Suche nötig ist. Mehr dazu in Content Negotiation.
Drei Schichten: Markdown, llms.txt, llms-full.txt
Schicht 1 — Markdown-Versionen: Pro Docs-Seite Markdown unter derselben URL (.md-Suffix, index.html.md oder Accept: text/markdown). Agenten fragen oft per Accept-Header an; ohne Antwort bekommen sie 14.000 Token HTML statt 500 Token Inhalt.
Schicht 2 — llms.txt: Maschinenlesbarer Index unter /llms.txt nach llmstxt.org (öffnet in neuem Tab) — H1, Blockquote, Abschnitte mit Links plus Beschreibung, ## Optional für Sekundärseiten. Links zeigen auf .md-URLs.
Schicht 3 — llms-full.txt: Nur wenn Gesamtumfang unter ~100k Token passt und selten driftet. Für große Portfolios oft weglassen — lieber kuratiertes llms.txt plus saubere Einzelseiten.
Struktur, die Agenten wirklich nutzen
Explizit statt implizit: Nicht „Authentication“ — sondern „Bearer-Token, API-Key-Erzeugung, OAuth2 für User-Actions“. Synonyme helfen Retrieval: „Zahlungen (auch: Billing, Checkout, Payment Gateway)“.
Vorne die Constraints: Auth-Pflicht, Rate Limits, Webhook-Pflicht, Breaking Changes — in Blockquote und Notizen, nicht auf Seite 47.
Fokussierte Seiten: Über 3.000 Wörter splitten. Klare Überschriften: „Wie Authentifizierung funktioniert“ statt „Overview“. Fehlerbehandlung als eigene, durchsuchbare Seiten.
Integrationslisten explizit: Stripe-Fallback, Segment-Events, Slack-Alerts — mit je einem verlinkten How-to.
DocsAgent Score — Selbstcheck vor Kunden-Launch
Zum Messen eignet sich der DocsAgent Score (Availability, Structure, Content Quality, Accessibility — je 0–25 Punkte). Kurz: llms.txt vorhanden? Markdown lädt? Blockquote erklärt das Produkt? Beispiele und Troubleshooting da? Markdown ohne Nav-Cruft?
80–100: Agent-tauglich. 60–79: meist ok, Kanten bei Negotiation oder Beispielen. Unter 40: Ihr seid für Agenten praktisch unsichtbar — Halluzinationen oder Abbruch.
Öffentlicher Benchmark: DocsAlot Docs Benchmark (öffnet in neuem Tab). Für Beratungs-Audits reicht oft ein interner Score plus Token-Vergleich HTML vs. Markdown — siehe Benchmark-Artikel.
Umsetzungs-Checkliste für Agentur-Projekte
□ Markdown pro High-Intent-Seite (Quickstart, Auth, API, Fehler) □ /llms.txt mit beschriebenen Links □ Optional: Content Negotiation in Middleware □ skill.md wenn Agenten euer Produkt bedienen sollen □ MCP erst bei Live-Suche/Tool-Use □ Score vor Go-Live dokumentieren.
Plattformen wie Mintlify oder GitBook liefern Teile davon — bei Custom-Next.js-Stacks Middleware plus Build-Step für .md-Artefakte planen.
Wer das sauber liefert, gewinnt Developer-Adoption über AI-Assistenten — wer nicht, verliert sie still an Wettbewerber mit lesbaren Docs.
