llms.txt war nie der Punkt

💡 Kurzfassung:

• llms.txt kann eine technische Idee sein, die es zu testen lohnt. Es ist aber weder ein anerkannter Anbieterstandard noch ein bewiesener Hebel für KI-Sichtbarkeit.
• Ich erprobte auf einer passenden Website eine umfangreichere Informationsarchitektur. Das war lehrreich, führte aber nicht zu einem explodierenden Sichtbarkeitsgewinn.
• Eine Hypothese sollte nicht zu „sofort hinzufügen“ werden, bevor Bedingungen, Kosten und ihr Verhältnis zur Anbieter-Dokumentation erklärbar sind.

Bei einem neuen, ausreichend vagen technischen Konzept gibt es zwei Reaktionen. Die eine lautet: „Interessant. Finden wir heraus, wo es hilft und wo nicht.“ Die andere: „Wenn Sie das noch nicht gemacht haben, liegen Sie bereits zurück. Tun Sie es jetzt.“

Was mich an der Diskussion über KI-Sichtbarkeit stört, ist die Geschwindigkeit, mit der eine Idee zum zweiten Satz wird. Bevor klar ist, was ein Anbieter in welchem Produkt tut – bevor es einen anerkannten Standard, einen erklärbaren Mechanismus oder ein gemessenes Ergebnis gibt –, wird sie zu einer festen Vorschrift und anschließend zu einer verkaufbaren Dienstleistung.

Eine technische Empfehlung gewinnt ihren Wert nicht durch die Sicherheit, mit der sie vorgetragen wird. Sie gewinnt ihn, wenn wir erklären können, für welches Produkt sie gilt, unter welchen Bedingungen und auf welcher Evidenz.

llms.txt zeigt diesen Kreislauf gut. Mein Einwand richtete sich nie gegen die Datei selbst. Ein neues Format, ein neuer Entdeckungspfad oder eine andere Repräsentation von Inhalten sind für sich genommen keine schlechten Ideen. Problematisch wird es, wenn ein Vorschlag ohne anerkannten Standard und ohne vom Anbieter bestätigten Sichtbarkeitsmechanismus in kurzer Zeit zu „Sie müssen das sofort auf Ihrer Website einführen“ wird.

Das ist keine theoretische Einwendung. Ich habe llms.txt auf einer geeigneten Website selbst ausprobiert.

Ich habe mehr als eine Datei ergänzt

Ich legte nicht nur eine Datei im Stammverzeichnis ab und verlinkte einige Seiten. Für mehrere Wissensbereiche baute ich eine hierarchische Informationsarchitektur. Ich erzeugte Markdown- und JSON-Versionen von Inhaltsseiten und verlinkte sie aus der Wurzeldatei in einer Reihenfolge, die für jemanden sinnvoll war, der dem Thema folgen wollte.

Das war eine zusätzliche Ebene neben der strukturierten-Daten-Arbeit der Website. Technisch war es interessant: Wie stellt ein Inhaltssystem dasselbe Wissen einem Menschen, einem Webcrawler und unterschiedlichen Werkzeugen dar? Meine Fragen waren jedoch enger:

• Werden diese Ressourcen überhaupt abgerufen?
• Hilft die Informationsarchitektur einem System, den richtigen Teil des Inhalts zu erreichen?
• Haben alternative Darstellungen wie Markdown oder JSON einen beobachtbaren praktischen Effekt?

Das sind getrennte Experimente. Sie lassen sich nicht auf eine 200 OK-Antwort, eine Dashboard-Bewegung oder einen Tool-Score reduzieren.

Das Ergebnis war kein Verkaufsversprechen

Nach der Umsetzung wurde die Website nicht schlechter. Einen explosionsartigen Gewinn an KI-Sichtbarkeit, den ich ehrlich der Architektur zuschreiben könnte, sah ich aber ebenfalls nicht.

Das beweist nicht, dass llms.txt unter keiner Bedingung für keine Website wirken kann. Aus einer einzelnen Website einen allgemeinen Mechanismus abzuleiten, wäre nur die Umkehrung desselben Fehlers.

Es zeigt aber klar genug: Eine reichhaltigere Datei- und Inhaltsarchitektur ist für sich genommen kein bewiesener Hebel für KI-Sichtbarkeit. Das Experiment war trotzdem erfolgreich, weil es bessere Fragen, die Wartungskosten einer Architektur und die Bedingungen sichtbar machte, unter denen ich dieselbe Investition erneut tätigen würde.

Wenn ein Inhaltssystem Markdown- oder JSON-Darstellungen mit geringem Zusatzaufwand ohnehin erzeugt, kann eine solche Ebene einen Versuch wert sein. Für eine separate Informationsarchitektur hinter einem bestehenden System, nur weil „KI sie jetzt will“, sehe ich nicht genügend Evidenz.

Das ist kein Argument gegen technische Neugier. Es ist ein Argument dagegen, ein Engineering-Experiment als bewiesene Marketingrendite zu verkaufen.

Dokumentation ist der Ausgangspunkt

Wir kennen nicht jedes Detail der Google-Algorithmen. Google veröffentlicht keinen Quellcode. Sagt Google Website-Betreibern aber klar: „Wir nutzen llms.txt nicht für Google Search; die Datei bringt weder Nutzen noch Schaden“, dann braucht jeder, der das Gegenteil als Gewissheit behauptet, stärkere Evidenz.

Googles aktueller Leitfaden zu generativen KI-Funktionen in der Suche ist eindeutig: Google Search verwendet weder llms.txt noch spezielles KI-Markup; die Datei helfe und schade Google Search nicht. Der Leitfaden macht auch Vorgaben wie eine besondere „Chunking“-Länge oder ein separates KI-Schema nicht zur Voraussetzung.

Die Datei kann weiterhin als Experiment oder organisatorische Ebene nützlich sein. Wer einen konkreten Vorteil für Google Search beansprucht, braucht dafür aber mehr als Googles eigene Dokumentation hergibt.

Auch andere Anbieter zeigen, dass „KI“ nicht ein System ist. OpenAI unterscheidet Bots für die Verfügbarkeit von Websites in ChatGPT-Suchergebnissen, Modelltraining und nutzerinitiierte Zugriffe. OpenAIs Crawler-Dokumentation beschreibt diese Trennung. Perplexity unterscheidet ebenfalls zwischen dem Bot für Suchergebnisse und nutzerinitierten Zugriffen. Perplexitys Crawler-Dokumentation tut dies ebenso.

Der Satz „Ich habe eine Datei für KI hinzugefügt“ ist daher zu weit, sofern er nicht Unternehmen, Produkt und Ablauf nennt. In Suchergebnissen zu erscheinen, Modelltraining, Grounding, nutzerinitiierter Abruf und ein Zitat in einer Antwort sind unterschiedliche Ergebnisse, die nicht durch denselben Schalter gesteuert werden.

Ein gutes Experiment ist keine schlechte Vorschrift

Dass eine Idee testenswert ist, bedeutet nicht, dass sie allen empfohlen werden sollte. In meiner Umsetzung passten alternative Inhaltsrepräsentationen zur bestehenden Architektur. Sind es nur einige Vorlagen, ein Build-Schritt oder eine weitere Darstellung bereits erzeugter Daten, können die Kosten angemessen sein. Die Dateien können später auch für Dokumentation, API oder Inhaltsverarbeitung nützlich sein.

Auf einer anderen Website kann dieselbe Arbeit eine neue Publishing-Pipeline, Synchronisierung, Fehlerverfolgung, URL-Wartung und redaktionelle Disziplin verlangen. Dann lautet die Frage nicht „Ist die Datei schädlich?“, sondern: „Ergibt diese Investition selbst ohne KI-Sichtbarkeit Sinn?“ Lautet die Antwort nein, verdient der behauptete Nutzen einen höheren Evidenzstandard.

Meine praktische Entscheidungskette ist heute einfach:

1. Entsteht diese alternative Darstellung mit geringem Aufwand aus der bestehenden Informationsarchitektur?
2. Wäre sie für einen anderen Nutzer oder ein anderes Produkt nützlich, selbst wenn kein KI-System sie verwendet?
3. Kann ich die Kopien bei Inhaltsänderungen zuverlässig aktuell halten?
4. Wird die Investition in einem Jahr auch ohne Nutzen noch angemessen erscheinen?

Wenn die meisten Antworten ja sind, probiere ich es aus. Wenn sie nein sind, priorisiere ich llms.txt nicht, nur weil Wettbewerber es tun.

Heute heißt es llms.txt, morgen eine andere Datei, ein Schema, ein Agentenstandard oder eine Metrik. Das Zubehör ändert sich; die Bewertung einer Empfehlung sollte es nicht.

Ist dies ein vom Anbieter dokumentiertes Verhalten, eine Forschungsbeobachtung mit transparenter Methodik oder eine Hypothese, die noch getestet werden muss?

Fehlt eine der ersten beiden Antworten, kann „Lassen Sie es uns ausprobieren“ richtig sein. Bis ein Experiment jedoch ein Ergebnis hervorbringt, sollte es nicht als unverhandelbar dargestellt werden.

llms.txt war nie der Punkt. Der Punkt ist zu wissen, wo die Evidenz endet – und Gewissheit darüber hinaus als Hypothese statt als Marketingbehauptung zu behandeln.

Quellen

• Google: Leitfaden zur Optimierung für generative KI-Funktionen in Google Search
• Google: KI-Funktionen und Ihre Website
• OpenAI: Überblick über OpenAI-Crawler
• Perplexity: Crawler