SEO & KI

Die Wahrheit über die Datei llms.txt

Alle großen KI-Anbieter veröffentlichen eine llms.txt auf ihren Dokumentationsseiten. Keiner von ihnen verpflichtet sich, Ihre zu lesen. Ich habe die URLs einzeln getestet, die offiziellen Aussagen und die Logfile-Studien noch einmal durchgearbeitet. Hier das Ergebnis — Fakten, Aussagen und Hypothesen strikt getrennt.

Fred Gaveau4. August 2026~11 Min. Lesezeit

Am Anfang steht eine Merkwürdigkeit. Seit zwei Jahren gilt llms.txt als die Datei, die mit künstlicher Intelligenz spricht. Und tatsächlich veröffentlichen sie alle eine: Anthropic, OpenAI, Mistral, Perplexity, xAI, Google teilweise. Wenn irgendjemand weiß, wozu diese Datei gut ist, dann sie.

Nur hat keiner von ihnen je geschrieben, dass seine eigenen Bots sie auf Ihrer Seite lesen. Und das einzige Unternehmen, das sich klar geäußert hat — Google — hat Nein gesagt.

Genau da setzt diese Recherche an. Ich habe jede URL von Hand getestet, die offiziellen Aussagen gesucht, wo es sie gibt, und die veröffentlichten Logfile-Studien gelesen. Der Text ist bewusst dreigeteilt: was belegt ist, was behauptet wird, und was Spekulation bleibt — meine eingeschlossen.

Was ich selbst überprüft habe

Ich habe siebzehn URLs am 4. August 2026 um 13:24 UTC über die Kommandozeile abgefragt, Weiterleitungen verfolgt und HTTP-Status sowie Größe des zurückgegebenen Rumpfes notiert. Alle Links in der Tabelle sind aktiv: prüfen Sie selbst nach, darum geht es ja gerade.

Momentaufnahme vom 4. August 2026, 13:24 UTC. Eine Datei kann morgen auftauchen oder verschwinden — genau das ist Google passiert.

Drei Dinge springen aus dieser Tabelle heraus.

Erstens: Die Datei lebt auf Dokumentations-Subdomains, nie auf der Publikumsseite. docs., developers., platform. antworten mit 200. Die Wurzeln anthropic.com und google.com antworten mit 404. Eine Ausnahme im Feld: Vercel, dessen /docs/llms.txt auf vercel.com/llms.txt umleitet und tatsächlich im Wurzelverzeichnis liegt, wie es die Spezifikation verlangt.

Zweitens: Google ist fragmentiert. Firebase hat eine, Google Cloud nicht, die Seite der Gemini-Modelle auch nicht. Das ist keine Politik, das ist ein Unfall — dazu gleich mehr.

Drittens: Das Format ist explodiert. Die Spezifikation beschreibt einen kurzen Index. Firebase liefert 1,7 MB aus, xAI 1,3 MB, die Vollvariante von Vercel 7,4 MB. Ein Index von 1,7 MB ist kein Index mehr: er ist der Korpus, den er zusammenfassen sollte.

Woher die Datei kommt

FAKT llms.txt ist ein Vorschlag, veröffentlicht am 3. September 2024 von Jeremy Howard (Answer.AI, Mitgründer von fast.ai) auf llmstxt.org. Die Idee: eine strukturierte Markdown-Datei im Wurzelverzeichnis — eine #-Überschrift, eine Zusammenfassung als Zitat, ##-Abschnitte mit kommentierten Links — die Modellen eine saubere Inhaltskarte bietet, statt sie die Struktur einer JavaScript-überladenen Website erraten zu lassen.

Die Analogie zu robots.txt und sitemap.xml ist gewollt, und sie hat die Idee verkauft. In einem entscheidenden Punkt führt sie aber in die Irre: robots.txt und sitemap.xml wurden von den Suchmaschinen übernommen, bevor sie populär wurden. Hier ist es umgekehrt.

FAKT Die Spezifikationsseite behauptet keinerlei Zustimmung eines KI-Anbieters, nennt kein Standardisierungsverfahren (weder IETF noch W3C noch WHATWG) und bezeichnet sich selbst als offen für Beiträge der Community über ein GitHub-Repository. Ein selten beachtetes Detail: llms-full.txt kommt in der Spezifikation überhaupt nicht vor. Es ist eine aus der Praxis entstandene Konvention, die jeder anders umsetzt.

Der Kern: Liest diese Datei überhaupt jemand?

Das ist die einzige Frage, die zählt, und es gibt Zahlen dazu.

Was die Server-Logs sagen

FAKT Am 5. März 2026 veröffentlichte Dries Buytaert — Drupal-Erfinder und CTO von Acquia — die Auswertung eines Monats Cloudflare-Logs. Seine Seite erhielt 52 Anfragen auf /llms.txt in einem Monat. Jede einzelne kam von einem SEO-Audit-Werkzeug. Keine einzige kam von einer Antwortmaschine oder einem KI-Crawler. Über die gesamte Hosting-Infrastruktur von Acquia hinweg: rund 5 000 Anfragen von 400 Millionen, also 0,001 %, fast ausschließlich von SEO-Werkzeugen.

FAKT Eine Logfile-Analyse von Ahrefs über 137 000 Domains (Juni 2026, berichtet von PPC Land) kommt zu dem Ergebnis, dass 97 % der llms.txt-Dateien im Mai 2026 keine einzige Anfrage erhielten. KI-Abrufbots machten 1,1 % der beobachteten Anfragen aus.

FAKT Und eine SE-Ranking-Studie vom 7. November 2025 über 300 000 Domains findet keinen messbaren Effekt von llms.txt auf KI-Zitationen. Die Variable aus dem Vorhersagemodell zu streichen, verbesserte dessen Genauigkeit sogar.

Was Google erklärt

AUSSAGE Google ist der einzige große Akteur, der sich förmlich geäußert hat. Die offizielle Dokumentation zu den KI-Funktionen der Suche (developers.google.com, aktualisiert am 10. Dezember 2025) schreibt es unmissverständlich:

AUSSAGE Auf Reddit verglich John Mueller llms.txt mit dem meta keywords-Tag — aufgegeben genau deshalb, weil die Seite es selbst ausfüllt — und später, berichtet im Juni 2026: „I don't think anyone knows – it's purely speculative for now (the file has existed for years, yet none of the AI systems use it — what does it mean?)“. Er fügt eine Entscheidungsregel hinzu, die ich für ehrlich halte: An dem Tag, an dem eine KI-Plattform, die Ihnen Kunden bringt, die Datei verlangt, bauen Sie sie. Bis dahin nicht.

AUSSAGE Gary Illyes aus dem Search-Team erklärte bei einem Search Central Live im Juli 2025, Google unterstütze llms.txt nicht und plane das auch nicht — eine von Search Engine Roundtable wiedergegebene Position.

Was die anderen nicht sagen

UNGEPRÜFT Für OpenAI, Anthropic, Perplexity und Mistral habe ich keine öffentliche Aussage gefunden, wonach ihre Bots die llms.txt einer fremden Seite auswerten — und auch keine, die es ausschließt. Schweigen ist kein Beweis für Abwesenheit, aber auch keine Zusage. Eine Datei auf der eigenen Dokumentation zu veröffentlichen, sagt nichts darüber aus, was der eigene Crawler bei Ihnen tut: zwei Teams, zwei Produkte, zwei Probleme.

Der dokumentierte Widerspruch bei Google

Das ist die aufschlussreichste Episode, und sie ist überprüfbar.

BERICHTET Am 3. Dezember 2025 erschien eine llms.txt auf developers.google.com/search/docs/. Entdeckt wurde sie von der SEO-Beraterin Lidia Infante. Sie wurde noch am selben Tag entfernt. Den Berichten zufolge war die Datei keine Entscheidung des Search-Teams: Googles internes Content-Management-System, das mehrere Entwickler-Properties bedient, hatte begonnen, sie automatisch zu erzeugen. Manche Teams entfernten sie, andere nicht.

FAKT — geprüft am 4. August 2026 Der heutige Befund bestätigt diese Lesart. developers.google.com/search/docs/llms.txt, developer.chrome.com/llms.txt, web.dev/llms.txt, cloud.google.com/llms.txt, ai.google.dev/llms.txt: überall 404. Und firebase.google.com/docs/llms.txt: 200, 1,7 MB. Ein Team hat das Aufräumen vergessen. Die „Google-llms.txt“, die überall als Beweis für Akzeptanz zitiert wird, ist der Rückstand eines automatischen Deployments.

FAKT Und doch zieht zur selben Zeit ein anderer Teil von Google in die Gegenrichtung. Lighthouse 13.3, das in Chrome eingebaute Analysewerkzeug, bringt eine experimentelle Kategorie „Agentic Browsing“ mit, die einen llms.txt-Test enthält (Dokumentation aktualisiert am 5. Mai 2026). Dort heißt es, sie sei „an emerging convention used to provide a machine-readable summary of a website's content, specifically designed for LLMs and AI agents“, und ohne die Datei bräuchten Agenten mehr Zeit, um die Seite zu erschließen.

MEINE DEUTUNG Das ist keine Heuchelei, und ich werde es nicht so darstellen. Es liegt daran, dass „Google“ keine einheitliche Instanz ist und die beiden Teams nicht vom selben Anwendungsfall sprechen: Search spricht von Ranking und Zitation in einer Antwortmaschine, Chrome von der Effizienz eines navigierenden Agenten. Beide Positionen sind für sich vertretbar. Für den Leser, der wissen will, ob „Google“ die Datei empfiehlt, sind sie schlicht unvereinbar. Und diese Verwirrung räumt niemand aus. Search Engine Journal hat es treffend formuliert: Googles Empfehlung hängt davon ab, welches Produkt Sie fragen.

Warum veröffentlicht sie dann jeder?

Hier die Hypothese, die ich vertrete — und die Dateien selbst stützen sie: llms.txt war nie eine SEO-Datei. Sie ist eine Entwicklerdokumentations-Datei. Der angesprochene Leser ist nicht GPTBot, der das Web für eine Antwortmaschine indexiert. Es ist eine Entwicklerin mit offenem Cursor, Claude Code oder Copilot, deren Agent aktuelle API-Doku laden muss, statt eine im Training gelernte veraltete Version aufzusagen.

FAKT Die Dateien sagen es selbst. Die von Cohere enthält einen Abschnitt „Instructions for AI Agents“, der empfiehlt, an jede URL .md anzuhängen, um sauberes Markdown zu erhalten, und einen MCP-Server anzubinden „for AI client integration (Claude Code, Cursor, etc.)“. Die von Cloudflare erklärt, jedes Produkt habe seine eigene llms.txt, „the recommended way to explore a specific product's content“. Diese Sätze richten sich nicht an eine Suchmaschine.

FAKT Buytaerts Logs weisen in dieselbe Richtung: In IDEs eingebettete Agenten rufen diese Ressourcen sehr wohl ab, anders als die Crawler der Antwortmaschinen.

Stimmt diese Lesart, dann beruht die gesamte Debatte „verbessert llms.txt meine KI-Sichtbarkeit?“ auf einer Verwechslung der Rolle. Ein Werkzeug der technischen Dokumentation wird an SEO-Maßstäben gemessen. Es scheitert, natürlich. Das heißt nicht, dass es nutzlos ist — es heißt, dass es nicht dafür da ist.

Was wirklich funktioniert und niemand verkauft: Markdown

FAKT Das ist der nützlichste Datenpunkt der ganzen Recherche, und er ist fast untergegangen. Wieder aus Buytaerts Logs, wenn eine Seite unter einer vorhersagbaren URL als Markdown verfügbar ist:

Mit anderen Worten: OpenAIs Crawler holen sich Markdown, wenn es unter einer erratbaren URL existiert — typischerweise /meine-seite.md. Ein Drittel der Abrufe bei GPTBot. Das ist unendlich viel mehr als die 0,001 % der llms.txt.

FAKT Und die Folgerung ist brutal: „No AI crawler uses content negotiation. Not one.“ Kein KI-Bot nutzt den Accept-Header, um Markdown anzufordern. Content Negotiation — die saubere, seit dreißig Jahren standardisierte Methode — wird von allen ignoriert. Was funktioniert, ist das URL-Suffix, die dümmste verfügbare Lösung.

Genau dieses Muster nutzen Stripe, Cohere, Perplexity und Anthropic in ihren Dateien: Jeder Eintrag zeigt auf einen .md-Zwilling. Die llms.txt ist das Verzeichnis; konsumiert werden die Markdown-Zwillinge.

Der Fall Stripe: wenn aus dem Index ein Befehl wird

FAKT Stripes llms.txt beginnt nicht mit einer Beschreibung. Sie beginnt mit Befehlen an die Maschine, die sie liest. Geprüfter Auszug, erste Zeilen der Datei:

# Stripe Documentation

When installing Stripe packages, always check the npm registry for the latest
version rather than relying on memorized version numbers. Run `npm view stripe
version` [...] Never hardcode an old version number from training data — always
install with `@latest` or verify the current version first.

HYPOTHESE Diese Zweckentfremdung wirft eine Sicherheitsfrage auf, die ich stellen, aber nicht entscheiden kann: Wenn eine öffentliche, unsignierte Datei Anweisungen enthalten kann und ein Agent sie in seinen Kontext lädt, ohne „Beschreibung der Website“ von „auszuführendem Befehl“ zu unterscheiden, sind wir im Bereich der Prompt Injection. Ich habe keinen öffentlich dokumentierten Vorfall gefunden, bei dem eine llms.txt ausgenutzt wurde. Das Risiko ist strukturell, nicht beobachtet. Aber das Format bietet derzeit keine Möglichkeit, beides zu trennen — und Stripe hat, in bester Absicht, gerade gezeigt, dass die Tür offen steht.

Acht Vorschläge, das Format zu reparieren

Kritisieren ist billig. Hier ist, was llms.txt aus meiner Sicht vom Glaubensartikel zum brauchbaren Werkzeug machen würde. Jeder Vorschlag stützt sich auf einen Mechanismus, den es anderswo bereits gibt.

1. Nicht mehr von Hand schreiben. Generieren.

Eine handgeschriebene llms.txt verrottet in drei Monaten: Die Seiten wandern, die Datei nicht. Sie gehört beim Build erzeugt, aus derselben Quelle wie die Sitemap oder das CMS. Die Ironie: Genau das tat Googles internes System — und der Unfall vom Dezember 2025 entstand, weil die Erzeugung automatisch war, die Entscheidung aber nicht. Automatisieren Sie die Erzeugung, nicht die Entscheidung.

2. Markdown-Zwillinge vor dem Index ausliefern.

Das ist der ertragreichste Vorschlag, und er dreht die übliche Priorisierung um. Da OpenAIs Crawler etwa ein Drittel ihrer Anfragen als Markdown stellen, Content Negotiation aber ignorieren: Liefern Sie /meine-seite.md neben /meine-seite unter vorhersagbarer URL aus und deklarieren Sie es im HTML mit <link rel="alternate" type="text/markdown" href="/meine-seite.md">. Das funktioniert heute, messbar, anders als llms.txt. Wenn Sie aus diesem Artikel nur eine Sache mitnehmen, dann diese.

3. Umzug nach /.well-known/.

RFC 8615 definiert seit 2019 einen Standard-Namensraum für genau solche Dateien, mit einem IANA-Register dahinter. /.well-known/llms.txt würde die Platzierungsfrage auf einen Schlag klären — eben jene Frage, die erklärt, warum alle Dateien der Tabelle auf Doku-Subdomains statt im Wurzelverzeichnis liegen — und den einzigen glaubwürdigen Weg zur Standardisierung eröffnen.

4. In robots.txt deklarieren.

Eine Zeile, Llms: https://beispiel.de/llms.txt, exakt nach dem Vorbild der Sitemap:-Direktive — die ebenfalls nie standardisiert wurde und die dennoch jede Suchmaschine beachtet. Null Kosten, garantierte Auffindbarkeit, und ein Mechanismus, dessen Akzeptanz zwanzig Jahre Praxis belegen.

5. Jeden Eintrag datieren.

Ein Index ohne Aktualitätsangabe ist unbrauchbar: Gegenüber einer live gerenderten Seite hat ein Modell keinen Grund, eine Indexzeile zu bevorzugen, die zwei Jahre alt sein kann. Ein Datum je Eintrag — - [Seite](url) (2026-07-12): Beschreibung — plus ein ehrliches Last-Modified auf der Datei selbst geben endlich etwas an die Hand, um abzuwägen.

6. Index und Korpus formal trennen.

Das Format braucht eine harte Obergrenze — sagen wir 50 KB — für llms.txt und muss alles Weitere in eine llms-full.txt auslagern, die in der Spezifikation ausdrücklich definiert ist (das ist sie bis heute nicht). Firebases 1,7 MB und xAIs 1,3 MB sind kein Missbrauch: Sie sind Symptome eines Formats, das nie gesagt hat, wo Schluss ist.

7. Signieren — oder eingestehen, dass es wertlos ist.

John Muellers Einwand — „die Seite füllt es selbst aus, wie meta keywords“ — ist unwiderlegbar, solange es keine Signatur gibt. Die Werkzeuge sind da: HTTP Message Signatures (RFC 9421), ein Schlüssel im DNS-TXT-Eintrag. Eine selbst deklarierte, unsignierte Datei wird immer genau die Beweiskraft eines meta keywords von 2003 haben.

8. Den Imperativ verbieten — oder einzäunen.

Solange kein Mechanismus Beschreibung von Anweisung trennt, sollte das Format Befehle entweder untersagen oder einen klar abgegrenzten Abschnitt ## Agent instructions vorschreiben, den Agenten als nicht vertrauenswürdige Daten behandeln. Der Fall Stripe ist kein Einzelfall: Er ist das erste Symptom.

Und zum Schluss: messen Sie es.

Keiner dieser Vorschläge erspart Ihnen den einfachsten Schritt. Ein Zugriff auf /llms.txt ist eine Zeile in Ihren Server-Logs. Filtern Sie nach den User-Agents der KI-Bots, vergleichen Sie mit Ihren HTML-Seiten, und Sie wissen binnen einer Woche, ob die Datei bei Ihnen etwas bringt. Das ist die einzige Zahl, die Sie wirklich betrifft. Alle anderen, meine eingeschlossen, sind der Durchschnitt von jemand anderem.

Fazit: Sollte man 2026 eine anlegen?

Es gibt nicht eine Antwort. Es gibt vier.

Und eine Regel, die für alle gilt: Bezahlen Sie niemanden dafür, Ihre llms.txt zu schreiben. Das sind zwanzig Minuten Arbeit, oder null, wenn Sie sie generieren. Budget verdient allein die anschließende Prüfung, ob die Bots wirklich vorbeikommen — und das sagen Ihre Logs, nicht ein Dienstleister.

Im Übrigen hat sich meine Position seit unserem ersten Artikel zum Thema nicht verschoben: Die Datei schadet nicht, kostet fast nichts, und falls die Nutzung eines Tages anzieht, sind Sie vorbereitet. Verändert haben sich die Daten. Wir wissen jetzt mit Zahlen, dass sie kein Hebel für KI-Sichtbarkeit ist — und wir beginnen zu verstehen, was sie wirklich ist: ein Werkzeug für Code-Agenten, schlecht benannt und in der falschen Rolle besetzt.

Transparenzhinweis: Snorklee veröffentlicht eine eigene llms.txt, im Wurzelverzeichnis, mit einem Vorbehalt darin. Wir tun also genau das, was wir empfehlen: anlegen, nicht daran glauben, und messen.