Meine llms.txt war zu 60 Prozent gelogen — und niemand hat es gemerkt

Ich habe vor etwa einem Jahr eine llms.txt für diese Website angelegt. Ordentlich gemacht, dachte ich: Kategorien aufgelistet, Fachartikel verlinkt, Tutorial-Serien mit Teileanzahl, GitHub-Profil dazu. Dann habe ich sie hochgeladen und nie wieder angesehen. Vor ein paar Tagen kam ich zufällig darauf zurück, weil ich etwas ganz anderes geprüft habe, und dachte mir: Schauen wir doch mal, ob die Links darin überhaupt noch funktionieren. Von siebzehn Verweisen waren zehn tot. Nicht „etwas veraltet“, sondern echte 404er. Und das Unangenehme daran ist nicht der Fehler selbst. Es ist, dass ich ein Jahr lang keinerlei Hinweis darauf bekommen habe.

Was genau kaputt war

Der Reihe nach. Drei Verweise zeigten auf Kategorien, die es einmal gab und dann nicht mehr: /category/entwicklung/, /category/wandern/ und /category/kochen/. Die hatte ich irgendwann umstrukturiert, weil die Kategorien anders geschnitten werden sollten. In WordPress war das eine Sache von zwei Minuten. Dass in einer Textdatei im Root-Verzeichnis noch die alten Pfade standen, ist mir dabei schlicht nicht in den Sinn gekommen.

Sechs weitere Verweise zeigten auf Fachartikel, die ich angekündigt hatte. Die Texte existieren tatsächlich, sie liegen als HTML-Dateien in meinem Projektverzeichnis. Sie sind nur nie in WordPress importiert worden. Ich hatte die llms.txt geschrieben, während die Artikel in Arbeit waren, und die Verweise gleich mit eingetragen — in der festen Absicht, den Import „demnächst“ zu machen. Das war vor einem Jahr. Die Datei hat seitdem sechs Artikel beworben, die es unter diesen Adressen nie gab.

Und dann war da noch der GitHub-Link. Er zeigte auf github.com/ruhrcoder, weil das der Name ist, unter dem ich hier auftrete. Mein Account heißt aber anders. Auch das: 404, seit dem ersten Tag.

Bleiben sieben funktionierende Verweise von siebzehn. Dazu kamen noch die Teileangaben hinter den Serien — „KI in der Softwareentwicklung (8 Teile)“, „C#/.NET (35 Teile)“ und so weiter. Die stimmten ebenfalls nicht mehr, weil ich seitdem weitergeschrieben habe. Aus acht KI-Artikeln waren dreizehn geworden, aus fünfunddreißig C#-Teilen zweiundvierzig, aus vier Shopware-Teilen zwölf. Jede einzelne Zahl in der Datei war falsch.

Warum das ein Jahr lang niemandem auffällt

Hier wird es interessant, und hier liegt für mich der eigentliche Erkenntnisgewinn. Wenn auf einer normalen HTML-Seite ein Link ins Leere zeigt, gibt es eine ganze Reihe von Mechanismen, die dich darauf stoßen. Die Google Search Console meldet 404-Fehler. Der Browser eines Besuchers zeigt eine Fehlerseite, und irgendwann schreibt dir jemand. Dein Server-Log füllt sich mit 404-Einträgen. Ein Linkchecker, den du vielleicht in der Pipeline hast, schlägt an.

Bei der llms.txt greift nichts davon. Sie ist eine reine Textdatei ohne Schema, ohne Validator, ohne offizielle Prüfstelle. Kein Werkzeug im typischen Werkzeugkasten kennt sie. Die Search Console interessiert sich nicht dafür, weil Google sie nicht auswertet — dazu gleich mehr. Und ein Mensch ruft sie praktisch nie auf, denn sie ist ja nicht für Menschen gedacht. Die Datei liegt da, sieht ordentlich aus, und verrottet still vor sich hin.

Das ist ein Muster, das man aus anderen Ecken kennt: Alles, was keine Rückmeldung gibt, wenn es kaputtgeht, geht irgendwann kaputt. Eine Datenbanksicherung, die nie zurückgespielt wird. Ein Monitoring, das keine Alarme sendet. Eine Textdatei, die niemand liest. Die llms.txt ist genau so ein Fall — ein Artefakt, das man einmal anlegt und dann für erledigt hält, weil es sich nie beschwert.

Der unbequeme Teil: Liest das überhaupt jemand?

Bevor ich erzähle, wie ich meine Datei repariert habe, muss ich eine Frage stellen, die ich mir ehrlich gesagt vorher nie ernsthaft gestellt hatte. Wenn zehn von siebzehn Verweisen ein Jahr lang tot sind und es fällt niemandem auf — ruft die Datei dann überhaupt jemand ab?

Die Antwort ist ernüchternder, als mir lieb war. Die llms.txt ist ein Vorschlag, kein Standard. Sie wurde Ende 2024 von Jeremy Howard in die Welt gesetzt, hat sich seitdem verbreitet und liegt inzwischen auf rund jeder zehnten untersuchten Domain. Verbreitung ist aber nicht dasselbe wie Wirkung. Eine Auswertung von über 500 Millionen KI-Bot-Zugriffen über neunzig Tage fand ganze 408 Abrufe, die tatsächlich der llms.txt galten. Das sind, gerundet, null Prozent. Bei rund siebenundneunzig Prozent aller angelegten Dateien passiert schlicht gar nichts.

Das deckt sich mit dem, was die Anbieter selbst sagen. Google hat im Juni 2026 offiziell in seinen Hinweisen zur KI-Optimierung ergänzt, dass eine llms.txt für Google Search nicht erforderlich ist; schon ein Jahr zuvor hatte Gary Illyes klargestellt, dass Google sie nicht unterstützt und das auch nicht vorhat. Die Crawler-Dokumentation von OpenAI erwähnt sie nicht und verweist für alles, was das Verhalten von Bots betrifft, auf die robots.txt. Anthropic hält es genauso. Wer also eine llms.txt anlegt in der Erwartung, damit in KI-Suchergebnissen besser dazustehen, wartet auf einen Effekt, den es so nicht gibt.

Ich finde es wichtig, das deutlich zu sagen, weil in vielen Artikeln zu dem Thema ein anderer Ton herrscht. Da wird die llms.txt als der neue Hebel für Sichtbarkeit verkauft. Nach allem, was messbar ist, stimmt das nicht. Und eine Datei, die als Rankingfaktor angepriesen wird, aber keiner ist, produziert genau das, was ich bei mir selbst gefunden habe: Man legt sie einmal an, hakt sie ab, und sie verrottet.

Wo sie trotzdem gelesen wird

Jetzt kommt die Wendung, und die ist der Grund, warum ich meine Datei nicht einfach gelöscht habe. Es gibt sehr wohl Systeme, die eine llms.txt auswerten — nur sind es nicht die Crawler, sondern die Assistenten. Werkzeuge wie Claude Code oder Cursor holen sich die Datei, wenn du im Gespräch eine Domain nennst. Das ist ein anderer Vorgang als Crawling: Kein Bot zieht im Hintergrund systematisch durchs Netz, sondern ein Agent lädt gezielt und in dem Moment, in dem jemand nach genau dieser Website fragt. Anthropic selbst pflegt aus diesem Grund eine llms.txt für die eigene Dokumentation — nicht fürs Ranking, sondern damit Entwicklungswerkzeuge und MCP-Integrationen sauber darauf zugreifen können.

Das verändert die Frage, für wen man die Datei eigentlich schreibt. Nicht für einen Suchalgorithmus, der Relevanz gewichtet, sondern für ein Programm, das gerade eine konkrete Aufgabe hat und in wenigen Sekunden verstehen muss, was auf dieser Domain zu finden ist. Und deshalb ist eine kaputte llms.txt nicht harmlos. Sie ist schlimmer als gar keine. Wer keine hat, zwingt den Agenten dazu, sich die Struktur selbst zu erschließen — über Sitemap, Navigation, Kategorieseiten. Das dauert länger, führt aber zu etwas Richtigem. Wer eine kaputte hat, liefert eine Landkarte mit Straßen, die es nicht gibt. Der Agent glaubt sie erst einmal, läuft in sechs 404er und muss dann trotzdem den langen Weg gehen.

Was ich daraus für den Inhalt gelernt habe

Beim Neuschreiben habe ich drei Regeln für mich festgelegt, und alle drei ergeben sich direkt aus den Fehlern, die ich gemacht hatte.

Erstens: keine Zahlen. Meine Serienangaben waren allesamt falsch, weil eine Teileanzahl in dem Moment veraltet, in dem man weiterschreibt. Eine Angabe, die sich selbst überholt, ist keine Information, sondern eine Wartungsschuld. Wenn ein Agent wissen will, wie viele Artikel in einer Kategorie liegen, kann er die Kategorieseite aufrufen und nachzählen. Dort steht die Wahrheit ohnehin aktueller, als sie in einer Textdatei je stehen könnte.

Zweitens: nichts eintragen, was noch nicht veröffentlicht ist. Das war mein teuerster Fehler, sechs tote Verweise auf einen Schlag. Die Versuchung ist verständlich — man schreibt die Datei, hat die geplanten Artikel im Kopf und trägt sie gleich mit ein. Aber eine llms.txt beschreibt einen Zustand, keine Absicht. Was nicht abrufbar ist, gehört nicht hinein, egal wie fertig der Text im Projektverzeichnis schon ist.

Drittens: kanonische Adressen verwenden. Das ist mir erst beim Reparieren aufgefallen. Meine Kategorien sind hierarchisch, die Unterkategorie ki hängt unter programmierung. WordPress beantwortet beide Formen mit Status 200 — sowohl /category/ki/ als auch /category/programmierung/ki/. Ein reiner Statuscode-Test hätte mir also grünes Licht gegeben. Im canonical-Tag der Seite steht aber die lange Form, und genau die gehört in die Datei. Sonst beschreibt man die eigene Struktur anders, als die Website sie selbst beschreibt.

Ergänzt habe ich außerdem etwas, das vorher komplett fehlte: meine vier Glossare. Das sind Seiten, auf denen jeder Fachbegriff einen eigenen Ankerlink hat — für ein Programm, das eine Definition sucht, mit Abstand das Wertvollste auf dieser Website. Sie standen nicht drin, weil ich beim ersten Anlegen an Kategorien und Artikel gedacht hatte und nicht daran, was ein Agent tatsächlich brauchen könnte. Das ist vielleicht die eigentliche Lehre: Ich hatte die Datei aus meiner Sicht geschrieben, nicht aus der des Lesers.

Wie man das prüft, ohne es zu vergessen

Die Prüfung selbst ist trivial, und genau das macht es so ärgerlich, dass ich sie ein Jahr lang nicht gemacht habe. Man zieht die Pfade aus der Datei und fragt jeden einzelnen ab. In einer Zeile Shell sieht das so aus:

grep -oE '^- /[^ ]*' llms.txt | sed 's/^- //' | while read u; do
  printf "%-46s %s\n" "$u" "$(curl -s -o /dev/null -w '%{http_code}' "https://deine-domain.de$u")"
done

Das gibt dir eine Liste aus Pfad und Statuscode, und alles, was nicht 200 ist, gehört angesehen. Wer es genauer will, hängt noch einen Abgleich mit dem canonical-Tag an, um die Weiterleitungsfälle zu erwischen, die ein reiner Statuscode-Test durchgehen lässt. Der eigentliche Punkt ist aber nicht das Skript, sondern wann es läuft. Ein Test, den man von Hand anstoßen muss, wird nicht ausgeführt — das hat mein Jahr Funkstille eindrucksvoll gezeigt. Sinnvoll ist es deshalb, die Prüfung dorthin zu hängen, wo ohnehin etwas automatisch passiert: in die Deployment-Pipeline, in einen wöchentlichen Job, irgendwohin, wo sie sich von selbst meldet. Ich habe sie mir bei der nächsten Gelegenheit in den Deploy-Vorgang gelegt, damit ein toter Verweis auffällt, bevor die Datei überhaupt live geht.

Lohnt sich die Datei denn nun?

Meine Antwort ist ein vorsichtiges Ja, aber mit deutlich anderer Begründung, als ich sie vor einem Jahr gehabt hätte. Als SEO-Maßnahme taugt die llms.txt nach heutigem Stand nicht — die Suchmaschinen werten sie nicht aus, und wer sie mit dieser Erwartung anlegt, wird enttäuscht. Wenn deine Website vor allem über klassische Suche gefunden wird, kannst du dir die Datei sparen und stattdessen an sauberen Überschriften, verständlichem Fließtext und einer korrekten Sitemap arbeiten. Das wirkt nachweislich.

Sinnvoll wird sie dort, wo Entwicklungswerkzeuge und Agenten auf deine Inhalte zugreifen sollen: bei Dokumentationen, bei APIs, bei technischen Blogs wie diesem hier. Der Aufwand ist überschaubar, eine gute Datei passt auf eine Bildschirmseite. Und sie ist ein ehrlicher Testfall für die eigene Struktur — wenn du deine Website nicht auf einer Seite erklären kannst, ist das ein Hinweis, der über die Datei hinausgeht.

Wofür sie sich dagegen definitiv nicht lohnt: einmal anlegen, abhaken und ein Jahr lang nicht mehr ansehen. Dann hast du keine Landkarte, sondern eine Sammlung von Behauptungen über deine eigene Website, die niemand nachprüft. Ich habe ein Jahr gebraucht, um das bei mir selbst zu bemerken, und ehrlich gesagt nur durch Zufall. Die Datei ist jetzt kürzer als vorher, enthält keine einzige Zahl mehr und verweist ausschließlich auf Dinge, die es tatsächlich gibt. Das ist weniger beeindruckend zu lesen. Dafür stimmt es.