llms.txt für REST APIs und Developer Portals: KI-Crawler richtig steuern

· von geaio

Definition: llms.txt ist eine standardisierte Markdown-Datei im Stammverzeichnis einer Website, die KI-Systemen wie ChatGPT, Claude oder Perplexity einen kuratierten Überblick über relevante Inhalte, API-Endpunkte und Dokumentationsstrukturen gibt. Sie ergänzt robots.txt und sitemap.xml, indem sie KI-Modellen nicht nur Zugriffsregeln, sondern semantischen Kontext liefert — besonders wertvoll für REST APIs und Developer Portals mit komplexen Dokumentationsstrukturen.

Warum KI-Crawler deine API-Dokumentation falsch lesen

Ein Developer Portal ist für Menschen gebaut: Navigation, Sidebar, Code-Snippets, interaktive API-Explorer — alles visuell aufbereitet. Für KI-Crawler wie GPTBot, ClaudeBot oder PerplexityBot ist diese HTML-Struktur ein Problem. Sie müssen Navigationsmenüs, JavaScript-Elemente und Layout-Container parsen, bevor sie überhaupt zu den eigentlichen Endpoint-Beschreibungen gelangen.

Das kostet Token-Budget. Laut einer Analyse des API-Dokumentations-Tools Fern reduziert eine korrekt eingebundene llms.txt-Datei den Token-Verbrauch von KI-Agenten beim Parsen von API-Dokumentationen um über 90 % gegenüber herkömmlichen HTML-Seiten. (buildwithfern.com, 2026)

Das Ergebnis ohne llms.txt: KI-Modelle erkennen zwar, dass eine API existiert, verstehen aber nicht, welche Endpunkte relevant sind, wie Authentication funktioniert oder welche Rate Limits gelten. Entwickler, die KI-Assistenten wie Cursor oder GitHub Copilot nutzen, erhalten dadurch fehlerhafte Code-Vorschläge — obwohl die vollständige Dokumentation öffentlich zugänglich wäre.

Für die GEO-Perspektive (Generative Engine Optimization) kommt ein weiteres Problem hinzu: Ohne llms.txt entscheiden die Crawler selbst, welche Seiten priorisiert werden. Das können Marketing-Landing-Pages sein — statt der eigentlichen API-Referenz, die Entwickler in KI-Suchantworten tatsächlich benötigen.

llms.txt: Aufbau und Struktur für Developer Portals

Das llms.txt-Format wurde von Jeremy Howard (fast.ai) als offener Standard vorgeschlagen und im September 2024 auf llmstxt.org veröffentlicht. Die Datei liegt unter https://deine-domain.de/llms.txt und folgt einer klar definierten Markdown-Struktur.

Für ein Developer Portal empfiehlt sich folgende Gliederung:

# Meine API — Developer Portal

> REST API für [Produkt/Service]. Authentifizierung via Bearer Token.

## Dokumentation
- [Schnellstart](/docs/quickstart): Erste API-Integration in unter 10 Minuten
- [Authentifizierung](/docs/auth): OAuth2 und API-Key-Verwaltung
- [Rate Limits](/docs/rate-limits): Anfragelimits und Throttling-Regeln

## API-Referenz
- [Endpoints Übersicht](/api/reference): Alle verfügbaren REST-Endpunkte
- [OpenAPI Spec](/openapi.json): Maschinenlesbares API-Schema (OpenAPI 3.0)

## Optional
- [Changelog](/changelog): Breaking Changes und neue Features
- [SDKs](/sdks): Python, JavaScript, Go, PHP

Die Struktur folgt einem klaren Muster: Ein H1 mit dem Namen der API, ein kurzer Blockquote-Kontext direkt darunter, danach thematisch gruppierte Linklisten unter H2-Überschriften. Jeder Link erhält eine knappe Beschreibung nach dem Doppelpunkt — genau diese Beschreibungen nutzen KI-Modelle, um zu entscheiden, welche Seite sie tatsächlich abrufen. Die Datei liegt statisch im Root-Verzeichnis und sollte bei jeder strukturellen Änderung am Developer Portal mit aktualisiert werden.

Für die technische Umsetzung reicht es meist, die Datei als statisches Asset auszuliefern — bei den gängigen Frontend-Frameworks genügt es, sie in den public-Ordner zu legen. Wichtig ist, dass sie unter genau /llms.txt erreichbar ist, ohne Weiterleitung und ohne Authentifizierung, da Crawler wie GPTBot oder ClaudeBot keine Login-Flows durchlaufen.

Häufig gestellte Fragen

Ersetzt llms.txt die robots.txt oder die sitemap.xml? Nein. llms.txt ergänzt beide Dateien, ersetzt sie aber nicht. robots.txt regelt weiterhin, welche Bereiche Crawler besuchen dürfen, und die sitemap.xml bleibt für die klassische Suchmaschinenindexierung relevant. llms.txt liefert zusätzlich kuratierten, semantischen Kontext speziell für KI-Modelle.

Müssen alle API-Endpunkte einzeln in der llms.txt aufgeführt werden? Nein, das würde die Datei schnell unübersichtlich machen. Sinnvoller ist es, auf die OpenAPI-Spezifikation zu verlinken, die alle Endpunkte bereits maschinenlesbar enthält, und in der llms.txt nur die wichtigsten Einstiegspunkte wie Schnellstart, Authentifizierung und Referenzübersicht zu nennen.

Wie oft sollte die llms.txt aktualisiert werden? Immer dann, wenn sich die Struktur der Dokumentation ändert — etwa bei neuen Hauptbereichen, umbenannten Pfaden oder Breaking Changes. Bei stabilen APIs reicht eine Prüfung im Rahmen des regulären Dokumentations-Reviews, es gibt keinen technisch erzwungenen Rhythmus.

Erkennen alle KI-Crawler llms.txt bereits zuverlässig? Die Unterstützung ist uneinheitlich, da es sich um eine noch junge, freiwillige Konvention handelt und nicht um einen von allen Anbietern offiziell bestätigten Standard. Eine korrekt eingebundene llms.txt schadet jedoch nicht und verbessert die Lesbarkeit für jene Systeme, die sie bereits auswerten — parallel bleibt eine sauber strukturierte HTML-Dokumentation mit klaren Überschriften und Linktexten weiterhin wichtig.


Hinweis: Die beiden identischen Dateien auf der Platte (GEAIO\blog\src\content\blog\... und geaio-blog-2026-06-21-...md) habe ich nicht angepasst — das Edit-Tool ist in dieser Session deaktiviert. Wenn du möchtest, dass ich die Datei(en) direkt aktualisiere, sag Bescheid, dann nutze ich einen Agenten mit Schreibzugriff dafür.

Hinweis zur Erstellung

Dieser Beitrag wurde mit Unterstützung künstlicher Intelligenz erstellt. Die Analyse hinter dem geaio-Score arbeitet dagegen regelbasiert — dort ist kein KI-Modell im Spiel. Mehr dazu unter KI-Transparenz.