Agentenlesbare Websites: llms.txt, Markdown-Spiegel und was wirklich kaputtgeht

Eine agentenlesbare Website liefert zu jeder Seite eine saubere Maschinenkopie aus, kündigt sie im Seitenkopf an und blockt nichts, was sie abrufen muss. Der schwierige Teil ist nicht die Entscheidung dafür. Es ist, das nach dem vierten Deployment noch wahr zu halten, denn jeder Fehlerfall hier ist im Browser unsichtbar und in deinen Logs stumm.

Wir betreiben diesen Stack auf der Website, die du gerade liest: einen Markdown-Spiegel jeder Seite, eine llms.txt pro Sprache, veröffentlichte Agent Skills und einen Verifier, der den Production-Build scheitern lässt, sobald davon etwas kaputt ist. Dieser Beitrag ist die Liste der Dinge, die dieser Verifier gefangen hat, und die ist nützlicher als die Liste, die man beim Lesen der Spezifikation bekommt.

Die vier Oberflächen, die ein Agent tatsächlich nutzt

Agentenlesbarkeit wird als ein Thema diskutiert, es sind aber vier voneinander unabhängige Oberflächen, und eine Website kann drei davon bestehen und trotzdem unsichtbar bleiben.

Die Reihenfolge zählt. Strukturierte Daten auf einer Seite zu reparieren, von der ein Retrieval-Fetcher ausgeschlossen ist, ist verlorene Arbeit, und genau so wird dieses Projekt am häufigsten von hinten begonnen.

llms.txt, ehrlich betrachtet

llms.txt ist eine Konvention, kein Standard. Keine Engine ist verpflichtet, sie zu lesen, und wer dir garantierte Auswertung verkauft, verkauft zu viel. Sie ist auch günstig zu erzeugen und gibt einem Agenten eine saubere Karte statt deiner gerenderten Navigation, weshalb wir eine veröffentlichen und sie meistens empfehlen.

Wenn du sie veröffentlichst, entscheiden drei Dinge, ob sie nützlich ist:

• Absolute URLs. Das ist der Fehler, den wir am häufigsten sehen, und wir haben ihn selbst gemacht. Eine llms.txt wird abgerufen und weitergegeben, losgelöst von der Seite, aus der sie kommt, es bleibt also keine Basis-URL, gegen die relative Links auflösen könnten. Eine Datei voller /services/…-Pfade ist eine Datei voller Sackgassen.
• Das Blockquote unter der H1. Dieser eine Satz ist das, was ein Agent am ehesten wörtlich übernimmt, wenn er dich vorstellt. Lass ihn weg, und der Agent schreibt diesen Satz selbst, aus dem, was er sich zusammengereimt hat.
• Notizen an jedem Link. Die : Notizen-Hälfte jedes Bullets ist, wie ein Agent mit knappem Budget entscheidet, welchen Link er öffnet. Eine nackte Titelliste lässt ihn raten.

Markdown-Spiegel und wie man sie ankündigt

Ein Spiegel ist derselbe Inhalt wie die Seite, ohne Beiwerk, als Markdown unter einem vorhersagbaren Pfad ausgeliefert und aus dem Seitenkopf verlinkt:

<link rel="alternate" type="text/markdown" href="/services/ai-visibility.md">

Spiegel zu erzeugen ist einfach. Sie treu zu halten ist der Teil, der eine Maschine braucht, denn ein Spiegel kann auf Weisen subtil falsch sein, die monatelang niemandem auffallen. Der Generator läuft nach dem Site-Build, geht das gerenderte HTML durch, und der Verifier vergleicht danach beides.

Die Fehlerfälle, die man kennen sollte

Das sind echte Funde aus unserem eigenen Build, keine Hypothesen. Jeder davon ist mindestens einmal live gegangen, bevor es das Gate gab.

Unser Favorit war subtiler als alle davon. Ein dekoratives Glyph auf einer Seite brachte ein wörtliches Anführungszeichen in einen SVG-Textknoten, was den HTML-Minifier in Foreign Content stoppte. Der Rest dieser Seite ging unminifiziert live, und ihr Markdown-Spiegel brach still nach zwei Dritteln ab und nahm die komplette FAQ mit. Im Browser sah nichts falsch aus. Das Gate ließ den Build scheitern, benannte die Route, und der Fix war ein einzelnes Zeichen.

Die robots.txt-Falle: Retrieval ist nicht Training

Das ist das teuerste Missverständnis im ganzen Thema, und es ist eine Zeile Konfiguration.

Manche Crawler existieren, um Trainingsdaten zu sammeln. Andere rufen eine Seite ab, um eine Frage zu beantworten und sie zu zitieren, jetzt gerade. Die erste Gruppe zu blocken ist eine Lizenzentscheidung, die du durchaus treffen willst. Die zweite Gruppe zu blocken entfernt dich komplett aus Antworten, und das passiert fast immer unbeabsichtigt:

User-agent: GPTBot
Disallow: /

User-agent: *
Disallow: /

Der erste Block ist ein bewusstes Trainings-Opt-out. Der zweite nimmt jeden Answer-Engine-Fetcher mit, weil ein Crawler ohne eigene Gruppe die Wildcard erbt. Das Team, das das geschrieben hat, glaubte, aus dem Training ausgestiegen zu sein. Es war auch aus dem Zitiertwerden ausgestiegen.

Wenn du die Position „zitiere mich, aber trainiere nicht auf mir“ willst, ist die schlüssig und konfigurierbar: benenne die Retrieval-Fetcher explizit und lass sie durch, und schließe die Trainings-Crawler namentlich aus.

Warum ein Gate und keine Checkliste

Jeder Punkt oben ist leicht einmal zu beheben und unmöglich durch guten Willen behoben zu halten. Der Inhalt ändert sich wöchentlich, die Templates monatlich, und keiner dieser Fehler erzeugt ein sichtbares Symptom. Ein Quartals-Audit findet sie ein Quartal zu spät.

Die Checks gehören also in den Build, neben die Tests. Unsere laufen nach dem Generieren der Website und lassen das Deployment scheitern, ein kaputter Spiegel ist damit eine rote Pipeline und kein langsames Leck. Das ist der ganze Trick, und deshalb geben wir Leuten den Regelkatalog statt eines Reports: der Agent Readability Checker führt dieselben Spiegel-Regeln in deinem Browser aus, und es ist derselbe Codepfad, der entscheidet, ob diese Website deployt.

Für die Nachbarprobleme: unser Open-Knowledge-Format-Guide behandelt das Verpacken internen Wissens als portables Markdown, und der Guide zum KI-fähigen Firmenwiki behandelt das Ausliefern dieses Wissens an deine eigenen Agenten. Dieser Beitrag dreht sich strikt um die öffentliche Oberfläche: was der Agent von jemand anderem lesen kann.