llms.txt erklärt: Was die Datei bringt und was nicht, gemessen in 27 Tagen Server-Logs (2026)

llms.txt ist eine Textdatei im Markdown-Format, die du unter deine-domain.de/llms.txt ablegst. Sie soll Sprachmodellen und KI-Agenten in kompakter Form erklären, worum es auf deiner Website geht, und auf die wichtigsten Inhalte verlinken. Die Idee stammt vom australischen Data Scientist Jeremy Howard (Answer.AI) und wurde im September 2024 vorgeschlagen. Seit August 2026 gibt es eine überarbeitete Version 2 der Spezifikation.

Um kaum eine Datei wird gerade so viel Wirbel gemacht. SEO-Tools prüfen auf sie, Plugins erzeugen sie per Knopfdruck, Agenturen verkaufen sie als Pflicht für die „KI-Sichtbarkeit“. Wir wollten wissen, was wirklich dran ist, und haben nicht nachgelesen, sondern gemessen. Wir haben 27 Tage Server-Logs von getmind.io ausgewertet (25. September bis 22. Oktober 2026, 218.657 Anfragen), 73 bekannte Domains auf eine llms.txt geprüft und den Lighthouse-Audit mit sechs präparierten Testservern nachgestellt.

Drei Ergebnisse vorweg:

1. Kein einziger der großen KI-Crawler hat in 27 Tagen /llms.txt abgerufen. Weder GPTBot noch ClaudeBot, PerplexityBot, Googlebot oder bingbot. Dieselben Bots haben unsere robots.txt in der Zeit hunderte Male geholt.
2. Lighthouse bestraft dich nicht, wenn du keine llms.txt hast. Eine fehlende Datei (404) gilt als „nicht anwendbar“. Rot wird der Audit erst, wenn du eine kaputte Datei auslieferst. Viele Artikel, unser eigener eingeschlossen, haben das bisher falsch dargestellt.
3. Ein anderer Weg ist bei uns tatsächlich angekommen: 2.386 Anfragen von KI-Suchdiensten wollten unsere Seiten direkt als Markdown haben, über den HTTP-Header Accept: text/markdown. Das ist ein Signal, das du ernst nehmen solltest.

In diesem Artikel erfährst du, wie eine llms.txt aufgebaut ist, wer sie wirklich liest, was Google dazu sagt, wie du eine erstellst, wenn du sie trotzdem willst, und für welche Websites sich der Aufwand lohnt.

Das kurze Erklärvideo von OMN stammt von Juni 2025 und ist damit älter als unsere übliche Grenze von sechs Monaten. Ein aktuelleres deutschsprachiges Video haben wir nicht gefunden. Die Grundidee stimmt weiterhin. Die Version 2 der Spezifikation (August 2026) und die Lighthouse-Prüfung kommen darin noch nicht vor, beides erklären wir unten.

Was ist llms.txt? Die Kurzfassung

Websites sind für Menschen gebaut. Eine typische Artikelseite besteht aus Navigation, Cookie-Banner, Seitenleiste, Skripten, Tracking und Fußzeile, und irgendwo dazwischen steht der eigentliche Text. Wir haben das an drei unserer eigenen Artikel nachgezählt. Bei unserem Artikel Was ist IndexNow? liefert der Server 82.104 Byte HTML aus. Davon sind 27.679 Byte reiner Lesetext, also rund ein Drittel. Bei der Sitemap-Anleitung ist das Verhältnis ähnlich: 104.327 Byte HTML, 33.092 Byte Text.

Ein Mensch blendet den Rest einfach aus. Ein Sprachmodell muss ihn erst herausfiltern, und jedes überflüssige Zeichen kostet Kontextfenster, Zeit und Geld. Die Idee hinter llms.txt ist deshalb simpel:

• Eine Datei an einer festen Adresse (/llms.txt), die ein Agent ohne Raten findet, ähnlich wie die robots.txt.
• Ein kurzer Überblick in Markdown: Was ist das für eine Website, was steht wo, was ist wichtig.
• Links auf saubere Fassungen der Inhalte, idealerweise ebenfalls als Markdown-Dateien, damit der Agent nicht durch HTML wühlen muss.

Wichtig ist, was llms.txt nicht ist. Es ist keine Zugriffsregel. Ob ein Crawler deine Seiten lesen darf, steuerst du weiterhin in der robots.txt. Es ist auch keine Sitemap. Die XML-Sitemap listet maschinenlesbar alle URLs für Suchmaschinen auf, die llms.txt ist eine kuratierte, kommentierte Auswahl für Sprachmodelle. Und es ist kein Ranking-Faktor. Keine Suchmaschine hat je bestätigt, dass die Datei die Sichtbarkeit verbessert.

Wie ist eine llms.txt aufgebaut?

Die Spezifikation auf llmstxt.org ist kurz. Eine gültige llms.txt besteht aus Markdown-Abschnitten in einer festen Reihenfolge:

1. Eine H1-Überschrift mit dem Namen der Website oder des Projekts. Das ist der einzige Pflichtteil.
2. Ein Blockzitat (>) mit einer kurzen Zusammenfassung.
3. Beliebig viele Absätze oder Listen ohne Überschriften mit weiteren Hinweisen.
4. Beliebig viele H2-Abschnitte, die jeweils eine Liste von Links enthalten. Jeder Eintrag hat die Form [Name](URL), optional gefolgt von einem Doppelpunkt und einer Beschreibung.

So sieht ein minimales Beispiel aus:

# Beispiel GmbH

> Die Beispiel GmbH verkauft Ersatzteile für Kaffeemaschinen
> und liefert innerhalb Deutschlands in 1 bis 2 Werktagen.

Preise sind Bruttopreise inklusive 19 % MwSt. Rücksendungen sind
30 Tage kostenlos möglich.

## Produkte

- [Dichtungen](https://beispiel.de/dichtungen.md): Brühgruppen-Dichtungen für alle gängigen Marken
- [Entkalker](https://beispiel.de/entkalker.md): Flüssig und in Tablettenform

## Service

- [Versand und Lieferzeiten](https://beispiel.de/versand.md)
- [Rückgabe](https://beispiel.de/rueckgabe.md)

## Optional

- [Firmengeschichte](https://beispiel.de/ueber-uns.md)

Der Abschnitt ## Optional ist eine Konvention für Nebensächliches, das ein Agent bei knappem Kontext überspringen darf. In Version 1 hatte er eine feste technische Bedeutung für Werkzeuge, die eine llms.txt automatisch zu einem großen Kontextblock aufblasen. In Version 2 ist diese Sonderbedeutung entfallen. Der Abschnitt ist weiterhin erlaubt, aber nur noch ein Hinweis.

Was Version 2 (August 2026) geändert hat

Die meisten Anleitungen im Netz beschreiben noch Version 1. Die Überarbeitung vom August 2026 bringt drei Änderungen, die für die Praxis relevant sind:

• Unterpfade sind offiziell geregelt. Eine llms.txt muss nicht im Root liegen. Eine Datei unter /docs/llms.txt gilt für alle Seiten unter /docs/. Gibt es mehrere, nimmt der Agent die spezifischste. Google macht genau das: ai.google.dev/llms.txt liefert 404, aber ai.google.dev/gemini-api/docs/llms.txt existiert (37.731 Byte, gemessen am 22.10.2026).
• Markdown-Fassungen dürfen zwei URL-Formen haben. Entweder .md an die volle URL anhängen (seite.html.md) oder die Endung ersetzen (seite.md).
• Es gibt einen offiziellen Weg zum Auffinden. Seiten können per <link rel="alternate" type="text/markdown"> auf ihre Markdown-Fassung verweisen und per <link rel="describedby"> auf die zuständige llms.txt. Das geht auch als HTTP-Header Link:, ganz ohne die Seiten selbst anzufassen.

Außerdem beschreibt Version 2 erstmals, wie die Datei gelesen werden soll: Der Agent schaut in die llms.txt, sucht sich das Passende heraus und folgt nur den relevanten Links. Die Datei soll klein bleiben, die Details liegen hinter den Links.

Und was ist llms-full.txt?

llms-full.txt ist eine Konvention, die vor allem Dokumentations-Plattformen wie Mintlify eingeführt haben. Darin steht nicht nur eine Linkliste, sondern der komplette Inhalt aller Seiten in einer einzigen Datei. Teil der offiziellen Spezifikation ist sie nicht.

Wie groß das werden kann, hat uns selbst überrascht. Am 22.10.2026 gemessen:

69 Megabyte Text entsprechen grob 17 Millionen Tokens. Kein Sprachmodell kann das in einem Rutsch lesen. Eine solche Datei ist bestenfalls ein Download zum lokalen Durchsuchen, aber kein Kontextfutter. Genau deshalb betont Version 2, dass die Datei klein bleiben und auf Details verlinken soll.

Wir haben dasselbe für getmind.io durchgerechnet. Eine llms.txt mit allen 93 deutschen Artikeln (Titel, Link, Beschreibung) wäre 33.650 Byte groß, rund 8.300 Tokens. Das passt problemlos in jedes Kontextfenster. Eine llms-full.txt mit dem kompletten Text aller Artikel käme auf 2,86 MB oder rund 700.000 Tokens und würde damit bei fast jedem Modell schon an der Größe scheitern.

Wer liest llms.txt wirklich? Unsere Log-Auswertung

Das ist die entscheidende Frage, und sie lässt sich nicht mit Meinungen beantworten, sondern nur mit Logdateien. getmind.io hat keine llms.txt. Wer sie abruft, bekommt ein 404. Gerade das macht die Messung sauber: Jeder Abruf im Log ist ein Besucher, der von sich aus nach der Datei gesucht hat.

Wir haben alle Caddy-Zugriffslogs vom 25. September bis 22. Oktober 2026 zusammengeführt: 218.657 Anfragen auf getmind.io. Darin finden sich 78 Abrufe von /llms.txt, dazu 2 auf /.well-known/llms.txt und einer auf /llms-full.txt. Das sind knapp drei pro Tag.

Und jetzt zu den Absendern:

Mehr als zwei Drittel der Abrufe stammen von einem einzigen SEO-Audit-Werkzeug. Der Rest sind andere SEO- und Analyse-Tools sowie Anfragen mit gewöhnlichen Browser-Kennungen, die typischerweise von Scannern oder Menschen stammen, die mal nachschauen. Kein einziger Abruf kam von einem Crawler eines KI-Anbieters oder einer Suchmaschine.

Dass diese Bots einfach selten vorbeikommen, kann man ausschließen. Im selben Zeitraum haben sie unsere Website intensiv besucht und dabei ganz selbstverständlich die robots.txt abgefragt:

Eine ehrliche Einschränkung gehört dazu: Diese Zahlen beruhen auf dem User-Agent, und der lässt sich fälschen. Wir haben das in den Logs gesehen. Die IP-Adresse 34.153.192.236 aus einem Cloud-Rechenzentrum taucht gleichzeitig als „GPTBot“, „ClaudeBot“ und „bingbot“ auf, ist also mit Sicherheit keiner davon. Die absoluten Anfragezahlen sind deshalb zu hoch. Für die Kernaussage spielt das keine Rolle. Hätte ein echter KI-Crawler die llms.txt gesucht, stünde der Abruf im Log, egal unter welchem Namen. Es gibt aber keinen.

Das deckt sich mit dem, was andere Betreiber berichten, und mit den Aussagen der Anbieter. Weder OpenAI noch Anthropic, Perplexity oder Google haben bestätigt, dass ihre Crawler llms.txt auswerten. Wenn wir in unserer Analyse der KI-Crawler etwas gelernt haben, dann das: Crawler holen sich robots.txt und HTML-Seiten. Was in Marketing-Folien über ihre Vorlieben steht, sieht man in den Logs selten wieder.

Wo llms.txt tatsächlich gelesen wird

Damit ist llms.txt aber nicht nutzlos. Die Datei wird gelesen, nur eben nicht von Crawlern, die das Web für Trainingsdaten oder Suchindizes abgrasen. Gelesen wird sie von Agenten, die gerade eine konkrete Aufgabe erledigen, und vor allem dann, wenn ein Mensch sie dorthin schickt:

• Coding-Agenten wie Claude Code, Cursor oder GitHub Copilot, wenn ein Entwickler schreibt: „Lies die Doku unter docs.beispiel.de/llms.txt und bau mir die Anbindung.“
• MCP-Server und Doku-Werkzeuge, die llms.txt-Dateien gezielt einlesen, um einem Modell die Dokumentation einer Bibliothek bereitzustellen.
• Menschen, die die URL in ein Chatfenster kopieren, weil sie wissen, dass die Datei dort sauber aufbereitet liegt.

Das erklärt, warum die Verbreitung so ungleich ist. Bei Entwickler-Dokumentationen ist llms.txt längst Standard, weil genau dort Agenten mit konkreten Aufgaben unterwegs sind. Auf einem Blog, einer Firmenwebsite oder in einem Shop kommt dieser Anwendungsfall selten vor.

Die Verbreitung: Wir haben 73 Domains geprüft

Wir haben am 22.10.2026 per curl geprüft, welche bekannten Websites eine llms.txt ausliefern. Die Auswahl ist bewusst gemischt: Entwickler-Dokus, Hoster, Shopsysteme, SEO-Tools, große deutsche Shops und Nachrichtenseiten. Gezählt haben wir nur Antworten mit Status 200 und einem Text- oder Markdown-Inhaltstyp.

Eine echte llms.txt haben (31 von 73): docs.anthropic.com, developers.openai.com, docs.github.com, github.com, docs.docker.com, docs.stripe.com, stripe.com, cloudflare.com, developers.cloudflare.com, vercel.com, netlify.com, render.com, fly.io, railway.com, supabase.com, nextjs.org, react.dev, vuejs.org, nuxt.com, svelte.dev, nodejs.org, bun.sh, mintlify.com, zapier.com, docs.hetzner.com, wordpress.org, shopify.com, woocommerce.com, yoast.com, semrush.com und otto.de.

Keine llms.txt (404 oder gesperrt): unter anderem anthropic.com, openai.com (403), ai.google.dev (nur im Unterpfad), huggingface.co, kubernetes.io, docs.python.org, laravel.com, symfony.com, tailwindcss.com, astro.build, nginx.org, caddyserver.com, hetzner.com, digitalocean.com, ionos.de, strato.de, all-inkl.com, shopware.com, ahrefs.com, moz.com, sistrix.de, heise.de, golem.de, t3n.de, chip.de, spiegel.de, zeit.de, faz.net, tagesschau.de, bild.de, wikipedia.org, ebay.de, amazon.de und zalando.de.

Das Muster ist eindeutig. Fast alle Treffer sind Entwickler-Dokumentationen und Plattformen, deren Kunden Entwickler sind. Unter den deutschen Nachrichtenseiten hat keine einzige eine llms.txt. Unter den großen deutschen Shops hat nur otto.de eine. Interessant ist auch der Unterschied bei Anthropic: Die Dokumentation unter docs.anthropic.com hat eine, die Unternehmensseite anthropic.com nicht. Das ist genau die Linie, die auch Google zieht: sinnvoll für Dokumentation, für die meisten anderen Websites nicht.

Zwei Auffälligkeiten aus der Stichprobe sind lehrreich:

• WooCommerce liefert eine von Yoast SEO automatisch erzeugte Datei aus. Die erste Zeile ist aber keine H1, sondern der Hinweis „Generated by Yoast SEO v26.0, this is an llms.txt file…“. Die Überschrift folgt erst danach. Formal verstößt das gegen die Reihenfolge der Spezifikation. Lighthouse findet die H1 trotzdem, weil es die ganze Datei durchsucht.
• deno.com, netcup.de und sueddeutsche.de antworten auf /llms.txt mit Status 200, liefern aber eine komplette HTML-Seite aus, bei sueddeutsche.de über 2 MB. Das ist ein sogenannter Soft-404. Für Menschen ist das harmlos, für Lighthouse ist es ein Fehler. Warum, zeigen wir im nächsten Abschnitt.

Was sagt Google zu llms.txt?

Bei Google gibt es zwei Aussagen, und sie widersprechen sich nur auf den ersten Blick.

Google Search ist eindeutig. Im Leitfaden „Optimizing your website for generative AI features on Google Search“ vom 15. Mai 2026 steht sinngemäß, dass man keine neuen maschinenlesbaren Dateien, KI-Textdateien, besonderes Markup oder Markdown anlegen muss, um in der Google-Suche einschließlich AI Overviews und AI Mode zu erscheinen, weil Google Search sie nicht nutzt. John Mueller hat llms.txt schon vorher mit dem Keywords-Meta-Tag verglichen, also mit einer Angabe, die Website-Betreiber über sich selbst machen und die eine Suchmaschine deshalb nicht ungeprüft übernehmen kann. Als Lily Ray ihn kurz darauf fragte, warum Google auf eigenen Seiten trotzdem llms.txt-Dateien anbietet, betonte er, dass das eine nichts mit dem anderen zu tun hat: Entwickler-Dokumentationen haben andere Leser als die Google-Suche.

Chrome Lighthouse prüft seit Version 13.3.0 (7. Mai 2026) in der neuen Kategorie „Agentic Browsing“ standardmäßig, ob eine llms.txt den Empfehlungen folgt. Das ist der Teil, der überall als Widerspruch zitiert wird. Wir haben uns den Code angesehen und das Verhalten selbst getestet.

Wir haben den Lighthouse-Audit nachgebaut

Im Quellcode von Lighthouse 13.4.1 (core/audits/agentic/llms-txt.js) ist die Logik überschaubar. Lighthouse ruft /llms.txt ab und prüft dann drei Dinge: Gibt es eine Zeile, die mit # beginnt (H1)? Gibt es mindestens einen Markdown-Link [...](...)? Ist die Datei mindestens 50 Zeichen lang? Spannender ist, was vorher mit dem Statuscode passiert.

Wir haben einen kleinen Python-Testserver geschrieben, der auf /llms.txt sechs verschiedene Antworten liefert, und Lighthouse 13.4.1 gegen jede Variante laufen lassen:

Daraus folgt etwas, das in vielen Artikeln falsch steht, auch in unserem eigenen Artikel zu Google und KI-SEO, den wir nach diesem Test korrigiert haben: Lighthouse markiert Seiten ohne llms.txt nicht als Fehler. Chromes eigene Dokumentation sagt das auch ausdrücklich: Fehlt die Datei, ist der Audit „Not Applicable“, weil sie „derzeit optional“ ist. Wir haben getmind.io selbst durch die Kategorie „Agentic Browsing“ laufen lassen. Ergebnis: volle Punktzahl, der llms.txt-Audit steht auf „nicht anwendbar“.

Rot wird es in zwei Fällen. Entweder dein Server wirft auf /llms.txt einen 5xx-Fehler, was auf falsch konfigurierte Rewrite-Regeln hindeutet. Oder du lieferst eine Datei aus, die nicht den Empfehlungen folgt. Das kann ein lieblos erzeugtes Plugin-Ergebnis sein oder eben ein Soft-404 wie bei netcup.de und sueddeutsche.de. Paradoxerweise steht eine Website ohne jede llms.txt in Lighthouse besser da als eine mit kaputter Datei.

Beruhigend ist auch das Gewicht. In der Kategorie „Agentic Browsing“ zählt llms.txt nur als einer von sechs gleich gewichteten Audits. Auf den Performance-, SEO- oder Barrierefreiheits-Score hat es keinen Einfluss.

Der Weg, der bei uns wirklich ankam: Markdown per Content-Negotiation

Beim Durchsuchen der Logs nach llms sind wir auf etwas gestoßen, das wir nicht gesucht hatten. 2.386 Anfragen im Zeitraum enthielten im Accept-Header den Wert text/markdown. Der Client sagt dem Server damit: „Wenn du diese Seite als Markdown hast, gib mir bitte die. Sonst nehme ich HTML.“

Das ist ein ganz anderes Muster als bei llms.txt. Diese Bots suchen keine zusätzliche Datei, von der sie hoffen, dass sie existiert. Sie fragen bei jeder Seite, die sie ohnehin abrufen, nach einer schlankeren Fassung. Unser Server liefert ihnen derzeit trotzdem HTML, weil wir keine Markdown-Fassungen anbieten. Aber der Bedarf ist messbar da, und er kommt von Diensten, die Inhalte für KI-Antworten aufbereiten.

Version 2 der llms.txt-Spezifikation greift genau diesen Gedanken auf. Statt nur auf eine zentrale Datei zu setzen, empfiehlt sie, jede Seite zusätzlich als .md anzubieten und per Link-Header darauf zu verweisen. Wer an maschinenlesbare Inhalte für KI denkt, sollte deshalb zuerst hier ansetzen. Markdown-Fassungen pro Seite sind langfristig nützlicher als eine einzelne Übersichtsdatei. Was eine Markdown-Datei genau ist und wie sie aufgebaut wird, erklären wir in unserem Artikel Was ist eine .md-Datei?.

llms.txt erstellen: Schritt für Schritt

Wenn du nach all dem eine llms.txt anlegen willst, zum Beispiel weil du eine Dokumentation, eine API oder ein Software-Produkt betreibst, ist das in wenigen Minuten erledigt.

Schritt 1: Inhalte auswählen

Eine llms.txt ist keine Sitemap. Nimm nicht alle URLs auf, sondern die 10 bis 50 Seiten, die ein Agent am ehesten braucht, um Fragen zu deinem Angebot zu beantworten: Einstieg, wichtigste Anleitungen, API-Referenz, Preise, Kontakt, Bedingungen. Alles andere gehört in den Abschnitt ## Optional oder bleibt weg.

Schritt 2: Datei schreiben

Halte dich an die Reihenfolge: H1, Blockzitat, optional Fließtext, dann H2-Abschnitte mit Linklisten. Jede Beschreibung nach dem Doppelpunkt sollte in einem Satz sagen, was der Agent hinter dem Link findet. Das ist der eigentliche Mehrwert gegenüber einer Sitemap.

# Mein Produkt

> Mein Produkt ist eine Open-Source-Bibliothek für XY.
> Aktuelle Version: 3.2. Lizenz: MIT.

## Einstieg

- [Installation](https://docs.beispiel.de/install.md): npm, pnpm und Docker
- [Schnellstart](https://docs.beispiel.de/quickstart.md): Erstes Projekt in 5 Minuten

## Referenz

- [API](https://docs.beispiel.de/api.md): Alle Funktionen mit Parametern und Beispielen
- [Konfiguration](https://docs.beispiel.de/config.md): Alle Optionen der config.json

## Optional

- [Changelog](https://docs.beispiel.de/changelog.md)

Schritt 3: Richtig ausliefern

Lege die Datei als /llms.txt ins Root-Verzeichnis, bei statischen Seitengeneratoren wie Astro oder Next.js also in den Ordner public/. Prüfe danach drei Dinge:

curl -sI https://deine-domain.de/llms.txt | grep -iE "^HTTP|content-type"
# Erwartet: HTTP/2 200 und content-type: text/plain oder text/markdown

curl -s https://deine-domain.de/llms.txt | head -3
# Erwartet: Erste Zeile beginnt mit "# "

curl -s -o /dev/null -w "%{http_code}\n" https://deine-domain.de/llms-txt-gibts-nicht.txt
# Gegenprobe: Muss 404 liefern, sonst hast du einen Soft-404

Die Gegenprobe ist wichtig. Liefert dein Server auf beliebige Pfade Status 200 mit einer HTML-Seite, dann hält jedes Werkzeug auch eine fehlende llms.txt für vorhanden und kaputt. Genau das passiert bei den drei Domains aus unserer Stichprobe.

Schritt 4: Optional mit Lighthouse prüfen

lighthouse https://deine-domain.de/ --only-audits=llms-txt --output=json --quiet

Der Audit braucht etwa 20 Sekunden. Steht er auf bestanden, ist die Datei formal in Ordnung. Ob sie jemand liest, verrät dir nur dein Server-Log.

Schritt 5: Abrufe messen

Das ist der Schritt, den fast alle Anleitungen weglassen. Wenn du schon eine Datei anlegst, dann miss auch, wer sie abruft. Bei Caddy mit JSON-Logs reicht ein Einzeiler:

grep '"uri":"/llms.txt"' /var/log/caddy/access.log \
  | grep -o '"User-Agent":\["[^"]*' | sort | uniq -c | sort -rn

Bei nginx oder Apache im Standardformat:

grep ' /llms.txt ' /var/log/nginx/access.log | awk -F'"' '{print $6}' \
  | sort | uniq -c | sort -rn

Nach vier Wochen weißt du, ob sich der Aufwand lohnt. Wenn dort nur SEO-Tools auftauchen, kennst du die Antwort.

Automatisch erzeugen lassen?

Für WordPress erzeugen Yoast SEO und Rank Math die Datei per Klick, Dokumentations-Plattformen wie Mintlify machen es automatisch. Das ist bequem, aber prüfe das Ergebnis. Automatisch erzeugte Dateien listen oft einfach alle Beiträge auf, ohne Auswahl und ohne sinnvolle Beschreibungen. Damit verlieren sie genau das, was eine llms.txt von einer Sitemap unterscheidet.

Im englischsprachigen Video von Trust Insights (Juni 2026) sprechen Christopher Penn und John Wall über den Einstieg und darüber, für welche Inhalte die Datei sinnvoll ist.

Risiken und Missverständnisse

Eine llms.txt kostet wenig, aber nicht nichts. Ein paar Punkte solltest du kennen, bevor du eine veröffentlichst.

Sie ist öffentlich und lädt zum Kopieren ein. Eine sauber aufbereitete Zusammenfassung deiner wichtigsten Inhalte ist auch für Scraper bequem. Wer seine Inhalte vor KI-Training schützen will, erreicht das über die robots.txt und Zugriffssperren, nicht durch Weglassen einer llms.txt. Umgekehrt solltest du in die Datei nichts schreiben, was nicht auch auf deinen öffentlichen Seiten steht.

Sie muss gepflegt werden. Eine llms.txt, die auf umbenannte oder gelöschte Seiten zeigt, ist schlimmer als keine. Ein Agent folgt den Links und landet im Leeren. Am besten erzeugst du sie beim Build automatisch aus deinen Inhalten und kuratierst nur die Auswahl von Hand.

Sie steuert keine Zugriffe. In manchen Anleitungen steht, man könne in der llms.txt festlegen, welche Inhalte KI nutzen darf. Das stimmt nicht. Die Spezifikation kennt keine Erlaubnis- oder Verbotsregeln. Das bleibt Aufgabe der robots.txt.

Sie ist kein Hebel für Rankings oder Zitate. Wer verspricht, dass eine llms.txt deine Website in ChatGPT, Perplexity oder den AI Overviews sichtbarer macht, verspricht etwas, das kein Anbieter bestätigt und das wir in unseren Logs nicht nachvollziehen konnten. Was in KI-Antworten zitiert wird, entscheidet sich an den Inhalten selbst. Mehr dazu in unserem Artikel über Google, AI Overviews und KI-SEO.

Für wen lohnt sich llms.txt?

Nach unseren Messungen lässt sich das ziemlich klar beantworten.

Lohnt sich:

• Entwickler-Dokumentationen, APIs, SDKs und Open-Source-Projekte. Hier nutzen Coding-Agenten die Datei wirklich, und Entwickler kopieren die URL gezielt in ihre Werkzeuge.
• Software- und SaaS-Produkte, bei denen Kunden mit KI-Assistenten Integrationen bauen.
• Websites, die ohnehin schon Markdown-Fassungen haben. Dann ist die llms.txt nur noch eine Linkliste und in zehn Minuten erledigt.

Kann man machen, bringt aber messbar wenig:

• Shops, Firmenwebsites, Blogs und Magazine. Der Aufwand ist gering, also schadet es nicht, solange die Datei korrekt ist. Erwarte aber keine Wirkung auf Suche oder KI-Zitate.

Lieber erst etwas anderes:

• Wer noch keine saubere robots.txt, keine aktuelle Sitemap und kein IndexNow hat, sollte damit anfangen. Diese drei Dateien bzw. Protokolle werden nachweislich gelesen, wir sehen das jeden Tag in unseren Logs.

Und getmind.io?

Wir haben uns bewusst gegen eine llms.txt entschieden, zumindest vorerst. Unsere Leser sind überwiegend Menschen, die über die Suche kommen, und in 27 Tagen hat kein einziger KI-Crawler nach der Datei gefragt. Spannender finden wir die 2.386 Anfragen nach Markdown. Wenn wir Zeit in maschinenlesbare Inhalte stecken, dann eher in Markdown-Fassungen unserer Artikel, die per Content-Negotiation ausgeliefert werden. Wenn wir das umsetzen, messen wir die Wirkung und schreiben das Ergebnis hier dazu.

FAQ zu llms.txt

Was ist llms.txt einfach erklärt?

Eine Markdown-Datei unter /llms.txt, die Sprachmodellen und KI-Agenten in wenigen Zeilen erklärt, worum es auf einer Website geht, und auf die wichtigsten Inhalte verlinkt. Man kann sie sich wie ein kommentiertes Inhaltsverzeichnis für Maschinen vorstellen.

Ist llms.txt ein offizieller Standard?

Nein. Es ist ein Vorschlag von Jeremy Howard (Answer.AI) aus dem September 2024, überarbeitet als Version 2 im August 2026. Es gibt keinen RFC und keine Standardisierungsorganisation dahinter, anders als bei der robots.txt (RFC 9309).

Liest ChatGPT, Claude oder Perplexity meine llms.txt?

Deren Crawler offenbar nicht. In unseren 27 Tagen Logs hat keiner der Crawler von OpenAI, Anthropic, Perplexity, Google, Microsoft oder Apple die Datei abgerufen, obwohl dieselben Bots die robots.txt hunderte Male geholt haben. Gelesen wird sie, wenn ein Nutzer einen Agenten gezielt dorthin schickt, etwa beim Programmieren mit einer fremden Dokumentation.

Bringt llms.txt etwas für Google und die AI Overviews?

Nein. Google sagt im Leitfaden vom 15. Mai 2026 ausdrücklich, dass Google Search solche Dateien nicht nutzt, auch nicht für AI Overviews und AI Mode.

Warum prüft Lighthouse dann auf llms.txt?

Lighthouse prüft in der Kategorie „Agentic Browsing“, wie gut KI-Agenten auf einer Seite arbeiten können. Das hat mit der Suche nichts zu tun. Wichtig: Fehlt die Datei, gilt der Audit als „nicht anwendbar“. Durchfallen kannst du nur mit einer fehlerhaften Datei oder einem Serverfehler.

Was ist der Unterschied zwischen llms.txt und robots.txt?

Die robots.txt regelt, welche Crawler welche Bereiche abrufen dürfen, und wird von allen seriösen Crawlern gelesen. Die llms.txt regelt gar nichts, sondern bietet eine kuratierte Übersicht an. Sie ersetzt die robots.txt nicht und kann keine Zugriffe sperren.

Was ist der Unterschied zwischen llms.txt und llms-full.txt?

Die llms.txt ist eine kurze Linkliste mit Beschreibungen. Die llms-full.txt enthält den kompletten Inhalt aller Seiten in einer Datei. Sie ist nicht Teil der Spezifikation und wird bei großen Dokus schnell riesig, bei developers.cloudflare.com zum Beispiel 69 MB.

Wo muss die llms.txt liegen?

Im Root deiner Domain unter /llms.txt. Seit Version 2 sind auch Unterpfade wie /docs/llms.txt erlaubt. Eine solche Datei gilt dann für alle Seiten unter diesem Pfad.

Welchen Content-Type braucht llms.txt?

text/plain oder text/markdown, jeweils mit UTF-8. Beides ist in der Praxis üblich. docs.github.com und docs.docker.com liefern zum Beispiel text/markdown, react.dev und nodejs.org text/plain.

Kann eine llms.txt schaden?

Direkt nicht. Eine fehlerhafte Datei lässt aber den Lighthouse-Audit durchfallen, veraltete Links schicken Agenten ins Leere, und eine gut aufbereitete Zusammenfassung macht Scrapern die Arbeit leichter. Wer keine Datei hat, hat keines dieser Probleme.

Brauche ich für WordPress ein Plugin?

Yoast SEO und Rank Math können die Datei erzeugen. Du kannst sie aber genauso gut von Hand schreiben und per FTP ins Hauptverzeichnis legen. Prüfe das Ergebnis eines Plugins immer, weil automatisch erzeugte Dateien oft nur alle Beiträge auflisten.

Wie finde ich heraus, ob meine llms.txt gelesen wird?

Nur über dein Server-Log. Filtere die Abrufe von /llms.txt nach User-Agent, wie im Abschnitt „Abrufe messen“ gezeigt. Analytics-Tools im Browser sehen solche Abrufe nicht, weil dabei kein JavaScript ausgeführt wird.

Fazit

llms.txt ist eine vernünftige Idee mit einem klaren, aber engen Einsatzgebiet. Für Entwickler-Dokumentationen und APIs ist die Datei inzwischen Standard, und dort wird sie von Coding-Agenten auch wirklich genutzt. Für alle anderen Websites ist sie bisher vor allem ein Häkchen in SEO-Tools. Unsere Messung ist eindeutig: 78 Abrufe in 27 Tagen, mehr als zwei Drittel davon von einem einzigen SEO-Audit-Tool, null von den Crawlern der KI-Anbieter und Suchmaschinen.

Wenn du eine llms.txt anlegst, dann richtig: kurz, kuratiert, mit H1 und Links, ohne Soft-404 und mit einem Blick ins Log nach vier Wochen. Wenn du keine anlegst, verlierst du nach heutigem Stand nichts, auch nicht in Lighthouse. Und wenn du wirklich etwas für maschinenlesbare Inhalte tun willst, schau dir an, ob bei dir schon Anfragen mit Accept: text/markdown ankommen. Bei uns waren es 2.386.