--- title: llms.txt in der Praxis: Was wirklich reingehört author: Lars Decker date: 2026-09-01 updated: 2026-09-01 description: llms.txt in der Praxis: Aufbau nach Spezifikation, eigene Umsetzung, Googles offizielle Haltung und Cloudflares Ansatz – plus was wirklich reingehört. tags: seo, geo, llms.txt, ki, content-strategie canonical: https://lars-decker.eu/blog/llms-txt-in-der-praxis --- # llms.txt in der Praxis: Was wirklich reingehört _Ich habe meiner eigenen Seite vor einiger Zeit eine llms.txt spendiert. Der Aufwand war klein. Die interessante Frage kam erst danach: Bringt das überhaupt etwas – und wem eigentlich?_ Ich habe [an anderer Stelle](/blog/seo-ist-nicht-mehr-genug-geo) schon beschrieben, warum klassische SEO allein nicht mehr reicht und Inhalte auch für generative Systeme anschlussfähig sein müssen. llms.txt taucht in dieser Debatte ständig auf, meist mit großen Versprechen. Ich wollte es nicht nur beschreiben, sondern selbst bauen und dann nachschauen, was Google und Cloudflare – zwei der Parteien, die es am meisten betrifft – tatsächlich dazu sagen. Die Antworten waren nüchterner, als die meisten Anleitungen zum Thema vermuten lassen. --- ## Was llms.txt eigentlich ist Die Idee stammt von Jeremy Howard (Answer.AI) und wurde im September 2024 unter [llmstxt.org](https://llmstxt.org/) veröffentlicht. Der Aufbau ist bewusst simpel: eine Markdown-Datei unter `/llms.txt`, mit einer H1-Überschrift, einem kurzen Blockquote als Zusammenfassung, optionalem Fließtext, und darunter H2-Abschnitte mit Linklisten im Format `[Name](URL): Beschreibung`. Für größere Seiten gibt es optional eine `/llms-full.txt` mit vollständigen Inhalten für Systeme mit großem Kontextfenster. Wichtig ist die Abgrenzung zu zwei Dateien, die es schon lange gibt: - **robots.txt** regelt, ob ein Crawler eine Seite überhaupt abrufen darf. Zugangskontrolle, keine Kuratierung. - **sitemap.xml** listet alle indexierbaren Seiten vollständig auf. Vollständigkeit statt Auswahl, für Maschinen kaum lesbar aufbereitet. - **llms.txt** soll dagegen eine kuratierte, von einem Menschen priorisierte Einstiegsseite für ein System zum Zeitpunkt der Anfrage sein – keine Liste von allem, sondern eine Auswahl von dem, was wirklich zählt. ## Wie ich meine eigene llms.txt gebaut habe Ich hätte die Datei von Hand schreiben können. Habe ich bewusst nicht gemacht, aus einem einfachen Grund: Eine handgepflegte Datei veraltet garantiert, sobald ich einen neuen Artikel veröffentliche und vergesse, sie nachzuziehen. Also generiere ich sie dynamisch bei jeder Anfrage aus denselben Daten, aus denen auch Blog und Skills-Übersicht gespeist werden: ```text # Lars Decker > [Kurzbeschreibung meiner Seite] Autor: Lars Decker (…/about). Sprache: Deutsch. ## Seiten - Startseite, Über mich, Kontakt, Blog-Übersicht, Skills-Übersicht ## Agent Skills - Jeder veröffentlichte Skill mit Tagline, Lizenz, Version ## Blogartikel - Jeder Artikel mit Titel, Zusammenfassung, Veröffentlichungs- und Aktualisierungsdatum ## Feeds - RSS, Atom, JSON Feed, Sitemap ``` Drei Entscheidungen daraus würde ich auch für andere Seiten empfehlen: 1. **Zusammenfassung statt Volltext.** Jeder Artikel bekommt seine SEO-Description oder das Excerpt, nicht den kompletten Inhalt. Wer mehr braucht, folgt dem Link. 2. **Frische sichtbar machen.** Veröffentlichungs- und Aktualisierungsdatum stehen direkt dabei, damit ein System einschätzen kann, wie aktuell eine Aussage noch ist. 3. **Dynamisch statt statisch.** Die Datei entsteht aus denselben Quelldaten wie die Seite selbst. Sie kann nicht veralten, weil es keine zweite, separat gepflegte Wahrheit gibt. Was bewusst **nicht** reingehört: paginierte Archivseiten, Login- oder Session-Routen, Weiterleitungen, und generell alles, was schon in der Sitemap steht, aber für eine Auswahl zu unwichtig ist. Eine llms.txt, die einfach die Sitemap dupliziert, hat den Kern der Idee verfehlt. Ein technischer Stolperstein, den ich im [GEO-Audit-Skill](/skills/geo-audit) wiedergefunden habe, den ich für genau solche Prüfungen gebaut habe: Bei vielen Single-Page-Apps liefert `/llms.txt` serverseitig einfach die normale HTML-Shell mit Status 200 aus, weil keine eigene Route existiert. Die Datei sieht dann für den Server vorhanden aus, ist es inhaltlich aber nicht. --- ## Was Google dazu sagt – und das ist eindeutig Ich hätte erwartet, dass sich Google zu diesem Thema bedeckt hält. Tut es nicht. **Gary Illyes** sagte bei einem Google Search Central Deep Dive im Juli 2025 unmissverständlich, dass Google llms.txt "nicht unterstützt und das auch nicht plant", und dass die Datei nicht gecrawlt wird. Für Sichtbarkeit in AI Overviews empfiehlt er schlicht: normale SEO-Praxis. **John Mueller** hat das seitdem mehrfach bestätigt. Auf Bluesky wurde er im Januar 2026 gefragt, ob llms.txt-Dateien auf Googles eigenen Entwickler-Doku-Seiten eine Art Empfehlung seien. Seine Antwort: "Ich bin versucht, etwas Bissiges zu sagen, weil das schon so oft aufkam, aber um es direkt zu sagen: nein." Kurz darauf tauchte am 3. Dezember 2025 tatsächlich kurzzeitig eine llms.txt in Googles eigenen Dev-Docs auf – und verschwand noch am selben Tag wieder, während Mueller erneut klarstellte, dass das keine offizielle Unterstützung bedeutet. Im Juni 2026 wurde Mueller noch deutlicher und nannte llms.txt "rein spekulativ, zumindest im Moment" – die Datei existiere seit Jahren, ohne dass irgendein KI-System sie tatsächlich nutze. Bemerkenswert fand ich seine Ergänzung: Er bevorzuge Ansätze wie **WebMCP**, bei denen Agenten klare Ziele und Prozesse angeboten werden, gegenüber einer statischen Datei. Dazu [schreibe ich gerade einen eigenen Artikel](/blog/webmcp-erklaert), weil ich den Gedanken für den eigentlich spannenden Teil der ganzen Debatte halte. Sein pragmatischer Nachsatz war trotzdem fair: Wenn eine AI-Plattform, die einem tatsächlich Kunden bringt, ausdrücklich nach der Datei fragt, spricht nichts dagegen, sie anzulegen. Nur eben ohne die Erwartung eines Rankingeffekts. ## Was Cloudflare dazu sagt – differenzierter, als es zunächst klingt Cloudflare wird oft als Gegenposition zu Google zitiert, weil ein Blogbeitrag vom September 2025 ("An AI Index for all our customers") llms.txt als "aufkommenden offenen Standard" bezeichnet, der Sprachmodellen eine maschinenlesbare Karte der eigenen Seite liefert. Cloudflare pflegt selbst llms.txt- und llms-full.txt-Dateien für seine Entwickler-Doku. Schaut man sich aber an, wo Cloudflare tatsächlich investiert, verschiebt sich das Bild: - **Managed robots.txt für KI-Crawler** (Juli 2025) generiert und aktualisiert robots.txt automatisch, um Trainings-Crawler zu blockieren, ohne die SEO-Sichtbarkeit zu gefährden. Zum Start hatten nur 7,8 % der großen Domains GPTBot explizit blockiert, ClaudeBot lag bei rund 18,8 %. - **Content Signals Policy** ergänzt robots.txt um maschinenlesbare Richtungsangaben, die zwischen Suche, KI-Training und KI-Antworten unterscheiden. - **Pay per Crawl** (2025 gestartet, seit Juli 2026 Richtung "Pay per Answer" weiterentwickelt) lässt Seitenbetreiber KI-Crawler per HTTP-402-Antwort direkt bezahlen lassen, statt Zugang komplett zu verweigern. Seit dem 15. September 2026 blockiert Cloudflares Standardeinstellung zusätzlich "Mixed-Use"-Crawler auf werbefinanzierten Seiten. Der eigentliche Cloudflare-Hebel ist also **Zugangskontrolle und Monetarisierung von Crawlern**, nicht llms.txt. Die Datei wird als ein netter, kostengünstiger Baustein unter mehreren behandelt – nicht als die Lösung, als die sie in vielen SEO-Blogposts verkauft wird. --- ## Was die Daten zur Wirkung sagen SE Ranking hat das 2026 an rund 300.000 Domains geprüft: Nur etwa 10 % haben überhaupt eine llms.txt. Die eigentlich interessante Zahl kam aus einem Prognosemodell (XGBoost) über einen Teildatensatz von rund 39.000 Domains: Ob eine Domain zitiert wurde, ließ sich statistisch nicht mit dem Vorhandensein einer llms.txt in Verbindung bringen. Entfernte man das Merkmal aus dem Modell, wurde die Vorhersage sogar minimal genauer – ein Hinweis darauf, dass es sich um Rauschen handelt, nicht um ein Signal. Das deckt sich mit dem naheliegenden technischen Argument: Ein normales Chat-Sprachmodell antwortet aus seinen beim Training gelernten Gewichten. Es ruft bei einer Anfrage keine externe Datei ab. Nur Systeme mit echter Websuche oder Retrieval zur Laufzeit – ChatGPT mit Browsing, Perplexity, Googles AI Overviews – könnten eine llms.txt überhaupt live abrufen. Und ausgerechnet Google hat bestätigt, das nicht zu tun. Der Bereich, in dem ich tatsächlich einen echten Nutzen sehe, ist ein anderer: **Coding-Assistenten**. Cursor, GitHub Copilot oder Claude Code rufen die llms.txt von Dokumentationsseiten aktiv ab, um Token zu sparen und präziser zu recherchieren, statt die komplette Doku zu durchsuchen. Das ist eine Entwickler-Zielgruppe, keine Endnutzer-Suche – aber dort funktioniert das Prinzip tatsächlich so, wie es gedacht war. --- ## Mein pragmatisches Fazit llms.txt kostet fast nichts und schadet nicht. Deshalb würde ich niemandem abraten, eine anzulegen – aber mit realistischen Erwartungen: - **Tu es, wenn es nichts kostet.** Bei mir läuft die Generierung automatisch mit, ohne zusätzliche Pflege. Genau so würde ich es empfehlen: als Nebenprodukt vorhandener Daten, nie als eigenständiges Pflegeprojekt. - **Erwarte keinen Rankingeffekt.** Weder Google noch die verfügbaren Daten stützen das. Wer llms.txt als GEO-Strategie verkauft, verkauft ein Versprechen ohne Beleg. - **Investiere die eigentliche Energie woanders.** Zugang für Retrieval-Crawler nicht versehentlich blockieren, Entitäten sauber über strukturierte Daten ausweisen, Inhalte so schreiben, dass einzelne Absätze isoliert zitierfähig sind – das sind die Hebel, die nachweislich wirken. - **Für Doku-Seiten mit technischer Zielgruppe lohnt es sich stärker**, weil Coding-Agenten die Datei tatsächlich aktiv nutzen. Der spannendere Teil der Debatte fängt für mich genau dort an, wo Mueller seine Bemerkung fallen ließ: Statt einer statischen Datei, die ein System vielleicht liest, Agenten direkt Ziele und ausführbare Funktionen anzubieten. Genau darum geht es bei WebMCP – und das ist tatsächlich ein Standard, bei dem sich noch etwas Grundlegendes verschieben könnte.