Eine llms.txt kann einen kurzen, gepflegten Einstieg in die Inhalte einer Website bieten. Ob ein bestimmter Agent sie findet, ihre Links nutzt und dadurch eine Aufgabe besser löst, musst du am konkreten Ablauf prüfen. Die bloße Existenz der Datei beantwortet diese Fragen nicht.
Für Google Search ist die Einordnung inzwischen ausdrücklich dokumentiert. Googles am 21. Oktober 2026 geprüfter Leitfaden zur Optimierung für generative Suchfunktionen erklärt, dass Google Search llms.txt und ähnliche spezielle KI-Textdateien nicht als solche verwendet. Eine Datei für andere Dienste darfst du trotzdem anbieten. Daraus folgt keine belegte Wirkung auf Google-Rankings oder Sichtbarkeit.
Die sinnvolle Entscheidung lautet deshalb: Gibt es einen bestimmten Agenten, eine konkrete Aufgabe und einen vertretbaren Pflegeaufwand für diesen zusätzlichen Einstieg? Wenn ja, lässt sich daraus ein begrenzter Pilot machen. Ein angeblicher Pflichtpunkt für jede SEO-Strategie ist damit nicht begründet.
Was der Vorschlag tatsächlich beschreibt
Die Originalbeschreibung von llms.txt bezeichnet das Format als Vorschlag. Die dort veröffentlichte Version 2 wurde im August 2026 überarbeitet. Ihr Zweck ist ein für Agenten lesbarer Überblick mit Kontext und Links zu weiterführenden Inhalten.
Eine wichtige aktuelle Einzelheit: Die Datei kann auch unter einem Unterpfad liegen. /docs/llms.txt ist im Vorschlag beispielsweise für Inhalte unter /docs/ vorgesehen. Die verbreitete Kurzform „lege eine Datei ins Stammverzeichnis“ beschreibt daher nicht jede mögliche Umsetzung.
Das Format verwendet Markdown. Es beginnt mit einer H1 für den Namen des Projekts oder der Website. Eine kurze Zusammenfassung und nach Themen geordnete Linklisten können den Einstieg ergänzen. Der Vorschlag beschreibt außerdem Markdown-Fassungen einzelner Seiten und Verweise, über die Clients diese finden können.
Diese Beschreibung legt eine Konvention fest. Sie beweist nicht, dass alle Agenten sie implementieren oder jede vorhandene Datei automatisch abrufen. Die Unterstützung des konkreten Clients gehört deshalb in die Einführung, nicht in eine Fußnote nach dem Rollout.
Ein kleines Beispiel, keine zweite Website
Angenommen, ein Unternehmen betreibt eine öffentliche Dokumentation. Ein kurzer Einstieg könnte schematisch so aussehen:
markdown# Beispiel-Dokumentation
> Öffentliche Anleitungen für die Einrichtung und den laufenden Betrieb.
## Einrichtung
- [Erste Schritte](https://example.com/docs/start.md): Voraussetzungen und Ablauf.
## Betrieb
- [Fehler eingrenzen](https://example.com/docs/diagnose.md): Beobachtungen und nächste Prüfschritte.
Die Adressen sind erfunden. Verlinke in einer echten Datei ausschließlich passende, tatsächlich verfügbare Fassungen. Ein an die URL angehängtes .md erzeugt noch keine Markdown-Seite. Wenn der Server dafür nur die normale Navigation oder eine Fehlerseite ausliefert, ist der Verweis nicht erfüllt.
Wähle Inhalte nach der Aufgabe aus. Ein Agent, der eine Einrichtung erklären soll, braucht Voraussetzungen und einen nachvollziehbaren Ablauf. Eine Sammlung aller Blogtitel hilft ihm möglicherweise weniger. Eine kleine kuratierte Liste lässt sich außerdem leichter aktuell halten als ein automatisch angehängter Gesamtexport.
Die Datei sollte dieselben Aussagen tragen wie die Originalquellen. Wenn eine Anleitung geändert wird, müssen Zusammenfassung und Verweis weiter passen. Ein zusätzlicher Einstieg mit veralteten Angaben kann die Orientierung gerade dort verschlechtern, wo er sie verbessern soll.
Inhaltshinweise ersetzen keine Zugriffssteuerung
Eine llms.txt kann beschreiben, wo passende Informationen liegen. Sie hebt aber weder eine Anmeldung auf noch beseitigt sie eine Firewall-Sperre. Wenn die verlinkte Seite nicht erreichbar ist, bleibt sie für diesen Abruf unzugänglich.
Auch die robots.txt hat eine andere Aufgabe. Sie formuliert Abrufregeln für Crawler, die diese beachten. Welche Regeln für einen Suchbot, Trainingsbot oder nutzerinitiierten Abruf gelten, ist am jeweiligen Dienst zu prüfen. Unser Beitrag zum Erlauben und Blockieren von KI-Crawlern erklärt diese Trennung nach Zweck.
Aus einem freundlichen Hinweis in llms.txt folgt keine technische Zugangskontrolle. Die Datei ist außerdem öffentlich, wenn du sie öffentlich auslieferst. Veröffentliche darin keine internen Informationen, Zugangsdaten oder Links auf private Vorschauen, die lediglich durch eine schwer zu erratende Adresse verborgen sind.
Vor der Frage nach Antwortqualität steht deshalb die Abrufprüfung. Ein 200 allein reicht dabei nicht. Du musst sehen, ob die Datei und die verlinkten Quellen tatsächlich den vorgesehenen Inhalt liefern.
Was ein eigener Abruf beweist
Mit einem gewöhnlichen GET kannst du Header und Inhalt speichern:
bashcurl -sS -D llms-headers.txt -o llms-body.txt "https://example.com/docs/llms.txt"
Unter Windows PowerShell verwendest du bei Bedarf curl.exe. Ersetze die Beispieladresse durch eine Datei, die du prüfen darfst. Kontrolliere Status, etwaige Weiterleitung und Body. Eine mit 200 ausgelieferte HTML-Fehlerseite ist keine korrekt geladene Markdown-Übersicht.
Öffne anschließend die aufgeführten Quellen. Passen Sprache, Produktversion und Inhalt zur Beschreibung? Funktioniert ein direkter Abruf ohne bestehende Sitzung? Bewahre die geprüfte Fassung mit Datum auf, damit spätere Änderungen nachvollziehbar bleiben.
Damit ist eine technische Erreichbarkeit für deinen Testclient belegt. Ein Serverprotokoll mit einem späteren Dateiaufruf belegt einen weiteren Abruf. Dieses Crawling sagt allein noch nichts darüber aus, ob ein Sprachmodell die Datei in eine Antwort einbezogen hat. Auch ein User-Agent ist zunächst eine vom Client gesetzte Angabe.
Vier Fälle für einen begrenzten Pilot
Der folgende Ablauf ist ein Versuchsplan, kein Bericht über bereits erzielte Ergebnisse. Wähle einen kontrollierbaren Agenten und wenige Aufgaben, deren richtige Antworten anhand deiner Quellen überprüfbar sind. Starte nach Möglichkeit mit einer Testdokumentation, deren Fassungen du sauber festhalten kannst.
| Fall | Einstieg | Was du beobachten kannst |
|---|---|---|
| Ausgangslage | Der Agent erhält die normale öffentliche Startseite | Welche Quellen er ohne Dateihinweis findet und welche Fragen er beantwortet |
| Datei vorhanden | Gleiche Aufgabe, Datei veröffentlicht, aber nicht im Auftrag genannt | Ob dieser Client sie selbstständig entdeckt und tatsächlich abruft |
| Datei vorgegeben | Der Auftrag nennt die llms.txt ausdrücklich als Einstieg | Ob der Agent sie liest, passende Links verfolgt und richtige Belege verwendet |
| Kontrollierter Fehler | Eine isolierte Testfassung enthält einen bekannten veralteten oder defekten Verweis | Ob der Agent die Lücke erkennt oder unbelegte Angaben ergänzt |
Der letzte Fall gehört in eine geeignete Testumgebung. Beschädige keine produktiven Anleitungen, um einen Fehler zu erzeugen. Der Zweck ist, den Umgang mit fehlenden Quellen zu verstehen, nicht eine öffentliche Fehlfassung zu verteilen.
Halte Modell- oder Clientversion, erlaubte Werkzeuge, Aufgabe und Quellenstand fest. Eine neue Sitzung hilft, übernommene Informationen aus dem vorherigen Durchlauf zu vermeiden. Wenn ein Dienst keinen Einblick in seine Abrufe gewährt, notiere diese Grenze. Ein plausibler Antworttext ersetzt das fehlende Abrufprotokoll nicht.
Sichere die benötigten Belege zeitnah. Wenn ein Protokoll nur einen begrenzten Zeitraum abdeckt, lässt sich ein später fehlender Treffer nicht rückwirkend als fehlende Nutzung auslegen. Halte deshalb fest, für welchen Zeitraum und welchen Auslieferungspfad deine Beobachtung vollständig ist und wo Informationen fehlen.
Entdeckung und Nutzen nicht verwechseln
Ein Agent kann eine ausdrücklich genannte Datei gut nutzen, ohne sie selbstständig zu entdecken. Das wäre ein brauchbares Ergebnis für einen gesteuerten Dokumentationsworkflow. Es belegt keine automatische Nutzung durch öffentlich zugängliche Such- oder Antwortdienste.
Auch der Abruf eines Links ist noch keine richtige Antwort. Prüfe, ob die Antwort die für die Aufgabe nötigen Aussagen enthält, den Quellenstand berücksichtigt und Unsicherheit dort kenntlich macht, wo Informationen fehlen. Speichere die tatsächlich verwendeten Verweise neben dem Ergebnis.
Für die Auswertung reichen verständliche Kategorien: richtige Antwort mit passendem Beleg, richtige Antwort ohne nachvollziehbaren Beleg, unvollständige Antwort und falsche oder unbelegte Aussage. Lege die erwarteten Aussagen vorher fest. Sonst passt sich die Bewertung leicht an das Ergebnis an, das du dir vom neuen Format erhofft hast.
Ein einzelner guter Durchlauf ist keine belastbare Wirkungsstudie. Wiederhole vergleichbare Aufgaben und dokumentiere Abweichungen. Bleiben Client, Quellen und Werkzeugzugriff unkontrolliert, kann eine veränderte Antwort viele Ursachen haben. Eine zusätzliche Datei gleichzeitig mit neuen Artikeln, geänderter Verlinkung und einem Modellwechsel einzuführen, erlaubt keine saubere Zuordnung.
Prüfe außerdem, ob der vermeintliche Dateivorteil aus einer besseren redaktionellen Auswahl stammt. Wenn nur die llms.txt eine klare Reihenfolge und hilfreiche Beschreibungen enthält, vergleichst du zugleich zwei unterschiedlich gut aufbereitete Einstiege. Für einen engeren Formatvergleich sollte eine Kontrollfassung dieselben Informationen und Links bereitstellen. Ein besserer Überblick kann nützlich sein, ohne dass gerade der Dateiname die Wirkung verursacht.
Lege ebenso fest, was überhaupt als Fehler zählt. Eine frei formulierte Antwort muss nicht dieselben Wörter wie deine Musterlösung verwenden. Fehlt dagegen eine entscheidende Voraussetzung oder wird eine veraltete Anleitung als aktuell dargestellt, ist das ein inhaltlicher Fehler. Bewerte solche Fälle anhand dokumentierter Aussagen, bevor du Abrufzahlen oder Bearbeitungszeiten zusammenfasst. Bei sehr kleinen Stichproben sind einzelne Fallbeschreibungen häufig aussagekräftiger als eine präzise wirkende Prozentzahl ohne belastbare Grundlage.
Für Google und andere Dienste getrennt messen
Google beschreibt für AI Overviews und andere generative Suchfunktionen weiterhin den Zusammenhang mit Suchindex, technischer Zugänglichkeit und hilfreichen Inhalten. Die Dokumentation zu KI-Funktionen und Websites nennt keine zusätzliche KI-Datei als Voraussetzung. Die ausdrücklichere aktuelle Einordnung von llms.txt steht im oben verlinkten Optimierungsleitfaden.
Unter dem Begriff Generative Engine Optimization werden sehr unterschiedliche Maßnahmen zusammengefasst. Benenne beim Pilot deshalb das konkrete System und den beabsichtigten Ablauf. Die Unterstützung einer Dateikonvention in einem Dokumentationsagenten lässt sich nicht auf sämtliche Suchfunktionen übertragen.
Wenn die Zielseite gar nicht für die Indexierung zugänglich ist, untersuche zuerst diese Voraussetzung. Unser Leitfaden zu „Gecrawlt, zurzeit nicht indexiert“ behandelt eine andere Problemstufe als die Lesbarkeit einer llms.txt.
Für Google verweist der aktuelle Optimierungsleitfaden auf den Bericht zur Leistung in generativen KI-Funktionen in der Search Console. Solche Leistungsdaten sind von einem Dateiaufruf zu unterscheiden. Mehr Sichtbarkeit nach einer Veröffentlichung beweist nicht, dass llms.txt sie verursacht hat. Für andere Dienste brauchst du deren tatsächlich verfügbare Beobachtungen und eine passende Vergleichsbasis.
Pflege und Entscheidung nach dem Pilot
Bestimme, wer für die Auswahl und Aktualität verantwortlich ist. Prüfe die Datei nach Änderungen an wichtigen Quellen, Sprachpfaden oder Dokumentationsversionen erneut. Ein automatischer Generator kann Verweise erzeugen. Ob seine Auswahl zur Aufgabe passt, bleibt eine redaktionelle Frage.
Für Teams, die Recherche und Inhalte gemeinsam organisieren möchten, bietet die Plattformübersicht von Crawl Foundry einen Einstieg. Für den Dateipilot selbst hältst du zusätzlich Aufgabe, Quellenstand und beobachtete Abrufe fest. Das verbindet inhaltliche Verantwortung mit einem überprüfbaren Test.
Setze vorab eine Grenze für den Pflegeaufwand. Wenn kein relevanter Client die Datei nutzt oder die Verweise keinen erkennbaren Vorteil für eure Aufgaben schaffen, muss daraus kein dauerhaftes Projekt werden. Wenn ein bestimmter Agent damit nachweislich zuverlässiger an die richtigen Quellen gelangt, dokumentiere genau diesen begrenzten Nutzen.
Ein brauchbarer Abschluss benennt das System, die getesteten Aufgaben und die beobachteten Schritte. Er darf auch lauten: technisch erreichbar, selbstständige Entdeckung bislang nicht beobachtet, Nutzen bei ausdrücklich vorgegebenem Einstieg noch zu prüfen. Diese Auskunft hilft bei der nächsten Entscheidung mehr als ein pauschaler Haken für vermeintliche KI-Sichtbarkeit.