llms.txt: Was die Datei ist, was sie nicht leistet und wie Sie eine erstellen

Was der llms.txt-Vorschlag festlegt

Jeremy Howard hat den Vorschlag am 3. September 2024 veröffentlicht. Der aktuelle Text auf llmstxt.org ist Version 2, zuletzt geändert am 10. August 2026. Es handelt sich um eine informelle Übersicht in einem öffentlichen GitHub-Repository, offen für Beiträge aus der Community, nicht um einen Standard von IETF oder W3C. Keine Suchmaschine und kein KI-Anbieter ist verpflichtet, die Datei zu lesen.

Die Datei ist in Markdown geschrieben, ihre Teile stehen in fester Reihenfolge:

1. Eine H1 mit dem Namen der Website oder des Projekts. Nur dieser Teil ist Pflicht.
2. Ein Blockzitat mit einer kurzen Zusammenfassung der wichtigsten Fakten.
3. Optional Absätze oder Listen mit weiterem Kontext, ohne Überschriften.
4. Null oder mehr H2-Abschnitte mit Dateilisten: Listeneinträge mit einem Link, optional gefolgt von einem Doppelpunkt und einer Notiz, etwa - [Preise](https://example.com/preise): Tarife und Limits.

Ein Abschnitt namens Optional enthält nachrangige Links, die ein Agent überspringen kann, wenn er mit weniger Kontext auskommen muss.

Die Datei kann im Wurzelverzeichnis liegen oder unter einem Pfad wie /docs/llms.txt. Sie gilt für die URLs unterhalb ihres Pfads; greifen mehrere Dateien, sollen Agenten die spezifischste verwenden. Der Vorschlag nutzt /.well-known/ nicht, weil Well-known-Pfade nur im Wurzelverzeichnis des Origins existieren und viele Autoren auf einem geteilten Host nur einen Pfad kontrollieren.

Außerdem schlägt er saubere Markdown-Kopien der Seiten unter derselben URL vor, mit angehängtem .md (page.html.md) oder, seit Version 2, mit ersetzter Endung (page.md). Version 2 ergänzt zwei Link-Relationen, gesendet als HTML-Elemente <link> oder als HTTP-Header Link: rel="alternate" type="text/markdown" für die Kopie und rel="describedby" für die llms.txt, die die Seite abdeckt. Eine Begleitdatei wie llms-full.txt definiert der aktuelle Text nicht; wenn ein Werkzeug oder eine Dokumentationsplattform eine erzeugt, ist das deren eigene Konvention.

Wie sich llms.txt von robots.txt und sitemap.xml unterscheidet

Die drei Dateien erfüllen verschiedene Aufgaben für verschiedene Leser.

Der Vorschlag zieht dieselbe Grenze: robots.txt legt fest, welcher automatisierte Zugriff akzeptabel ist, llms.txt wird bei Bedarf genutzt. Eine Sitemap ist laut Vorschlag kein Ersatz: Ihr fehlen oft Markdown-Versionen der Seiten, sie enthält keine URLs auf anderen Websites und umfasst meist mehr Inhalt, als in das Kontextfenster eines Modells passt.

Wenn Sie einen KI-Crawler zulassen oder sperren wollen, bearbeiten Sie also die robots.txt. Eine Seite, die in llms.txt fehlt, ist damit nicht versteckt, und eine dort gelistete Seite hebt keine robots.txt-Regel auf, die einen Crawler blockiert. Der Leitfaden zu robots.txt erklärt, wie Regeln abgeglichen werden.

Was Google und KI-Anbieter zu llms.txt sagen

Das sagen die Primärquellen:

• Google-Suche. Ihr Leitfaden zu generativen KI-Funktionen (aktualisiert am 10. Juli 2026) sagt, dass Sie keine maschinenlesbaren Dateien, KI-Textdateien oder Markdown brauchen, um in der Google-Suche einschließlich ihrer KI-Funktionen zu erscheinen, weil die Suche sie nicht verwendet. llms.txt wird ausdrücklich genannt: Eine solche Datei für andere Dienste vorzuhalten, ist in Ordnung; auf Sichtbarkeit und Ranking in der Google-Suche wirkt sie sich aber weder positiv noch negativ aus.
• Chrome Lighthouse. Die experimentelle Kategorie Agentic Browsing (ab Chrome 150, ohne Score von 0 bis 100) enthält ein llms.txt-Audit, das im Wurzelverzeichnis der Domain nach der Datei sucht. Ein Serverfehler wird gemeldet; ein 404 gilt als nicht zutreffend, weil die Datei optional ist. Das ist eine Prüfung auf Vorhandensein in einem Entwicklerwerkzeug, keine Aussage, dass ein Such- oder KI-Produkt die Datei nutzt.
• OpenAI. Die Crawler-Seite erklärt die robots.txt-Steuerung für OAI-SearchBot (Suchergebnisse in ChatGPT) und GPTBot (Training) und merkt an, dass von Nutzern ausgelöste Abrufe durch ChatGPT-User robots.txt womöglich nicht befolgen. Dass OpenAI die llms.txt einer Website liest, steht dort nicht.
• Anthropic. Der Hilfeartikel nennt ClaudeBot, Claude-User und Claude-SearchBot und sagt, dass sie robots.txt beachten. llms.txt erwähnt er nicht.
• Perplexity. Die Dokumentation behandelt PerplexityBot für Suchergebnisse und den von Nutzern ausgelösten Abrufer Perplexity-User, der robots.txt im Allgemeinen ignoriert. Dass Perplexity die llms.txt einer Website liest, steht dort nicht.
• Microsoft Bing. Eine Aussage von Microsoft oder Bing zu llms.txt war nicht zu finden. Die Ankündigung vom Februar 2026 zu AI Performance in den Bing Webmaster Tools erwähnt die Datei nicht.

Mit Stand 1. Oktober 2026 dokumentiert keiner dieser Anbieter, dass er die llms.txt einer Website für Ranking, Quellenangaben oder Antworten nutzt. Mehrere von ihnen veröffentlichen selbst eine llms.txt für ihre Entwicklerdokumentation (OpenAI, Anthropic, Perplexity und Google für die Gemini-API), ebenso Cloudflare. Eine Datei für die eigene Dokumentation zu veröffentlichen, ist etwas anderes, als die Dateien anderer Websites zu lesen.

Wann sich llms.txt lohnt und wann sie warten kann

Die Datei ist schnell geschrieben und laut Google in der Suche unschädlich. Die eigentlichen Kosten liegen darin, sie aktuell zu halten.

Ein schneller Test: Würde ein Entwickler Ihre URL in einen Coding-Assistenten einfügen und ihn bitten, mit Ihrem Produkt zu arbeiten? Wenn ja, ist ein Nachmittag für eine llms.txt mit Markdown-Kopien der wichtigsten Seiten gut investiert. Wollen Sie dagegen in Antworten zu einem lokalen Angebot genannt werden, etwa als Handwerksbetrieb oder Praxis, investieren Sie diesen Nachmittag lieber in klare Seiteninhalte und Crawler-Zugang. Sollen Agenten mit Ihrem Produkt arbeiten, statt nur darüber zu lesen, sehen Sie sich eine API oder einen MCP-Server an; die Einführung in MCP erklärt, wie das funktioniert.

Ein minimales llms.txt-Beispiel für eine kleine Website

Eine vollständige Datei für eine hypothetische App zur Schichtplanung unter example.com:

# Beispiel Schichtplan

> Beispiel Schichtplan ist eine browserbasierte App für die Schichtplanung in kleinen Cafés, Bäckereien und Läden. Ein kostenloser Tarif deckt einen Standort ab; kostenpflichtige Tarife ergänzen weitere Standorte.

Beispiel Schichtplan übernimmt keine Lohnabrechnung. Zuletzt geprüft: 2026-10-01.

## Dokumentation

- [Erste Schritte](https://example.com/docs/erste-schritte.md): Standort anlegen, Mitarbeitende hinzufügen und die erste Woche veröffentlichen
- [Schichtvorlagen](https://example.com/docs/vorlagen.md): Wiederkehrende Schichten, Pausen und Vertretungsregeln
- [API-Referenz](https://example.com/docs/api.md): REST-Endpunkte, Authentifizierung und Rate-Limits

## Produkt

- [Preise](https://example.com/preise): Tarife, Limits und was jeder Tarif enthält
- [Daten und Datenschutz](https://example.com/datenschutz): Wo Daten gespeichert werden und wie man sie exportiert oder löscht

## Optional

- [Änderungsprotokoll](https://example.com/changelog): Versionshinweise nach Monat

• Als Text ausliefern. https://example.com/llms.txt sollte mit Status 200 und dem Markdown selbst antworten. Single-Page-Apps beantworten unbekannte Pfade manchmal mit ihrer HTML-Hülle; prüfen Sie die Antwort deshalb mit curl.
• Markdown-Kopien sind optional. Wenn Sie keine veröffentlichen, verlinken Sie die normalen HTML-Seiten, wie es der Abschnitt Produkt oben tut.
• Die Zusammenfassung sachlich halten. Nennen Sie, was das Produkt ist, für wen es gedacht ist und welche wichtigen Grenzen es hat. Slogans gehören nicht hinein.
• Notizen schreiben, keine Prompts. Die Aufforderung an ein Modell, Sie zu empfehlen, fügt nichts hinzu, was ein Leser prüfen könnte.
• Auswählen. Zehn gute Links sind besser als zweihundert; die vollständige URL-Liste gehört in die Sitemap.

Mit Markdown-Kopien kann jede HTML-Seite auf ihre Kopie und auf die Datei verweisen, die sie abdeckt:

<link rel="alternate" type="text/markdown" href="/docs/erste-schritte.md">
<link rel="describedby" href="/llms.txt">

Generatoren, Checker und Validatoren: die Datei aktuell halten

Eine Datei, die einen alten Preis oder eine gelöschte Seite nennt, kann schlechter sein als gar keine, weil ein Agent, der ihr folgt, veraltete Fakten wiedergeben kann.

• Mit der Dokumentation bauen. Wird die Dokumentation aus Markdown erzeugt, erstellen Sie llms.txt und die Seitenkopien im selben Build-Schritt.
• In die Release-Checkliste aufnehmen. Ändern sich Preise, Tarifnamen, Plattformen oder URLs, aktualisieren Sie die Datei im selben Release.
• Links automatisch prüfen. Jede URL sollte ohne Weiterleitungskette mit 200 antworten. Dieser Shell-Einzeiler gibt den Statuscode jedes absoluten Links in der Datei aus:

curl -s https://example.com/llms.txt | grep -oE 'https://[^) ]+' | while read -r u; do echo "$(curl -s -o /dev/null -w '%{http_code}' "$u") $u"; done

Ein llms.txt-Generator taugt für einen ersten Entwurf aus einer Sitemap oder einem Dokumentationsordner. Welche Seiten wichtig sind, kann er nicht entscheiden, und er nimmt womöglich Seiten auf, die auf noindex stehen oder in der robots.txt gesperrt sind. Prüfen Sie das Ergebnis wie jede Seite, die Sie veröffentlichen.

Ein llms.txt-Checker oder -Validator kann die mechanischen Teile bestätigen: Die Datei ist erreichbar, die H1 steht am Anfang, und die Links funktionieren. Ob ein Assistent die Datei liest, kann kein Checker sagen, weil die Anbieter das nicht dokumentieren.

Was für KI-Antworten wichtiger ist

Wenn Sie eine brauchbare Quelle für KI-Antworten sein wollen, kommt zuerst Folgendes:

1. Crawler-Zugang für die Bots, die Sie zulassen wollen. KI-Crawler werden in der robots.txt gesteuert, jeder unter seinem eigenen Token. OpenAI trennt OAI-SearchBot (ChatGPT-Suche) von GPTBot (Training), Anthropic trennt Claude-SearchBot von ClaudeBot, und Perplexity dokumentiert PerplexityBot. Das Token Google-Extended ist eine robots.txt-Steuerung, kein eigener Crawler: Es regelt, ob Inhalte, die Google crawlt, für Training und Grounding von Gemini genutzt werden dürfen, und beeinflusst laut Google weder die Aufnahme noch das Ranking in der Google-Suche. Suchcrawler zuzulassen und Trainingscrawler zu sperren, ist eine legitime Entscheidung. Denken Sie daran, dass eine Gruppe User-agent: * mit Disallow: / jeden Crawler sperrt, der robots.txt befolgt und keine eigene Gruppe hat. Laut OpenAI kann es etwa 24 Stunden dauern, bis eine Änderung an der robots.txt in seinen Systemen ankommt.
2. Authentifizierung für private Inhalte. Von Nutzern ausgelöste Abrufer wie ChatGPT-User und Perplexity-User befolgen robots.txt womöglich nicht, und laut RFC 9309 sind robots-Regeln keine Zugriffsautorisierung.
3. Klare Inhalte auf der Seite. Googles Hinweise zu seinen KI-Funktionen verweisen auf einzigartige, nützliche Inhalte und eine klare technische Struktur, die Auffindbarkeit und Indexierung ermöglicht, nicht auf spezielle Dateien. Beantworten Sie echte Fragen direkt im HTML einer erreichbaren Seite. Der Leitfaden zur KI-Sichtbarkeit zeigt das an einem Beispiel.
4. Strukturierte Daten, die zur Seite passen. Google sagt, dass strukturierte Daten für seine generative KI-Suche nicht erforderlich sind und kein spezielles schema.org-Markup nötig ist; für die Eignung für Rich Results in der Suche empfiehlt Google strukturierte Daten weiterhin. Wenn Sie JSON-LD verwenden, halten Sie es mit den sichtbaren Fakten im Einklang.
5. Einheitliche Fakten. Name, Preise, Tarife, Regionen und Kontaktdaten, etwa im Impressum, sollten auf Ihren Seiten, in Ihren strukturierten Daten und in Ihrer llms.txt übereinstimmen. Widersprechen sich Ihre eigenen Seiten, muss jedes System, das sie zusammenfasst, raten.

Keine Datei kann einen Assistenten dazu bringen, Sie zu zitieren. In Ihrer Hand liegt, ob Ihre Seiten erreichbar, lesbar und korrekt sind; der Leitfaden zu technischem SEO behandelt die Grundlagen von Crawling und Indexierung.

Was Sitelemetry an llms.txt prüft

Der Bereich KI-Sichtbarkeit von Sitelemetry gehört zum Audit mit sechs Bereichen (Sicherheit, technisches SEO, KI-Sichtbarkeit, Barrierefreiheit, Performance und Integrationen), das es ab dem Starter-Plan für 49 US-Dollar im Monat gibt. Seine llms.txt-Prüfung ist eng gefasst:

• Sie ruft /llms.txt einmal am Origin ab und meldet Status und Größe.
• Die Datei gilt nur als vorhanden, wenn sie mit einem 2xx-Status antwortet, nicht leer ist, kein HTML ist und wie ein Linkverzeichnis aussieht: eine Zeile, die mit # oder - beginnt, eine URL oder Wörter wie docs oder sitemap. Eine fehlende Datei erscheint als Teilergebnis mit Empfehlung.
• Sie validiert das Format nicht, folgt den Links nicht, testet sie nicht und behauptet nicht, dass ein KI-System die Datei liest.

Derselbe Bereich prüft die robots.txt auf websiteweite Sperren gegen 16 namentlich genannte KI-Crawler, darunter GPTBot, OAI-SearchBot, ClaudeBot, PerplexityBot und Google-Extended. Regeln unter User-agent: * und teilweise Sperren werden keinem einzelnen KI-Crawler zugeordnet (eine websiteweite Sperre für alle Crawler wird gesondert gemeldet), und die Liste ist fest; Crawler, die nicht darauf stehen, etwa Claude-SearchBot oder Claude-User, prüfen Sie also selbst. Außerdem meldet der Bereich strukturierte Daten in JSON-LD, ohne sie gegen schema.org zu validieren. Das Audit liest statisches HTML einer Auswahl von Seiten, ohne JavaScript auszuführen, fragt weder ChatGPT, Claude, Perplexity noch Google ab und verfolgt keine Quellenangaben in KI-Antworten.

Der Free-Plan umfasst nur Sicherheitsprüfungen. Der kostenlose Snapshot führt ohne Anmeldung acht passive Prüfungen aus; llms.txt, robots.txt und strukturierte Daten betrachtet er nicht, und er ist nicht das Audit mit sechs Bereichen. Details zu den Tarifen stehen auf der Preisseite.