Was llms.txt für KI-Sichtbarkeit leistet – und was nicht

llms.txt ist der Vorschlag für eine einfache Textdatei im Wurzelverzeichnis einer Website, geschrieben in Markdown, die eine kuratierte Übersicht der wichtigsten Inhalte liefert – gedacht als kompakte Orientierung für Sprachmodelle, die eine Seite nicht komplett crawlen, sondern gezielt einzelne Unterseiten laden. Die Datei liegt unter /llms.txt, beginnt mit einem Titel und einer kurzen Beschreibung und listet danach ausgewählte Links zu Unterseiten auf – keine Crawl-Anweisung, keine maschinenlesbare URL-Liste, sondern eine von Menschen lesbare Zusammenfassung.

Die Datei wird oft in einem Atemzug mit robots.txt und der XML-Sitemap genannt, funktioniert aber grundlegend anders und wird von keinem der großen KI-Anbieter öffentlich als Eingabequelle für ihre Web-Crawler bestätigt. Dieser Beitrag erklärt, was in der Datei technisch steckt, wer sie nach aktuellem Kenntnisstand tatsächlich liest, wie sie sich von den beiden etablierten Standards unterscheidet – und ob sich die Pflege für eine normale Website überhaupt lohnt.

Herkunft und Zweck des Vorschlags

Die Idee stammt von Jeremy Howard, Mitgründer von Answer.AI und bekannt aus dem Machine-Learning-Umfeld um fast.ai. Er veröffentlichte den Vorschlag im September 2024 auf der Seite llmstxt.org zusammen mit einer Begründung: Sprachmodelle arbeiten mit einem begrenzten Kontextfenster, und eine normale Webseite ist für dieses Fenster denkbar ineffizient gefüllt – Navigation, Cookie-Banner, Werbeflächen, JavaScript-Gerüst und Footer-Links verbrauchen Tokens, ohne inhaltlichen Wert zu liefern. Eine llms.txt-Datei soll diesen Ballast umgehen und einem Modell direkt die relevanten Inhalte in kompakter, sauberer Form anbieten.

Wichtig für die Einordnung: Es handelt sich um einen offenen Vorschlag einzelner Personen und Projekte, nicht um einen ratifizierten Webstandard. Es gibt kein Normungsgremium wie die IETF oder das W3C, das die Syntax verbindlich festgelegt oder die Einhaltung geprüft hätte. Das unterscheidet llms.txt fundamental von robots.txt, das mittlerweile als RFC 9309 offiziell dokumentiert ist, und von der Sitemap, deren Protokoll seit Jahren von den großen Suchmaschinen gemeinsam getragen wird. llms.txt befindet sich in einem früheren, unentschiedenen Stadium – vergleichbar mit einer Konvention, die sich erst noch durchsetzen oder eben nicht durchsetzen muss.

Eine ähnliche Ausgangslage gab es historisch schon einmal, wenn auch mit anderer Zielgruppe. Auch die XML-Sitemap begann 2005 als reine Google-Initiative, bevor sich Yahoo und Microsoft ein Jahr später dem gemeinsamen Protokoll anschlossen und daraus ein von mehreren Suchmaschinen getragener Standard wurde. llms.txt steht heute an einem vergleichbaren Punkt: eine einzelne, gut begründete Initiative, die erst zum Standard wird, wenn mehrere große Plattformen sie unabhängig voneinander unterstützen. Ob das passiert, ist offen, und der Vergleich mit der Sitemap ist kein Versprechen, sondern lediglich eine Einordnung, wie solche Konventionen historisch entstehen können.

Aufbau und Syntax einer llms.txt-Datei

Der Aufbau ist bewusst simpel gehalten und orientiert sich an gewöhnlichem Markdown. Ganz oben steht eine H1-Überschrift mit dem Namen der Website oder des Projekts, darunter ein kurzer Blockquote-Absatz mit einer prägnanten Beschreibung, wofür die Seite steht. Danach folgen H2-Abschnitte, die thematische Gruppen von Links bündeln, etwa „Dokumentation“, „API-Referenz“ oder „Leitfäden“. Jeder Link wird als Markdown-Listenpunkt mit kurzer Erläuterung dargestellt, damit ein Modell ohne weiteren Klick einschätzen kann, ob sich das Laden dieser Unterseite lohnt.

Ein häufig genutztes Element ist ein abschließender Abschnitt mit der Überschrift „Optional“, in dem weniger zentrale, aber dennoch relevante Seiten aufgeführt werden – etwa Änderungsprotokolle oder ältere Versionshinweise. Diese Trennung erlaubt es einem Modell mit engem Kontextbudget, zuerst die als wichtig markierten Links zu laden und den optionalen Teil zu ignorieren, wenn der Platz nicht reicht.

Die verbreitete Erweiterung llms-full.txt unterscheidet sich vom Grundformat dadurch, dass sie nicht auf Seiten verweist, sondern deren Inhalt direkt in die Datei kopiert – praktisch eine Aneinanderreihung der wichtigsten Textinhalte in einer einzigen, langen Markdown-Datei. Für eine kleine SDK-Dokumentation ist das machbar; für eine umfangreiche Website mit tausenden Artikeln sprengt diese Variante schnell jedes vernünftige Kontextbudget und widerspricht damit dem eigentlichen Zweck des Formats.

Ein konkretes Beispiel macht den Unterschied greifbar. Angenommen, ein Softwareprojekt namens Beispiel-SDK möchte eine llms.txt bereitstellen. Die Datei beginnt mit der Überschrift Beispiel-SDK, gefolgt von einem einzeiligen Zitat wie „Eine Programmierschnittstelle für Zahlungsabwicklung in Webanwendungen.“ Darunter steht ein Abschnitt mit der Überschrift Dokumentation, der auf die Einstiegsseite mit dem Hinweis „Installation und erste Schritte“ verweist, auf die API-Referenz mit dem Hinweis „Vollständige Liste aller Endpunkte und Parameter“ und auf einen Abschnitt zu Fehlercodes mit der Erläuterung „Bedeutung aller zurückgegebenen Statuscodes“. Ein zweiter Abschnitt mit der Überschrift Optional listet zusätzlich das Änderungsprotokoll und eine Migrationsanleitung für ältere Versionen auf.

Diese Struktur zeigt den eigentlichen Wert des Formats: Ein Sprachmodell, das um Hilfe bei einem Integrationsfehler gebeten wird, muss nicht raten, welche von zwanzig Unterseiten relevant ist. Es bekommt drei bis fünf klar benannte Einstiegspunkte statt einer kompletten Sitemap mit hunderten URLs, von denen die meisten für die konkrete Frage irrelevant sind. Genau dieser Unterschied – Auswahl statt Vollständigkeit – ist der Kern dessen, was llms.txt von einer Sitemap unterscheidet, nicht nur das Dateiformat.

• Pflichtelement laut Vorschlag ist nur der H1-Titel; üblich sind zusätzlich eine kurze Blockquote-Beschreibung und mindestens eine Liste mit Links
• Format: reiner Markdown-Text, UTF-8, keine Bilder oder eingebetteten Skripte
• Speicherort: im Wurzelverzeichnis unter /llms.txt, optional laut Vorschlag auch in einem Unterpfad
• Erweiterung: llms-full.txt für den vollständig ausgeschriebenen Inhalt statt nur Links, für Projekte mit kompakter Dokumentation

Welche Systeme lesen llms.txt tatsächlich?

Hier liegt der entscheidende Unterschied zwischen Anspruch und öffentlich belegtem Verhalten. Keiner der großen Anbieter von KI-Crawlern – weder OpenAI mit GPTBot, noch Anthropic mit ClaudeBot, noch Google mit dem Steuerungstoken Google-Extended oder Perplexity mit PerplexityBot – dokumentiert in seinen öffentlichen Crawler-Richtlinien, dass llms.txt gelesen, ausgewertet oder bei der Indexierung berücksichtigt wird. Diese Dokumentationen beschreiben durchweg die Einhaltung von robots.txt und die jeweiligen User-Agent-Bezeichner, aber llms.txt taucht in keiner davon auf.

Adoption findet aktuell auf einer anderen Ebene statt: bei Anbietern von Entwickler-Dokumentation. Mehrere Dokumentationsplattformen für Software-Projekte bieten inzwischen an, aus vorhandenen Docs automatisch eine llms.txt zu erzeugen. Der Anwendungsfall dahinter ist aber kein autonomer Crawler, der das Web durchsucht, sondern ein Mensch, der einen Link in ein Chat-Interface wie ChatGPT, Claude oder einen KI-gestützten Code-Editor einfügt, damit das Modell gezielt die Projekt-Dokumentation als Kontext bekommt. Das ist ein reales, nützliches Szenario – aber ein anderes als „meine Seite wird besser in KI-Antworten gefunden“, weil hier ein Mensch die Datei aktiv referenziert, statt dass sie automatisiert entdeckt wird.

Der Unterschied ist wichtig, weil er zwei völlig verschiedene Versprechen auseinanderhält. Das eine Versprechen – bessere Sichtbarkeit in autonomen KI-Suchantworten, etwa in Perplexity-Ergebnissen oder KI-Übersichten – ist durch öffentliche Dokumentation nicht belegt. Das andere – eine handliche Referenz, die ein Entwickler manuell in ein Sprachmodell einspeist – funktioniert bereits heute, weil hier keine automatische Erkennung nötig ist, sondern nur eine gut formatierte Datei, auf die verlinkt wird.

Wer das selbst nachprüfen will, muss nicht raten: Jeder der genannten Anbieter veröffentlicht eine Seite mit seinen Crawler-Richtlinien und dem zugehörigen User-Agent-Namen. Eine Suche nach „GPTBot robots.txt“, „ClaudeBot crawler“ oder „Google-Extended“ führt direkt zu diesen Dokumentationen. Solange dort llms.txt nicht als ausgewertete Datei auftaucht, ist die realistische Annahme, dass der jeweilige Crawler sie nicht einbezieht – unabhängig davon, was einzelne Blogbeiträge oder Marketingtexte dazu behaupten.

llms.txt im Vergleich zu robots.txt

robots.txt ist eine Zugriffssteuerung. Die Datei existiert seit 1994 als informelle Konvention und wurde 2022 mit RFC 9309 offiziell durch die IETF standardisiert. Sie enthält Regeln für bestimmte User-Agents – etwa „Disallow: /intern/“ – und legt fest, welche Pfade ein konformer Crawler besuchen darf und welche nicht. Alle relevanten KI-Crawler, deren Betreiber sich öffentlich zur Einhaltung von robots.txt bekennen, respektieren diese Regeln, weil ein Verstoß dagegen als aggressives, nicht konformes Crawling gilt.

llms.txt hat keine dieser Eigenschaften. Es gibt keine Syntax für Erlauben oder Verbieten, keine User-Agent-Zuordnung und keinen Mechanismus, der irgendetwas erzwingt. Selbst wenn ein Bot die Datei laden würde, verpflichtet ihn nichts, die aufgeführten Links auch tatsächlich zu besuchen oder sie zu bevorzugen. robots.txt sagt „du darfst hierhin, dort nicht“, llms.txt sagt bestenfalls „falls es dich interessiert, hier wäre eine sinnvolle Leseliste“ – ein Vorschlag ohne Durchsetzungsmechanismus, keine Regel.

llms.txt im Vergleich zur XML-Sitemap

Die XML-Sitemap folgt dem 2005 von Google eingeführten und seither von den großen Suchmaschinen gemeinsam getragenen Sitemap-Protokoll. Sie listet vollständig und maschinenlesbar alle indexierbaren URLs einer Website auf, ergänzt um Metadaten wie das letzte Änderungsdatum. Ihr Zweck ist Vollständigkeit: Eine Suchmaschine soll aus der Sitemap jede Seite erfahren können, die zur Indexierung vorgesehen ist, auch solche, die intern nur schwach verlinkt sind.

llms.txt verfolgt das Gegenteil: Kuration statt Vollständigkeit. Die Datei soll bewusst nicht jede URL enthalten, sondern nur die Seiten, die für das Verständnis eines Projekts wirklich zentral sind. Sie ist reiner Markdown-Text statt strukturiertem XML, es gibt kein Einreichungsverfahren wie die Google Search Console, und es existiert keine bestätigte Verarbeitungspipeline auf der empfangenden Seite. Eine Sitemap sagt „hier ist alles, maschinenlesbar, zur Indexierung“. llms.txt sagt „hier ist das Wichtigste, lesbar aufbereitet, zur Einordnung“ – zwei unterschiedliche Aufgaben, die sich nicht gegenseitig ersetzen.

Typische Fehler bei der Umsetzung

Wer eine llms.txt einführt, wiederholt meist einen von drei vermeidbaren Fehlern:

• Automatisch generierte Massenlisten: Ein Skript exportiert alle URLs aus der Sitemap in die llms.txt und zerstört damit die Kuration, die den eigentlichen Zweck der Datei ausmacht
• Verweise auf geschützte Inhalte: Links zu Seiten hinter einer Paywall oder einem Login führen ins Leere, weil kein Bot und kein Modell sich anmelden kann
• Verwechslung mit einer Crawl-Steuerung: eine in der llms.txt fehlende Seite ist dadurch nicht vor KI-Crawlern geschützt, denn die Datei hat keine Sperrwirkung

Der dritte Punkt ist der folgenreichste, weil er zu einem falschen Sicherheitsgefühl führt. Eine Seite, die in der llms.txt fehlt, aber nicht in robots.txt gesperrt ist, bleibt für jeden konformen Crawler regulär erreichbar – die Abwesenheit in der einen Datei hat keine Auswirkung auf die andere. Schutz vor unerwünschtem Crawling ist und bleibt ausschließlich Aufgabe von robots.txt, niemals der llms.txt.

Lohnt sich die Pflege einer llms.txt-Datei?

Der Aufwand ist gering: eine einzelne statische Markdown-Datei, die sich ohne Build-Pipeline von Hand oder mit einem einfachen Skript aus vorhandenen Inhaltsverzeichnissen erzeugen lässt. Es gibt keine Einreichung, keine Wartepflicht und kein Risiko, dass eine fehlerhafte Datei etwas blockiert – im schlimmsten Fall wird sie schlicht ignoriert.

Der Nutzen ist dagegen aktuell nicht belegt, jedenfalls nicht für das Ziel, in autonomen KI-Antworten sichtbarer zu werden. Was nachweislich beeinflusst, ob eine Seite in KI-generierten Antworten zitiert wird, sind bekannte Mechanismen: ob die relevanten Crawler laut robots.txt überhaupt zugelassen sind, ob der HTML-Inhalt ohne aufwendiges JavaScript-Rendering lesbar ist, ob die Seite an anderer Stelle im Web verlinkt und zitiert wird, und die üblichen inhaltlichen Qualitätsfaktoren klassischer SEO. Für keinen dieser Mechanismen ist llms.txt bislang als wirksamer Zusatzfaktor dokumentiert.

Eine Randbedingung, die dabei oft übersehen wird, ist Mehrsprachigkeit. Betreibt eine Website mehrere Sprachversionen, stellt sich die Frage, ob es eine gemeinsame llms.txt für alle Sprachen geben soll oder eine je Sprachversion. Da der Vorschlag selbst dazu keine Vorgabe macht und die Datei primär im Wurzelverzeichnis vorsieht und Unterpfade nur als Option erwähnt, gibt es dafür keine etablierte Konvention – mehrsprachige Projekte müssen sich also entscheiden, ob sie mischen, nur die Hauptsprache abbilden oder auf das Format verzichten, bis eine bessere Konvention für diesen Fall entsteht.

Sinnvoll wird die Datei dort, wo der beschriebene Anwendungsfall tatsächlich zutrifft: Dokumentations-Websites, SDKs, APIs und Entwickler-Tools, deren Nutzer regelmäßig einen Link in ChatGPT, Claude oder einen KI-Code-Assistenten einfügen, um Hilfe zu bekommen. Dort ersetzt eine gepflegte llms.txt tatsächlich stundenlanges Copy-Paste einzelner Dokumentationsseiten. Für eine normale Marketing- oder Content-Website ohne diesen Nutzungskontext trifft dieses Szenario in der Praxis kaum ein – die Datei würde geschrieben, aber es gäbe aktuell niemanden, der sie systematisch liest.

Praktische Hinweise, falls du sie trotzdem einsetzt

Wer sich trotz der unsicheren Wirkung für eine llms.txt entscheidet, sollte einige Grundregeln beachten, damit die Datei zumindest keinen Schaden anrichtet und für den beschriebenen Nutzungsfall tatsächlich brauchbar bleibt:

• Aktuell halten: veraltete Links in der Datei sind schlechter als gar keine Datei, weil sie ein Modell aktiv in die Irre führen
• Kuratieren statt kopieren: die eigene Sitemap nicht einfach in llms.txt duplizieren, sondern wirklich nur die zentralen Seiten aufnehmen
• llms-full.txt nur bei kompaktem Inhalt einsetzen, nicht bei umfangreichen Wissensdatenbanken
• Keine Rankingerwartung verknüpfen: die Datei hat keinen bekannten Effekt auf klassische Suchrankings, ihr Wirkungsbereich bleibt, falls überhaupt vorhanden, auf den KI-Kontext begrenzt
• Die Entwicklung beobachten: sollte ein großer KI-Anbieter offiziell dokumentieren, dass sein Crawler llms.txt auswertet, ändert sich die Kosten-Nutzen-Abwägung grundlegend

Die Datei ist damit weder ein Muss noch ein Fehler, den man vermeiden sollte – sie ist ein Vorschlag mit einem klar umrissenen, heute schon funktionierenden Nutzen für Entwickler-Dokumentation und einem bislang unbelegten, möglichen Zusatznutzen für die Zukunft. Wer das unterscheidet, trifft die Entscheidung ohne falsche Erwartungen.