Warum Agenturen einen neutralen Docs-Benchmark brauchen
Coding-Agenten lesen Dokumentation häufiger als Menschen — bei API-Integration, Auth-Flows und Troubleshooting. Scheitern sie an fehlendem llms.txt, HTML-only oder Beispiellücken, ist das kein Modellproblem, sondern Interface-Design.
Der öffentliche DocsAlot-Benchmark (öffnet in neuem Tab) misst eine enge Frage: Kann ein Agent eure Docs entdecken, maschinenlesbar abrufen, Struktur verstehen und genug Kontext für den nächsten Schritt finden — ohne zu raten?
Steve Baka nutzt solche Scores in KI-Beratung als objektives Vorher/Nachher — nicht als Marketing-Ranking, sondern als Diagnose: Welcher Bucket fehlt?
Vier gewichtete Buckets — was wirklich geprüft wird
1. Discovery & Delivery: Existiert /llms.txt? /llms-full.txt? Haben Stichproben-Seiten gültige .md-Versionen? Sampling aus llms.txt-Links, sonst Fallback /getting-started, /api, /reference.
2. Content Structure: H1, Blockquote, sinnvolle H2-Abschnitte, Links mit Beschreibungen, ## Optional — angelehnt an AFDocs (öffnet in neuem Tab). Ein leeres llms.txt bringt null Punkte.
3. Task Readiness: Produktbeschreibung, Prerequisites, Integrationen, Fehlerbehandlung, Code-Beispiele. Polierte UI hilft nicht, wenn Auth unklar bleibt.
4. Access & Recovery: Markdown liefert Markdown (nicht HTML-Fehlerseiten), akzeptable Latenz, kein JS-Pflicht-Rendering, Accept: text/markdown, sauberer Body ohne Nav/Footer-Müll.
Vendor-Neutralität als Diagnose, nicht als Werbung
Benchmarks scheitern, wenn der Anbieter gleichzeitig Test und Sieger ist. Nützlich ist ein Tool, das unbequeme Ergebnisse zulässt: Open-Source schlägt Commercial, schlichtes Design schlägt Fancy — weil Machine-Delivery besser ist.
Leaderboards zeigen eine Zahl; entscheidend ist das Failure Pattern: Fehlt llms.txt? Ist Markdown dreckig? Keine Beispiele? Agentur-Reports sollten Bucket-Breakdowns liefern, nicht nur „Score 62“.
Benchmark-Mode ohne versteckte Host-Ausnahmen — sonst kein Vertrauen beim Kunden-Audit.
Grenzen — was der Benchmark nicht misst
Kein End-to-End-Workflow, keine Code-Validierung, keine live API-Calls. Es misst Docs-Operability, nicht Software-Operability.
Trotzdem relevant: Docs sind oft der erste Kontakt von Agenten mit eurem Produkt — scheitert der, bricht Adoption ab, bevor Menschen eingreifen.
Separate Benchmarks für CLI, Auth und Recovery folgen logisch — siehe Man-Pages für CLIs.
So setzt ihr den Benchmark in Beratung ein
1. Baseline vor Projektstart erfassen. 2. Maßnahmen nach Bucket priorisieren (Discovery vor Copywriting). 3. Nach Deploy erneut messen — gleiche Methodik-Version.
Verknüpft mit Dokumentation KI-lesbar machen für Umsetzung und llms.txt reicht nicht für Negotiation.
Enge Claims sind nützliche Claims — der Benchmark sagt nicht „beste Docs der Welt“, sondern „agentenlesbar genug für den nächsten Schritt“.
