Habe ich mich bei der llms.txt geirrt? Drei Signale, die das Bild verschieben.

Im Februar habe ich die llms.txt zum Rohrkrepierer erklärt. Drei Monate später muss ich präzisieren: Als GEO-Maßnahme bleibt sie tot. Als Discovery-Datei für agentische Systeme könnte sie genau das werden, was Jeremy Howard ursprünglich im Sinn hatte.

Wer meinen Februar-Artikel „Die llms.txt ist tot“ gelesen hat, weiß: Ich habe wenig zimperlich argumentiert. 0,1 Prozent der KI-Bot-Requests in OtterlyAIs 90-Tage-Messung. John Mueller, der die Datei mit dem Keywords-Meta-Tag vergleicht. Vier strukturelle Gründe, warum kein KI-Suchsystem im Retrieval-Stack eine vom Seitenbetreiber kuratierte Inhaltsbeschreibung als vertrauenswürdiges Signal verwenden würde.

An dieser Analyse ändert sich nichts. Wer eine llms.txt erstellt, um besser in ChatGPT, Perplexity oder den Google AI Overviews zu erscheinen, verschwendet weiterhin Zeit. Aber drei Entwicklungen der letzten Wochen zwingen mich, die Frage anders zu stellen.

Signal 1: Google I/O 2026 — Search ist jetzt agentisch

Am 19. Mai hat Liz Reid auf der I/O das vorgestellt, was Google „a new era for AI Search“ nennt. Die nüchterne Übersetzung: Suche ist nicht mehr nur Retrieval. Suche wird Task-Ausführung.

Was Google angekündigt hat, ist in Summe ein Paradigmenwechsel:

• Information Agents, die im Hintergrund 24/7 das Web nach nutzerdefinierten Kriterien beobachten und proaktiv Updates liefern — etwa beim Wohnungssuchen oder bei Sneaker-Drops.
• Agentic Booking für lokale Dienstleistungen: Karaoke-Raum für sechs Personen am Freitagabend mit später Küche? Google sucht Preise und Verfügbarkeit zusammen und führt zur Buchung beim Anbieter. Für Kategorien wie Home Repair, Beauty oder Pet Care ruft Google die Anbieter „on your behalf“ an.
• Agentic Coding direkt in der Suche über Antigravity und Gemini 3.5 Flash — mit generativer UI, die in Echtzeit zusammengebaut wird.
• Mini-Apps in der Suche, die als Custom-Tracker oder Dashboard für wiederkehrende Aufgaben dienen.

Der entscheidende Punkt für unsere Frage: Diese Agenten besuchen Websites, navigieren durch URL-Strukturen, lesen Detailseiten, vergleichen, buchen, rufen an. Sie sind keine klassischen Indexer, die einmalig crawlen und in einem Embedding-Index landen. Sie sind Operatoren, die zur Inferenzzeit auf live Inhalte zugreifen — mit einem konkreten Task im Kontext.

Genau für diesen Anwendungsfall war llms.txt von Anfang an gedacht. Howards Originaltext spricht von „inference-time use cases“ und zielt explizit auf Tools wie Cursor und Claude Code. Was 2024 nach einem Nischen-Use-Case für Coding-Assistenten klang, ist 2026 die Standardoperation jedes Mainstream-Suchanbieters.

Signal 2: Chrome Lighthouse prüft die llms.txt

Am 5. Mai 2026 tauchte in den Chrome-Developer-Docs ein neuer Lighthouse-Audit auf: llms.txt, eingeordnet unter der Rubrik Agentic browsing audits.

Die Formulierung ist vorsichtig. Lighthouse markiert den Audit als „Not Applicable“, wenn die Datei fehlt — „providing the file is optional at the moment“. Geflagged wird nur, wenn der Server bei Abruf einen Fehler liefert. Das ist weit entfernt von einem Ranking-Faktor.

Trotzdem ist die symbolische Bedeutung erheblich. Erstens kommt diese Dokumentation aus dem Hause Google — dem gleichen Konzern, der im Februar via Mueller und Illyes explizit klargestellt hatte, dass keine offizielle Unterstützung geplant sei. Zweitens — und das ist der wichtigere Punkt — wird llms.txt unter „Agentic browsing audits“ einsortiert, nicht unter „SEO audits“. Die Kategorie zählt.

Lighthouse sagt damit: Wenn Agenten deine Seite besuchen, ist eine maschinenlesbare Zusammenfassung dessen, was deine Seite anbietet und wie sie strukturiert ist, ein hilfreicher Baustein. Ohne diese Datei verbringen Agenten mehr Zeit damit, die Seitenstruktur zu rekonstruieren. Das ist eine sehr andere Aussage als „die Datei hilft beim Ranking“.

Signal 3: Eine neue Use-Case-Kategorie wird sichtbar

Im Februar habe ich „publizieren“ und „konsumieren“ als Verwechslung beschrieben: Dass Anthropic, OpenAI und Perplexity llms.txt-Dateien auf ihren Developer-Docs haben, sagt nichts darüber aus, ob ihre Retrieval-Systeme die llms.txt anderer Sites lesen. Das stimmt weiterhin.

Was ich aber unterbelichtet habe: Es gibt einen dritten Modus jenseits von „publizieren für die eigene Sichtbarkeit“ und „konsumieren im Retrieval“.

Es gibt das Szenario, in dem ein Agent — aus welchem Grund auch immer — sich entschieden hat, deine Seite zu besuchen, und nun eine konkrete Aufgabe abarbeiten soll. Der Agent hat dich nicht „gefunden“, weil er deine llms.txt gelesen hat. Er hat dich gefunden, weil ihn der Nutzer dort hingeschickt hat oder weil ein klassisches Retrieval ihn dort hingeführt hat. Aber sobald er da ist, hat er ein Problem: Welche URLs sind die richtigen Einstiegspunkte für seine Aufgabe? Wie sind die Slugs aufgebaut? Welche Aktionen darf er ohne Bestätigung ausführen, welche nicht?

Für dieses Problem ist eine gut gepflegte llms.txt eine plausible Lösung. Nicht als Ranking-Signal. Sondern als Operating Manual.

Was meine ursprüngliche These nicht erfasst hat

Beides kann gleichzeitig wahr sein:

1. llms.txt als GEO-Hebel ist gescheitert und wird scheitern. Die strukturellen Gründe — Manipulationsanfälligkeit, Retrieval-Ineffizienz, Redundanz zur robots.txt, fehlende Adoption auf Consumer-Seite — gelten unverändert.
2. llms.txt als agentische Discovery-Datei ist im aufkommenden Browsing-Stack potenziell nützlich. Hier zählt nicht, ob ein Embedding-Index die Datei einmal pro Quartal crawlt. Hier zählt, ob ein Agent zur Inferenzzeit damit schneller zur richtigen URL kommt.

Diese zwei Anwendungen sind nicht das gleiche Produkt mit zwei Namen. Sie haben unterschiedliche Adressaten, unterschiedliche Erfolgskriterien und unterschiedliche Designprinzipien. Eine llms.txt, die als „Pitch an Crawler“ geschrieben ist, ist für agentische Nutzung untauglich. Eine llms.txt, die als „Bedienungsanleitung für Agenten“ geschrieben ist, hat in der GEO-Welt nichts verloren.

Wie eine agentische llms.txt aussieht: drei Beispiele aus dem deutschen Telefonbuchmarkt

Um zu zeigen, was ich meine, habe ich drei Beispieldateien für gut bekannte deutsche Verzeichnisdienste gebaut — Gelbe Seiten, Das Telefonbuch und Das Örtliche. Die Wahl ist kein Zufall: Branchen- und Personenverzeichnisse sind ein Lehrbuchfall für agentische Aufgaben und könnten den Plattformen zu neuer Relevanz für KI-Systeme verhelfen, wenn man nicht gerade Google mit Zugriff auf Google Maps oder Apple mit Apple Maps ist.

„Friseur in Berlin-Mitte mit Öffnungszeit Samstag“, „Rückwärtssuche zu dieser Telefonnummer“, „Notapotheke in der Nähe“ — das sind exakt die Tasks, die Information Agents und Agentic Booking aus Reids Keynote bedienen sollen.

Was in diesen Dateien steht, ist explizit keine Marketing-Beschreibung der Plattform. Es sind sechs Dinge:

Erstens: Eine knappe Intent-Beschreibung. Wofür ist diese Seite zuständig, wofür nicht? Beispiel aus der Datei für Das Örtliche: Lokale Kontakt-, Telefonbuch- und Branchensuche; für stark gewerbliche Dienstleisterauswahl kann Gelbe Seiten ergänzend sinnvoll sein. Das ist eine Routing-Empfehlung, keine Werbung.

Zweitens: URL-Patterns, die ein Agent direkt zur Resolution nutzen kann. Statt einen Agenten erst die Suchmaske parsen zu lassen, gebe ich ihm das kanonische Muster:

• https://www.gelbeseiten.de/branchen/{branche-slug}/{ort-slug} für Branchen-Ortslisten
• https://www.dastelefonbuch.de/Branchen/{branche-slug}/{ort-slug} mit dem Hinweis, dass Stadtteile via doppeltem Bindestrich angehängt werden (Berlin--Biesdorf)
• https://www.dasoertliche.de/Themen/{thema-slug}/{ort-slug}.html mit Query-Fallback, wenn das Thema nicht kanonisch ist

Drittens: Normalisierungsregeln. „Frankfurt am Main“ wird in der einen Plattform mit URL-kodierten Leerzeichen geschrieben, in der anderen mit Bindestrichen verbunden. Umlaute werden mal kodiert, mal nicht. Berliner Bezirke folgen einem Sondermuster (berlin%20bezirk%20mitte). Ohne diese Hinweise rät der Agent — und scheitert in 30 Prozent der Fälle.

Viertens: Resolver-Workflows. „Nutzeranfrage zerlegen in Branche, Ort, optional Stadtteil und Zeitwunsch. Wenn ein kanonisches Thema bekannt ist, /Themen aufrufen, sonst Query-Fallback.“ Das ist Pseudocode für agentisches Verhalten.

Fünftens: Bestätigungs- und Datenschutzgrenzen. Bei Aktionen wie Anrufen, Reservieren, Routenplanung oder Kontaktanlage muss der Agent vor Ausführung den Nutzer bestätigen lassen. Personenbezogene Treffer dürfen nicht massenhaft profiliert werden. Diese Regeln gehören in die llms.txt, weil sie genau zur Inferenzzeit gebraucht werden, in der ein Agent gerade kurz davor ist, etwas Unwiderrufliches zu tun.

Sechstens: Discovery-Links. robots.txt, Sitemaps, Impressum, Datenschutz. Das ist nichts Magisches — aber es ist genau das, was ein Agent als Erstes braucht, um sich auf der Domain zu orientieren.

Was diese drei Dateien gemeinsam haben: Sie sind nicht „kuratierte Inhaltsbeschreibung gegenüber einem Crawler“. Sie sind eine API-artige Dokumentation der Site-Logik. Wer sie liest, ist nicht der Indexer, sondern der Operator.

Konkrete Empfehlungen für die nächsten Wochen

Wenn du heute überlegst, was du tun sollst, würde ich nach drei Kategorien sortieren:

Wenn du eine Entwickler-Dokumentation hast — JETZT. Wer eine API anbietet, ein SDK pflegt, ein Framework dokumentiert oder eine technische Spezifikation veröffentlicht, sollte heute eine llms.txt bereitstellen und idealerweise auch Markdown-Versionen der relevanten Dokumentationsseiten ausliefern (etwa unter /seite.md neben /seite.html). Das war Jeremy Howards Original-Use-Case, das ist das, wofür Mintlify, Anthropic und Cursor die Dateien haben, und das ist der Bereich, in dem die Adoption durch Coding Agents real ist. Hier zahlt sich die Investition unmittelbar aus, weil deine API von einem Cursor- oder Claude-Code-Nutzer schneller verstanden und korrekt eingesetzt wird.

Wenn du einen Service anbietest, der agentisch genutzt werden könnte — denk in Szenarien. Beispiele: Verzeichnisdienste, Buchungsplattformen, Marktplätze, lokale Dienstleister, Kartenanwendungen, Behörden-Services. Frag dich: Was würde ein Information Agent von Google bei einer typischen Nutzeranfrage auf meiner Seite tun müssen? Welche URLs sind die richtigen Einstiegspunkte? Welche Aktionen sind reversibel, welche nicht? Welche Datenschutzgrenzen muss ein Agent kennen? Daraus entsteht eine sinnvolle llms.txt, die — ob sie heute schon gelesen wird oder nicht — als interne Klärungsübung wertvoll ist.

Wenn du eine klassische Content-Site betreibst — abwarten und beobachten. Für News-Seiten, Magazine, Corporate Sites, Blogs gilt meine Februar-Analyse weiterhin: Eine llms.txt als Sichtbarkeits-Hebel zu pflegen ist Opportunitätskosten ohne nachweisbaren Nutzen. Wenn die Adoption sich verschiebt, lässt sich eine Datei in einer Stunde generieren. Wer jetzt Zeit investiert, sollte sie in Content-Qualität und Zitierfähigkeit stecken.

Was bleibt richtig

OtterlyAIs 0,1-Prozent-Zahl ist immer noch die belastbarste Datenquelle, die wir haben. Mueller und Illyes haben ihre Position nicht widerrufen. Die strukturellen Argumente gegen llms.txt als Retrieval-Signal — Manipulationsanfälligkeit, Effizienz-Probleme im Retrieval-Stack, Redundanz zur robots.txt — sind unverändert gültig.

Wer nach diesem Artikel zurück ans Whiteboard geht und in den nächsten GEO-Audit „llms.txt erstellen und optimieren“ als Workstream schreibt, hat ihn missverstanden. Die llms.txt ist weiterhin kein Ranking-Hebel. Sie wird auch keiner werden.

Fazit

Mein Februar-Titel war zugespitzt. Das war Absicht, und die Pointe trifft die Sache, die ich angreifen wollte: llms.txt als GEO-Maßnahme.

Was ich nicht ausreichend gewürdigt habe: Mit der Verschiebung von „Search als Retrieval“ zu „Search als Task-Ausführung“ entsteht eine zweite Klasse von Nutzungsszenarien. In diesen Szenarien ist eine gut gepflegte llms.txt keine Marketing-Datei, sondern eine Bedienungsanleitung. Sie wird nicht von einem Crawler gewichtet — sie wird von einem Operator gelesen, der gerade eine Aufgabe abarbeitet.

Diese Lesart ist näher an Jeremy Howards Originalvorschlag von September 2024 als die GEO-Interpretation, die im Frühjahr 2025 viral ging. Vielleicht war die llms.txt nie tot. Vielleicht war sie nur in einer Diskussion gefangen, die mit ihrem eigentlichen Zweck wenig zu tun hatte.

Wenn die agentische Suche das wird, was Google auf der I/O versprochen hat, dann werden wir alle in den nächsten Monaten darüber nachdenken, welche URLs unserer Sites für welche Tasks die richtigen sind — und wie wir das einem Agenten in einer halben Seite Markdown erklären. Das ist eine Konversation, die es wert ist, geführt zu werden. Sie hat nur nicht das Etikett verdient, unter dem sie 2025 vermarktet wurde.