llms.txt erstellen und prüfen: eine Anleitung

Von Manfred Mayer Rieger · Veröffentlicht 15. September 2026

Eine Website veröffentlicht /llms.txt, schreibt dazu einen Absatz im Blog und hakt das Thema ab. Monate später meldet eine Routineprüfung: Datei fehlt. Verwirrend, denn die URL liefert weiterhin HTTP 200. Nur liefert sie eben die Startseite aus — dieselbe Seite, die jede beliebige Adresse auf der Domain bekommt, die zu keiner echten Route passt. Die Datei wurde nie wirklich ausgeliefert. Sie sah nur so aus, für jeden, der sich den Inhalt nicht angeschaut hat.

Der Grund: Die wenigsten Websites liefern bei einem unbekannten Pfad einen echten 404. Der Router einer Single-Page-App oder eine Catch-all-Regel im CDN schickt jede nicht erkannte URL auf dieselbe Ersatzseite statt auf eine Fehlerseite. Eine /llms.txt, die im falschen Verzeichnis liegt, oder die auf einer Doku-Seite erwähnt wird, bevor das zugehörige Deployment sie tatsächlich ausgerollt hat, scheitert genauso wie eine vertippte URL: 200, und der falsche Inhalt. Eine Datei, die in dem Sinn “da” ist, dass die Adresse antwortet, und gleichzeitig “nicht da”, weil es das Dokument gar nicht gibt — dieser merkwürdige Zwischenzustand ist bei einem einzigen falsch gesetzten Detail der Normalfall, nicht die Ausnahme.

Was muss die Datei überhaupt enthalten?

Das Format, festgelegt auf llmstxt.org, ist bewusst schmal gehalten. Ein Pflichtelement: eine H1 mit dem Namen der Website oder des Projekts. Alles danach ist empfohlen, aber optional — eine Blockquote-Zusammenfassung direkt unter dem Titel, dann null oder mehr H2-Abschnitte, jeder eine Liste von Markdown-Links mit einer optionalen Notiz nach einem Doppelpunkt.

# Seitenname

> Ein bis zwei Sätze, die beschreiben, worum es auf dieser Website geht.

## Docs

- [Erste Schritte](https://example.com/docs/start): Einrichtung und erste Schritte
- [API-Referenz](https://example.com/docs/api): vollständige Liste der Endpunkte

## Optional

- [Änderungsprotokoll](https://example.com/changelog): letzte Releases

Das ist die gesamte Struktur. Kein Frontmatter, kein XML, kein Schema, gegen das geprüft werden könnte — außer der Frage, ob es Markdown ist und ob die Abschnitte in dieser Reihenfolge stehen. Die Optional-Überschrift ist der Konvention nach für Links gedacht, die ein Modell bei knappem Kontextfenster überspringen kann — ein Änderungsprotokoll etwa, statt der Doku, die es gerade wirklich braucht. Genau diese Einfachheit ist der Witz an der Sache, und genau deshalb lässt sich die Datei leicht im Kleinen falsch schreiben, ohne dass irgendein Werkzeug meckert: Es gibt keinen strengen Parser, der eine fehlerhafte Datei zurückweist, wie es eine kaputte XML-Sitemap tun würde. Eine fehlende Leerzeile zwischen Blockquote und erster H2, oder ein Link, der als reiner Text statt als Markdown-Syntax geschrieben ist — beides rendert weiterhin als Seite. Nur ist es dann keine gültige llms.txt mehr, und die Datei selbst sagt das nirgendwo.

Ein erfundenes Beispiel: Die Musterfirma Acme GmbH veröffentlicht eine /llms.txt mit Titel, Zusammenfassung und einem Abschnitt “Docs” — nur hat die Person, die sie geschrieben hat, die Links als reine URLs eingefügt statt als [Text](URL)-Paare, weil das in der eigenen Sitemap der Website genauso gemacht wird. Die Datei ist weiterhin da, liefert weiterhin 200, liest sich weiterhin als reiner Text. Nur hat sie keine Linkliste mehr, die ein Parser extrahieren kann, denn “Dateiliste” meint in der Spezifikation ausdrücklich Markdown-Links, nicht jede Zeile, in der zufällig eine URL steht. Beim Schreiben weist nichts die Datei zurück. Sie besteht jede Prüfung, die nur bestätigt, dass die Adresse antwortet.

Wo liegt sie, und wie sollte die Antwort aussehen?

Am Wurzelverzeichnis der Domain: https://example.com/llms.txt, ausgeliefert als reiner Text oder Markdown, mit Status 200 und einem echten Inhalt — nicht weitergeleitet, nicht hinter einem Query-Parameter versteckt, nicht in einem Unterverzeichnis verschachtelt. Ein Modell oder Agent, der die Datei abruft, erwartet genau das, was robots.txt und sitemap.xml bereits vorgeben: etwas, das sich direkt lesen lässt, ohne Login und ohne JavaScript zum Rendern.

Eine Weiterleitung ist ein häufigerer Fehler, als es klingt. Eine Website, die von www.example.com auf example.com umgezogen ist, oder die für jeden Pfad eine Regel für den abschließenden Schrägstrich eingeführt hat, leitet dabei oft auch /llms.txt per 301 mit weiter, zusammen mit allem anderen. Das Linkziel funktioniert in der Regel weiterhin, weshalb es niemandem auffällt, der einfach klickt. Ein Abrufer, der Weiterleitungen nicht folgt — und das tun nicht alle —, bekommt eine 301 und hört auf, ohne die Datei je wirklich gelesen zu haben.

Wie prüft man, ob sie wirklich funktioniert?

Nicht, indem man die URL im Browser-Tab öffnet und sieht, dass irgendetwas lädt. Ein Browser rendert eine HTML-Fehlerseite anstandslos und lässt sie wie eine normale Seite aussehen. Entscheidend ist die rohe Antwort:

• Die URL direkt abrufen — mit curl -i oder einem HTTP-Client, der Header und den ungerenderten Inhalt zeigt, statt einem Browser-Tab, der einfach anzeigt, was zurückkommt.
• Die ersten Bytes ansehen. curl -i https://example.com/llms.txt liefert bei einer funktionierenden Datei HTTP/2 200, einen content-type-Header von text/plain oder text/markdown und einen Inhalt, der mit # und einem Titel beginnt. Bei einem Soft-404 steht in der Statuszeile weiterhin 200, aber der Inhalt beginnt mit <!doctype html> oder <html, und der Content-Type lautet text/html.
• Den Content-Type-Header gezielt prüfen, nicht nur den Status. text/html an genau dieser Stelle ist der Hinweis — der Statuscode allein kann eine echte Datei nicht von einer Ersatzseite unterscheiden, weil beide 200 liefern.
• Parallel einen Pfad abrufen, der garantiert nicht existiert — etwa /dieser-pfad-existiert-garantiert-nicht-12345. Kommt auch der mit 200 und demselben Inhalt wie /llms.txt zurück, beantwortet der Server grundsätzlich alles mit 200, und die Prüfung von llms.txt beweist für sich genommen nichts: Die Website würde diese Prüfung bestehen, egal ob die echte Datei je veröffentlicht wurde. Genau nach dieser Logik arbeitet eine solide gebaute Website-Prüfung, bevor sie einer Existenzprüfung für einen bekannten Pfad überhaupt vertraut — erst bestätigen, dass der Server Nein sagen kann, bevor man ihm ein Ja abnimmt.
• Jedem Link in der Datei folgen. Eine Datei, die fünf Seiten auflistet, von denen zwei einen 404 liefern, ist schlechter als gar keine Datei — sie schickt eine Leserin, ob Mensch oder Modell, mit vollem Selbstvertrauen in zwei Sackgassen.

Dafür braucht es kein Spezialwerkzeug. Es ist dieselbe Disziplin, mit der man prüft, ob robots.txt oder sitemap.xml tatsächlich erreichbar sind — nur angewendet auf eine neuere Datei, für die sich diese Gewohnheit bei den meisten Teams noch nicht eingespielt hat. Ein Generator trifft das vorgeschriebene Format automatisch richtig und nimmt damit den Fehler “falsche Form” aus der Gleichung — den Fehler “nie wirklich ausgerollt” nimmt er nicht ab. Der zeigt sich erst, wenn man die Live-URL nach der Veröffentlichung tatsächlich abruft.

Ändert das schon etwas daran, was zitiert wird?

Eine Klarstellung vorweg: Eine korrekt geschriebene llms.txt ist nicht dasselbe wie eine, die nachweislich etwas bewirkt. Wie unsicher die Wirkung auf Verbraucherseite noch ist, zeigt sich daran, dass bislang keine große KI-Assistenz-Anwendung dokumentiert hat, die llms.txt einer beliebigen Domain mitten im Gespräch abzurufen. Diese Unsicherheit ändert nichts daran, dass es sich lohnt, die Datei korrekt zu schreiben. Sie bedeutet nur, dass der Aufwand in die Kategorie “billig, plausibel, unbewiesen” gehört, nicht in die Kategorie “belegter Rankinghebel” — ein Punkt auf einer längeren Liste dessen, was für die Sichtbarkeit in der KI-Suche tatsächlich zählt, keine Abkürzung an allem anderen vorbei.

Was in der Praxis tatsächlich kaputtgeht

Vier Fehlerbilder erklären fast alles. Der Soft-404-Fall von oben, bei dem der Pfad auf etwas völlig anderes zeigt. Eine Datei mit der richtigen Struktur, aber mit blanken URLs statt Markdown-Link-Syntax, wie bei der Musterfirma Acme — ein stiller Fehler, weil an der Antwort selbst nichts falsch aussieht. Eine Datei, die formal der Spezifikation entspricht, aber auf Seiten verlinkt, die inzwischen verschoben oder gelöscht wurden — das merkt nur, wer den Links tatsächlich folgt, statt sie nur zu lesen. Und eine Datei, die am Tag ihrer Entstehung korrekt war, seither aber nie wieder angefasst wurde, während die Website neue Seiten bekam und alte abgab, sodass sie langsam nicht mehr zu der Website passt, auf der sie liegt. Das Format kennt kein Verfallsdatum — eine veraltete llms.txt sieht für alles, was nur die Form prüft, genauso gültig aus wie eine aktuelle, und die Form ist das Einzige, was die meisten prüfen.

Alle vier haben eine Gemeinsamkeit: Sie bestehen einen flüchtigen Blick und scheitern an einem echten Abruf. Das spricht dafür, “existiert die Datei” und “stimmt sie auch” als zwei getrennte Fragen zu behandeln, jede für sich geprüft, statt anzunehmen, die erste beantworte automatisch die zweite.