llms.txt erstellen: Aufbau, Beispiel und was der Standard wirklich bringt

Seit KI-Systeme Webinhalte als Antwortgrundlage nutzen, stellt sich eine alte Frage neu: In welcher Form soll eine Website Maschinen erklären, was auf ihr zu finden ist? Die Antwort der Suchmaschinen-Ära bestand aus zwei Dateien. Die robots.txt regelt, was ein Crawler abrufen darf; die XML-Sitemap listet, welche Adressen es gibt. Beide sagen nichts darüber, welche Inhalte inhaltlich zusammengehören, welche zentral sind und welche man getrost überspringen kann.

Genau in diese Lücke zielt llms.txt. Der Vorschlag stammt von Jeremy Howard, Mitgründer von Answer.AI, und wurde im September 2024 veröffentlicht. Er ist bewusst klein gehalten: eine einzige Markdown-Datei im Wurzelverzeichnis, die in wenigen Zeilen beschreibt, worum es auf der Website geht, und danach kuratierte Linklisten anbietet. Kein Protokoll, keine Registrierung, keine Prüfstelle – ein Textformat, mehr nicht. Diese Bescheidenheit ist die eigentliche Stärke des Vorschlags und zugleich die Quelle fast aller Missverständnisse darüber.

Was llms.txt ist – und was sie ausdrücklich nicht ist

Eine llms.txt ist eine Markdown-Datei, die unter der festen Adresse /llms.txt im Wurzelverzeichnis einer Domain liegt. Sie enthält den Namen der Marke oder des Projekts, eine kurze Selbstbeschreibung und danach thematisch gruppierte Listen von Links – jeweils mit einem Halbsatz, was hinter dem Link steht. Die Kurzdefinition von llms.txt fasst das Format in wenigen Zeilen zusammen; hier geht es um die Umsetzung.

Der Zweck ist eng gefasst. Sprachmodelle arbeiten mit einem begrenzten Kontextfenster – der Menge an Text, die sie pro Anfrage verarbeiten können. Eine mittelgroße Website übersteigt dieses Fenster um ein Vielfaches. Die Datei bietet deshalb einen kuratierten Einstieg an: Statt eine Website vollständig zu durchsuchen, kann ein System zuerst lesen, was der Betreiber selbst für zentral hält.

Wichtiger als das, was die Datei ist, ist in der Praxis das, was sie nicht ist. Vier Verwechslungen halten sich hartnäckig.

1. Kein Ersatz für die robots.txt. Die robots.txt regelt Zugriff – ob ein Crawler eine Ressource überhaupt abrufen darf. Sie hat seit 2022 mit RFC 9309 eine formale Spezifikation und wird von den großen Anbietern befolgt. Die llms.txt regelt nichts. Sie ist ein Angebot, keine Anweisung. Wer steuern will, welche Systeme Inhalte lesen dürfen, tut das weiterhin ausschließlich in der robots.txt.
2. Kein Ersatz für die Sitemap. Eine XML-Sitemap zielt auf Vollständigkeit: Sie listet möglichst alle indexierbaren Adressen mit technischen Metadaten. Die llms.txt zielt auf das Gegenteil – auf Auswahl. Sie ist erst dann nützlich, wenn sie deutlich weniger enthält als die Sitemap.
3. Keine Garantie auf Zitierung. Kein Anbieter hat öffentlich zugesagt, die Datei als Auswahl- oder Rankingsignal zu behandeln. Google formuliert in der Search-Central-Dokumentation zu KI-Funktionen sogar ausdrücklich, dass für AI Overviews und den AI Mode keine zusätzliche Auszeichnung und keine speziellen KI-Textdateien erforderlich seien.
4. Kein Zugriffsschutz. Wer verhindern will, dass Inhalte in Trainingsdaten oder Live-Abrufe gelangen, erreicht das über Crawler-Direktiven, nicht über eine Linkliste. Welche Bots man zulässt und welche nicht, ist eine eigene Entscheidung – sie gehört in eine bewusste AI-Crawler-Strategie und nicht in eine Markdown-Datei.

Die Unterschiede lassen sich nebeneinander am schnellsten erfassen:

Das Problem, das die Datei lösen soll

HTML ist für Maschinen teuer. Eine Seite mit 900 Wörtern Fließtext transportiert im Quelltext leicht ein Vielfaches an Zeichen: Navigation, Consent-Banner, Skripte, Tracking-Container, Layout-Container ohne Inhalt. Wer daraus verwertbaren Text extrahieren will, muss entscheiden, welcher Teil der Seite die Antwort enthält – und entscheidet gelegentlich falsch.

Dazu kommt: Es gibt zwei grundverschiedene Wege, auf denen Inhalte in eine KI-Antwort gelangen. Entweder sie waren beim Training des Modells im Datenbestand, oder sie werden zum Zeitpunkt der Frage live abgerufen und in die Antwort eingespeist – ein Verfahren, das als Retrieval-Augmented Generation bezeichnet wird. Für den zweiten Weg zählt, wie schnell und wie verlustfrei aus einer Adresse verwertbarer Text wird. Genau dort setzt der Vorschlag an.

Die Datei macht daher zwei Angebote: eine kompakte Selbstbeschreibung, die ohne Interpretation auskommt, und eine kuratierte Auswahl von Adressen mit einer Notiz, was dort zu finden ist. Beides ist Text, den ein System nicht erst aus einem Seitengerüst herauslösen muss.

Damit ist zugleich die Grenze markiert: Gelöst wird ein Effizienzproblem, kein Relevanzproblem. Ein System, das die Datei nicht abruft, profitiert nicht. Und eine Datei, die auf dünne Inhalte zeigt, macht dünne Inhalte nicht besser – sie beschleunigt nur, wie schnell erkennbar wird, dass wenig dahintersteht.

Der Aufbau im Detail

Der Vorschlag beschreibt eine feste Reihenfolge, von der nur ein einziges Element verpflichtend ist. Alles Weitere ist optional, wird aber in der Praxis fast immer verwendet.

1. H1 mit dem Namen – das einzige Pflichtelement

Die Datei beginnt mit einer Markdown-Überschrift erster Ordnung, die den Namen des Projekts oder der Marke trägt. Entscheidend ist die Schreibweise: exakt so, wie der Name auf der Website, im Impressum, in Verzeichnissen und in Fachpublikationen geschrieben wird, inklusive Rechtsform, wenn diese Teil der geführten Marke ist. Uneinheitliche Schreibweisen sind einer der häufigsten Gründe, warum eine Marke von KI-Systemen als zwei getrennte Entitäten behandelt wird und ihre Nennungen sich nicht addieren.

2. Blockquote: die Kurzbeschreibung

Darunter folgt ein Markdown-Zitatblock mit ein bis drei Sätzen. Das ist der wichtigste Abschnitt der gesamten Datei, weil er die Frage beantwortet, die jedes System zuerst stellt: Was ist das hier, für wen, und womit. Prüfbare Angaben wiegen an dieser Stelle mehr als Adjektive – Fertigungsverfahren, Losgrößen, Normen und Standorte statt „führend“ und „innovativ“. Welche Signale bei der Quellenauswahl generell zählen, behandelt der Guide zur Sichtbarkeit in KI-Antworten ausführlicher.

3. Optionale Absätze für Betriebshinweise

Zwischen Kurzbeschreibung und Linklisten dürfen freie Markdown-Absätze stehen. Sie sind der richtige Ort für Hinweise, die sonst nirgends hingehören: welche Sprachfassungen existieren, ob Preise öffentlich sind, welcher Bereich sich an Fachpublikum richtet, wie aktuell der Stand ist.

4. H2-Abschnitte mit Linklisten

Danach folgen beliebig viele Abschnitte mit einer Überschrift zweiter Ordnung und je einer Markdown-Liste. Jeder Eintrag besteht aus einem Link – eckige Klammern für den Namen, runde Klammern für die Adresse – und danach optional einem Doppelpunkt mit einer Notiz. Diese Notiz ist keine Werbezeile, sondern eine Inhaltsangabe: dieselbe Disziplin, die auch bei interner Verlinkung gilt, wo der beschreibende Text sagt, was am Ziel steht, nicht wie gut es ist.

Für die Gruppierung gilt eine einfache Regel: nach Fragetypen sortieren, nicht nach der Struktur des Content-Management-Systems. Wie das System die Inhalte intern ablegt, interessiert außerhalb der Redaktion niemanden. Relevant ist, welche Abschnitte jemand braucht, der eine Produktfrage hat, und welche jemand braucht, der wissen will, mit wem er es zu tun hat.

5. Der Abschnitt „Optional“

Eine Besonderheit des Formats: Ein Abschnitt, der wörtlich mit „Optional“ überschrieben ist, hat eine definierte Bedeutung. Er markiert Inhalte, die weggelassen werden dürfen, wenn ein kürzerer Kontext gebraucht wird. Damit setzt der Betreiber selbst eine Priorität, statt sie dem lesenden System zu überlassen. Wer diesen Abschnitt nutzt, sollte ihn ernst meinen und dort tatsächlich nur Nachrangiges einordnen.

Ein vollständiges Beispiel

So sieht eine vollständige Datei für einen mittelständischen Fertigungsbetrieb aus. Die Domain ist fiktiv, die Struktur überträgt sich unverändert auf andere Branchen.

# Norddraht GmbH

> Hersteller von Kabelkonfektionen und Sensorleitungen für den industriellen Maschinenbau. Fertigung in Deutschland, Serienlieferung ab Losgröße 50, Qualitätsmanagement nach IATF 16949.

Alle verlinkten Seiten liegen zusätzlich als Markdown-Fassung vor. Die Inhalte sind auf Deutsch; englische Fassungen liegen unter dem Pfadpräfix /en. Preise werden nicht öffentlich ausgewiesen und auf Anfrage kalkuliert.

## Produkte

- [Kabelkonfektion](https://beispiel.de/produkte/kabelkonfektion.md): Fertigungsverfahren, Toleranzen, Losgrößen und Materialoptionen
- [Sensorleitungen](https://beispiel.de/produkte/sensorleitungen.md): Schirmungsarten, Temperaturbereiche und typische Einsatzfälle
- [Sonderlösungen](https://beispiel.de/produkte/sonderloesungen.md): Ablauf von der Anfrage über den Prototyp bis zur Erstmusterprüfung

## Technische Referenz

- [Materialübersicht](https://beispiel.de/technik/materialien.md): Isolierwerkstoffe mit Temperatur- und Chemikalienbeständigkeit
- [Prüfverfahren](https://beispiel.de/technik/pruefverfahren.md): Serienbegleitende Prüfungen und Dokumentationsumfang
- [Normen und Zertifikate](https://beispiel.de/technik/normen.md): Gültige Zertifizierungen mit Ausstellungs- und Ablaufdatum

## Unternehmen

- [Über uns](https://beispiel.de/unternehmen.md): Gründungsjahr, Standorte, Mitarbeiterzahl, Eigentümerstruktur
- [Kontakt](https://beispiel.de/kontakt.md): Ansprechpartner nach Fachgebiet, Anschrift, Reaktionszeiten

## Optional

- [Pressemitteilungen](https://beispiel.de/presse.md): Meldungen der vergangenen fünf Jahre
- [Karriere](https://beispiel.de/karriere.md): Offene Stellen und Ablauf des Bewerbungsprozesses

Die einzelnen Bestandteile im Durchgang:

1. Die H1. Nur der Name, keine Zusätze wie „Willkommen bei“ und kein Claim. Der Name steht hier in derselben Schreibweise wie im Impressum und in externen Verzeichnissen.
2. Das Blockquote. Drei Bausteine in zwei Sätzen: was das Unternehmen herstellt, für welchen Markt, unter welchen nachprüfbaren Rahmenbedingungen. Die Nennung von Losgröße und Qualitätsnorm ist keine Detailverliebtheit, sondern der Unterschied zwischen einer Beschreibung, die zu einer konkreten Frage passt, und einer, die auf jeden Wettbewerber genauso zutrifft.
3. Der freie Absatz. Er beantwortet drei Betriebsfragen vorab: Gibt es Markdown-Fassungen, welche Sprachen existieren, sind Preise öffentlich. Damit erübrigen sich Abrufe, die ohnehin ins Leere laufen würden.
4. Die Abschnitte. Produkte, Technische Referenz und Unternehmen entsprechen drei verschiedenen Fragetypen – was das Unternehmen kann, wie es das belegt, wer dahintersteht. Ein Abschnitt pro Fragetyp genügt; zehn Abschnitte mit je zwei Links sind ein Gliederungsproblem, kein Kuratierungserfolg.
5. Die Notizen hinter dem Doppelpunkt. Jede benennt konkret, welche Angaben auf der Zielseite stehen. „Alles über unsere Kabelkonfektion“ wäre wertlos; „Fertigungsverfahren, Toleranzen, Losgrößen und Materialoptionen“ erlaubt einem System, die Seite gezielt für eine passende Frage heranzuziehen.
6. Der Abschnitt Optional. Presse und Karriere sind für Produktfragen irrelevant. Sie stehen trotzdem in der Datei, aber ausdrücklich als das, was zuerst wegfallen darf.
7. Die Endung .md. Der Vorschlag empfiehlt, zu jeder Seite zusätzlich eine Markdown-Fassung unter derselben Adresse mit der Endung .md anzubieten. Wer das technisch nicht abbilden kann, verlinkt schlicht die regulären HTML-Adressen – die Datei bleibt gültig und nutzbar.

llms-full.txt und die Frage nach der Vollversion

Neben der llms.txt kursiert eine zweite Datei: die llms-full.txt, die nicht nur auf Inhalte verweist, sondern sie vollständig enthält – die gesamte Dokumentation als ein einziges Markdown-Dokument. Hier lohnt eine saubere Unterscheidung, weil in Ratgebern häufig beides in einen Topf geworfen wird.

Die ursprüngliche Spezifikation beschreibt diese Vollversion nicht als eigenes Format. Sie kennt stattdessen erzeugte Ausgaben, die sich aus einer llms.txt mit einem Hilfswerkzeug generieren lassen und die verlinkten Inhalte einsammeln. Die Bezeichnung llms-full.txt hat sich davon unabhängig als Konvention verbreitet, vor allem bei Anbietern technischer Dokumentation. Sie ist damit üblich, aber nicht normiert – wer sie erwähnt, sollte diesen Unterschied kennen.

Praktisch lohnt sie sich für eine schmale Gruppe: Anbieter mit umfangreicher, ohnehin in Markdown gepflegter Produkt- oder Entwicklerdokumentation, bei denen die Vollversion automatisiert aus derselben Quelle erzeugt wird wie die Website. Für eine Unternehmenswebsite mit vierzig Seiten ist sie überflüssig. Und sie hat ein spezifisches Risiko: Eine große, manuell gepflegte Datei driftet fast zwangsläufig vom Stand der Website ab. Eine Vollversion, die veraltete Preise, abgekündigte Produkte oder alte Zertifikatsstände transportiert, richtet mehr Schaden an als gar keine Datei.

Ausliefern: Ort, Statuscode, Content-Type

Die Datei muss unter genau einer Adresse erreichbar sein: der Domain, gefolgt von /llms.txt. Kein Unterverzeichnis, kein Asset-Ordner, keine Variante mit Bindestrich. Systeme, die die Datei suchen, probieren diesen einen Pfad – und nur diesen.

Technisch sind vier Punkte entscheidend, und alle vier gehen in der Praxis regelmäßig schief. Erstens der Statuscode: Die Adresse muss mit 200 antworten, nicht über eine Weiterleitungskette laufen und nicht auf einer Fehlerseite landen, die aus Bequemlichkeit ebenfalls 200 zurückgibt. Zweitens der Content-Type: text/plain oder text/markdown, kodiert in UTF-8. Wird die Datei als application/octet-stream ausgeliefert, behandeln manche Clients sie als Download statt als Text. Drittens die Zugänglichkeit: nicht per robots.txt gesperrt, nicht hinter einer Anmeldung, nicht hinter einer Bot-Abwehr, die alles ohne Browser-Signatur blockiert. Viertens absolute Adressen in den Linklisten – relative Pfade sind in einer Datei, die außerhalb der Seitenstruktur gelesen wird, wertlos.

Wo die Datei im Projekt abgelegt wird, hängt vom Setup ab: bei statischen Generatoren im öffentlichen Verzeichnis, das unverändert ausgeliefert wird, bei klassischen Content-Management-Systemen entweder direkt im Wurzelverzeichnis oder über eine eigens angelegte Route. Auslieferung, Statuscodes und Crawl-Steuerung sind ohnehin ein Thema für technisches SEO und keine Inhaltsfrage.

Die Prüfung dauert zwei Minuten: die Adresse in einem privaten Browserfenster aufrufen, anschließend Statuscode und Content-Type über ein Kommandozeilenwerkzeug oder die Netzwerkanalyse der Entwicklerwerkzeuge kontrollieren. Wenn im Browser Text erscheint und der Header stimmt, ist der technische Teil erledigt.

Pflege: warum eine veraltete Datei schadet

Eine llms.txt ist eine Behauptung über den Zustand einer Website. Verlinkt sie ein Produkt, das es nicht mehr gibt, oder beschreibt sie ein Leistungsspektrum, das seit dem letzten Relaunch anders zugeschnitten ist, dann liefert sie präzise formulierte Falschinformation – und zwar an genau der Stelle, an der ein System besonders bereitwillig zugreift, weil der Betreiber sie selbst kuratiert hat.

Vier Anlässe machen eine Überarbeitung zwingend: ein Relaunch oder eine Änderung der Adressstruktur, eine Umbenennung von Marke oder Produkten, eine neue Leistungs- oder Produktlinie, und jede Korrektur an den Kernaussagen der Selbstbeschreibung. Zusätzlich empfiehlt sich eine Sichtprüfung im Quartal – im Wesentlichen ein Abgleich, ob alle verlinkten Adressen noch mit 200 antworten. Der Zusammenhang von Crawling und Indexierung erklärt, warum tote Adressen hier schwerer wiegen als in einer Sitemap: Es gibt keinen Mechanismus, der einen Fehler stillschweigend korrigiert.

Wo es geht, sollte die Datei aus derselben Quelle generiert werden, aus der auch die Website entsteht. Jede manuell gepflegte Zweitfassung von Inhalten driftet irgendwann ab – die Frage ist nur, wie lange es niemand bemerkt.

Stand der Adoption: was belegt ist und was nicht

Hier trennt sich, was dokumentiert ist, von dem, was behauptet wird.

Belegt ist die Herkunft: Der Vorschlag ist offen einsehbar, sowohl auf der Projektseite als auch im zugehörigen Repository von Answer.AI. Er ist ein Vorschlag geblieben – kein Ergebnis eines Normungsprozesses bei W3C, IETF oder ISO. Der Unterschied zur robots.txt ist an dieser Stelle greifbar: Diese hat seit 2022 mit RFC 9309 eine formale Spezifikation, die beschreibt, wie Direktiven zu interpretieren, Fehler zu behandeln und Antworten zwischenzuspeichern sind. Für llms.txt existiert nichts Vergleichbares.

Belegt ist auch, wo die Datei am weitesten verbreitet ist: bei Anbietern von Software und technischer Dokumentation. Das ist naheliegend, weil dort die Inhalte ohnehin in Markdown vorliegen und die Zielgruppe – Entwickler, die mit KI-Assistenten arbeiten – die Datei unmittelbar nutzt.

Nicht belegt ist der entscheidende Teil: welche Anbieter die Datei tatsächlich auswerten und mit welchem Gewicht. Öffentliche Zusagen dazu sind rar. Google hält in der Dokumentation zu KI-Funktionen in der Suche ausdrücklich fest, dass es für AI Overviews und den AI Mode keine zusätzlichen technischen Anforderungen und keine speziellen KI-Textdateien gebe – wer llms.txt als Rankingfaktor für Google beschreibt, widerspricht damit der Herstellerdokumentation. Zahlen zur Verbreitung, die in Ratgebern kursieren, stammen fast durchweg aus Stichproben unklarer Methodik. Wer sie zitiert, zitiert eine Momentaufnahme.

Die nüchterne Einordnung lautet deshalb: eine günstige Wette mit geringem Einsatz. Der Aufwand liegt bei einem halben Tag Ersterstellung plus überschaubarer Pflege. Der mögliche Ertrag besteht darin, vorbereitet zu sein, falls und soweit Systeme die Datei nutzen. Dazu kommt ein Nebeneffekt, der unabhängig von jeder Adoption eintritt: Wer gezwungen ist, die eigene Organisation in drei Sätzen ohne Marketingvokabular zu beschreiben und die eigenen Inhalte nach Fragetypen zu sortieren, findet dabei verlässlich Widersprüche und Lücken. Diese Arbeit zahlt auf jede Strategie zur Generative Engine Optimization ein, ob die Datei am Ende gelesen wird oder nicht.

Nicht lohnen wird sich der Aufwand dort, wo die Grundlagen fehlen. Wenn zentrale Seiten nicht indexierbar sind, die Marke im Netz uneinheitlich benannt wird oder die verlinkten Inhalte die versprochenen Fragen gar nicht beantworten, ist die Datei Kosmetik über einem strukturellen Problem.

Wo die Datei in einer GEO-Strategie steht

Generative Engine Optimization besteht aus mehreren Hebeln, die sich in ihrer Wirkung deutlich unterscheiden. Nach dem, was sich über verschiedene Systeme hinweg beobachten lässt, ergibt sich eine ziemlich stabile Rangfolge.

1. Abrufbarkeit. Inhalte müssen für die relevanten Systeme technisch erreichbar sein. Wer Crawler pauschal aussperrt, kann alles Weitere überspringen.
2. Eindeutige Entität. Name, Beschreibung und Zuordnung müssen über alle Quellen hinweg identisch sein. Uneinheitlichkeit teilt eine Marke in mehrere schwache Fragmente.
3. Inhalte, die Fragen abschließend beantworten. Systeme ziehen Passagen, keine Seiten. Ein Abschnitt, der eine Frage vollständig und ohne Rückverweise beantwortet, ist zitierfähiger als ein Text, der über drei Unterseiten verteilt ist.
4. Nennungen außerhalb der eigenen Domain. Was Dritte über eine Marke schreiben, wiegt schwerer als das, was die Marke über sich selbst schreibt. Diese Ebene lässt sich nicht durch Arbeit auf der eigenen Website ersetzen.
5. llms.txt. Eine Erleichterung obendrauf – wirksam nur, wenn die vier Punkte darüber stehen.

Diese Reihenfolge hilft bei der Budgetfrage. Wer die Datei zuerst baut, weil sie die sichtbarste und schnellste Maßnahme ist, arbeitet an Position fünf, während Position eins offen ist. Wo eine konkrete Website in dieser Rangfolge tatsächlich steht, klärt ein GEO Audit verlässlicher als jede Checkliste.

„Eine llms.txt ist ein Inhaltsverzeichnis. Sie verbessert nichts an dem Buch, auf das sie zeigt.“

Häufige Fehler beim Erstellen

Die meisten Dateien, die im Netz stehen, scheitern an denselben sieben Punkten.

1. Die Datei als Werbetext schreiben. Superlative und Claims sind an dieser Stelle nutzlos, weil sie nichts unterscheidbar machen. Prüfbare Angaben ersetzen sie ohne Verlust.
2. Alles verlinken. Eine Datei mit 200 Einträgen ist eine zweite Sitemap in schlechterem Format. Der Wert entsteht durch das Weglassen.
3. Relative Pfade verwenden. Die Datei wird außerhalb des Seitenkontexts gelesen. Ohne vollständige Adresse ist ein Link nicht auflösbar.
4. Am falschen Ort ablegen. Alles außer /llms.txt im Wurzelverzeichnis wird nicht gefunden – auch nicht mit einer Weiterleitung, die man sich sparen kann, indem man die Datei gleich richtig ablegt.
5. Einmal erstellen, nie prüfen. Ohne festen Anlass zur Überarbeitung veraltet die Datei still. Der Relaunch ist der Moment, in dem sie am zuverlässigsten vergessen wird.
6. Widersprüche zur übrigen Kommunikation. Wenn die Selbstbeschreibung in der Datei anders lautet als auf der Über-uns-Seite, im Unternehmensprofil und in Fachverzeichnissen, entsteht kein zusätzliches Signal, sondern ein widersprüchliches.
7. Sie als Rankinghebel verkaufen. Wer die Datei intern mit einer Sichtbarkeitszusage begründet, produziert eine Erwartung, die niemand einlösen kann – und beschädigt die Glaubwürdigkeit der Maßnahmen, die tatsächlich tragen.

Häufige Fragen zu llms.txt

Ist llms.txt ein Ersatz für die robots.txt?

Nein, die beiden Dateien haben verschiedene Aufgaben. Die robots.txt regelt den Zugriff und ist seit 2022 mit RFC 9309 formal spezifiziert; sie entscheidet, ob ein Crawler eine Ressource abrufen darf. Die llms.txt regelt nichts, sondern bietet eine kuratierte Übersicht an. Wer Crawler steuern will, tut das ausschließlich über die robots.txt.

Verbessert eine llms.txt mein Ranking bei Google?

Dafür gibt es keinen Beleg, und Google widerspricht dem in der eigenen Dokumentation. Die Search-Central-Dokumentation zu KI-Funktionen hält ausdrücklich fest, dass für AI Overviews und den AI Mode keine zusätzlichen technischen Anforderungen und keine speziellen KI-Textdateien nötig sind. Die Datei sollte deshalb nicht mit einer Rankingzusage begründet werden.

Wo muss die Datei liegen und wie prüfe ich, ob sie erreichbar ist?

Im Wurzelverzeichnis der Domain, erreichbar unter dem Pfad /llms.txt – ein Unterverzeichnis funktioniert nicht. Die Prüfung dauert zwei Minuten: Adresse in einem privaten Browserfenster aufrufen und kontrollieren, ob Statuscode 200 zurückkommt, der Content-Type text/plain oder text/markdown lautet und die Datei weder per robots.txt gesperrt noch hinter einer Anmeldung liegt.

Brauche ich zusätzlich eine llms-full.txt?

Für die meisten Websites nicht. Eine Vollversion mit sämtlichen Inhalten lohnt sich vor allem bei umfangreicher technischer Dokumentation, die ohnehin in Markdown gepflegt und automatisiert erzeugt wird. Wird sie manuell gepflegt, driftet sie fast zwangsläufig vom Stand der Website ab – und eine veraltete Vollversion schadet mehr, als sie nützt.

Wie oft muss ich die Datei aktualisieren?

Zwingend bei jedem Relaunch, jeder Änderung der Adressstruktur, jeder Umbenennung von Marke oder Produkten und bei jeder Korrektur der Kernaussagen. Darüber hinaus genügt eine Sichtprüfung im Quartal, bei der geprüft wird, ob alle verlinkten Adressen noch erreichbar sind und die Beschreibungen zum tatsächlichen Angebot passen.

Für welche Websites lohnt sich der Aufwand nicht?

Für Websites, bei denen die Grundlagen fehlen. Wenn zentrale Seiten nicht indexierbar sind, die Marke im Netz uneinheitlich benannt wird oder die verlinkten Inhalte die versprochenen Fragen gar nicht beantworten, ist die Datei Kosmetik über einem strukturellen Problem. Dann liegt der Hebel eine Ebene tiefer, nicht in einer zusätzlichen Datei.

Fazit

llms.txt ist ein kleiner, offener Vorschlag mit einem klar umrissenen Zweck: Maschinen einen kuratierten Einstieg in eine Website zu geben, statt sie suchen zu lassen. Der Aufbau ist in einer Stunde verstanden, die Erstellung in einem halben Tag erledigt, die Pflege im Quartal machbar. Was fehlt, ist eine belastbare Auskunft darüber, wer die Datei auswertet und wie stark – und diese Lücke sollte man benennen, statt sie mit Zuversicht zu füllen.

Als Wette ist sie damit günstig: geringer Einsatz, unklarer, aber möglicher Ertrag, kein Risiko außer dem, sie zu vernachlässigen. Als Strategie taugt sie nicht. Wer Sichtbarkeit in KI-Antworten aufbauen will, arbeitet zuerst an Abrufbarkeit, an einer eindeutig benannten Entität, an Inhalten, die Fragen abschließend beantworten, und an Nennungen außerhalb der eigenen Domain. Wenn diese vier Punkte stehen, ist die Datei ein sinnvoller letzter Handgriff. Wenn sie nicht stehen, ist sie ein gut lesbares Inhaltsverzeichnis für ein Buch, das niemand aufschlägt.

Kostenlose Wachstumsanalyse anfragen →