Wenn ein KI-Agent einen unserer Blog-Artikel liest, wiegt die HTML-Version 466 KB. Die Wörter in diesem Artikel wiegen 18 KB. Alles andere ist Markup, Styling und Framework-Payload, für die ein Sprachmodell in Tokens bezahlt und die es anschließend wegwirft.
Diese Woche haben wir die Lösung über den gesamten Blog ausgerollt: Jeder unserer 208 Artikel hat jetzt in allen drei Sprachen einen rohen Markdown-Zwilling. Nimm eine beliebige Artikel-URL, häng .md an, und du bekommst den sauberen Text. Das sind 624 statische Dateien, beim Build erzeugt, ausgeliefert ohne Laufzeitkosten. Die Markdown-Version des gemessenen Artikels ist 96 Prozent kleiner als ihr HTML-Geschwister.
Dieser Beitrag erklärt, warum wir das gebaut haben, wie die Schicht funktioniert, warum wir bewusst vom Muster abweichen, das Vercel und Cloudflare nutzen, und was das realistisch für KI-Sichtbarkeit bringt und was nicht.
Die vergessene Hälfte des llms.txt-Standards#
Die meisten kennen llms.txt als "robots.txt für KI": eine Markdown-Datei im Root der Domain, die Sprachmodellen erklärt, worum es auf der Site geht. Jeremy Howard hat den Standard im September 2024 vorgeschlagen, und Adoptions-Studien aus 2026 sehen ihn auf ungefähr jeder zehnten Domain.
Was fast alle überspringen, ist die zweite Hälfte desselben Vorschlags. Die Spezifikation empfiehlt ausdrücklich, dass Seiten "eine saubere Markdown-Version dieser Seiten unter derselben URL wie das Original, aber mit angehängtem .md" bereitstellen.
In dieser zweiten Hälfte steckt der eigentliche Wert. Eine llms.txt ist ein Inhaltsverzeichnis. Die .md-Seiten sind die eigentliche Mahlzeit. Ein Inhaltsverzeichnis ohne lesbare Kapitel dahinter ist genau der Grund, warum mehrere unabhängige Analysen dieses Jahr festgestellt haben, dass eine llms.txt allein die Zitierraten nicht messbar bewegt.
Dokumentations-Plattformen haben das zuerst verstanden. Stripe, Anthropic, Neon und FastAPI liefern sauberes Markdown, wenn du .md an eine Docs-URL hängst. Mintlify hat Content Negotiation in jede gehostete Docs-Site eingebaut. Sentry liefert Agents Markdown unter denselben URLs, die Menschen benutzen. Im Februar 2026 bestätigte Vercel, dass Claude Code und OpenCode bereits Accept: text/markdown mit ihren Requests senden, und im März startete Cloudflare Markdown for Agents und konvertiert HTML an der Edge zu Markdown.
Die Konvergenz unter den Infrastruktur-Firmen ist also durch. Was wir nicht sehen: normale Business-Sites und Blogs, die nachziehen. Diese Lücke ist die Chance.
Warum Token-Ökonomie das entscheidet#
Das Argument ist nicht ästhetisch, es ist Arithmetik.
Unser gemessenes Beispiel: 466.398 Bytes HTML gegenüber 18.028 Bytes Markdown für einen Artikel mit 2.900 Wörtern. Faktor 26. Vercel berichtet rund 90 Prozent Größenersparnis für ihre verhandelten Seiten; unsere statischen Zwillinge landen bei 96 Prozent, weil überhaupt kein Boilerplate übrig bleibt.
Für einen Agenten ist dieser Unterschied nicht kosmetisch. Kleinere Payloads bedeuten weniger Tokens pro Seite, und das bedeutet: Ein Agent, der ein Thema recherchiert, kann sich zwanzig deiner Artikel leisten statt einem. Es bedeutet auch weniger Parsing-Fehler: keine Cookie-Banner, keine Navigation, keine Script-Tags, die HTML-zu-Text-Konverter mitten im Satz zerlegen.
Die Traffic-Seite macht das dringend. Cloudflare-Radar-Daten vom Juni 2026 zeigen, dass automatisierte Requests inzwischen mehr als die Hälfte des HTML-Traffics im Web ausmachen, KI-Crawler allein liegen bei rund einem Fünftel des verifizierten Bot-Traffics. Und die Verhältnisse von Crawls zu Besuchen sind brutal: Anthropics Crawler holen Tausende Seiten für jeden Besuch, den sie zurückschicken. Diese Abrufe passieren, ob du sie gut bedienst oder schlecht. Sie schlecht zu bedienen heißt nur, dass du die Bandbreite bezahlst und trotzdem falsch gelesen wirst.
Was wir konkret gebaut haben#
Die Schicht hat vier Teile, und alle sind statisch. Nichts läuft zur Request-Zeit, keine API wird aufgerufen, kein Modell ist beteiligt.
Markdown-Zwillinge. Jede Artikel-URL akzeptiert .md: zum Beispiel /de/blog/claude-guide-2026.md. Jede Datei beginnt mit YAML-Frontmatter mit Titel, Beschreibung, Autor, Veröffentlichungs- und Update-Datum, Tags, der kanonischen HTML-URL und den URLs aller drei Sprachversionen. Darunter steht der volle Artikel, jeder relative Link zu einem absoluten umgeschrieben, plus ein kurzer Weiterlese-Block mit verwandten Artikeln aus demselben Themen-Cluster, ebenfalls als .md-Links. Ein Agent, der auf einem Artikel landet, kann weiterlesen, ohne je HTML anzufassen.
Feeds, die den Inhalt tragen. Unsere RSS-Feeds enthalten jetzt das komplette Artikel-HTML für die neuesten zwanzig Beiträge, nicht nur Teaser. Es gibt einen JSON-Feed-Endpunkt, und jeder unserer 26 Themen-Cluster hat einen eigenen Feed, sodass ein Abonnent, Mensch oder Maschine, nur "Claude und Claude Code" oder nur "KI-Sichtbarkeit" folgen kann.
Auffindbarkeit. Der HTML-Head jedes Artikels verlinkt seinen Markdown-Zwilling per <link rel="alternate" type="text/markdown">, genau wie man einen RSS-Feed bewirbt. Unsere llms.txt listet alle 26 Lese-Strecken und nennt die .md-Konvention einmal, prominent. Der JSON Feed trägt die Markdown-URL pro Eintrag als Erweiterungsfeld.
Konsolidierung. Jede .md-Antwort sendet einen HTTP-Link-Header, der die HTML-Seite als kanonisch deklariert. Keine noindex-Spielchen: Suchmaschinen konsolidieren die Signale auf die HTML-Version, während Agents das Markdown frei konsumieren.
Weil die Blog-Metadaten in einer einzigen typisierten Quelldatei leben, regeneriert sich die ganze Schicht bei jedem Build. Ein neuer Artikel bekommt seine drei Zwillinge, seine Feed-Einträge und seinen llms.txt-Eintrag automatisch.
Warum wir explizite URLs statt Content Negotiation gewählt haben#
Vercel und Cloudflare werben beide für Content Negotiation: eine URL, und der Server entscheidet anhand des Accept-Headers, ob HTML oder Markdown zurückkommt. Das ist elegant, und für deren Infrastruktur die richtige Wahl.
Wir haben das bewusst nicht getan, und der Grund ist Caching.
Jede Site hinter einem CDN-Edge-Cache muss eine Frage ehrlich beantworten: Enthält dein Cache-Key den Accept-Header? Auf gängigen CDN-Tarifen lautet die praktische Antwort nein. Die Edge speichert eine Variante pro URL. Stell dir vor, ein Agent fragt deinen Artikel mit Accept: text/markdown an, genau in dem Moment, in dem der Cache kalt ist. Die Markdown-Antwort wird unter der Artikel-URL gecacht, und die nächsten tausend menschlichen Besucher bekommen rohes Markdown in den Browser. Content Negotiation hinter einer Edge, die Vary ignoriert, ist ein Cache-Poisoning-Vorfall, der auf seinen Auslöser wartet.
Explizite .md-URLs machen das Problem strukturell unmöglich. Zwei URLs, zwei Cache-Einträge, keine Mehrdeutigkeit. Das kostet ein bisschen Eleganz und kauft vollständige Vorhersagbarkeit. Wer seine Edge-Konfiguration bis ins Detail kontrolliert, kann verhandeln. Wer auf einem Standard-CDN-Tarif sitzt, fährt mit expliziten URLs die sicherere Architektur, und die ist obendrein genau das, was die llms.txt-Spezifikation von Anfang an empfohlen hat.
Der ehrliche Teil: was das nicht leistet#
Hier will ich präzise sein, denn dieses Feld ist voll von aufgeblasenen Versprechen.
Markdown auszuliefern sorgt für sich genommen nicht dafür, dass ChatGPT dich zitiert. Die Daten aus 2026 sind eindeutig: llms.txt-Adoption allein zeigt keinen messbaren Citation-Effekt, und ich habe keinen Grund zu glauben, dass .md-Zwillinge allein sich anders verhalten. Zitate folgen aus Inhalten, die echte Fragen beantworten, aus strukturierten Daten, die Maschinen verifizieren können, aus konsistenten Entitäten und aus tatsächlicher Indexierung. Unsere eigenen Zahlen, über 14.100 Bing-Copilot-Zitate im rollenden 30-Tage-Fenster Anfang Juli 2026, kommen aus diesem gesamten Stack, der über Monate zusammenarbeitet. Die Markdown-Schicht ist ein Baustein, nicht das Gebäude.
Was die Schicht heute liefert: Agents, die diesen Dialekt bereits sprechen, lesen deine Site zum Bruchteil der Kosten. Claude Code sendet den Markdown-Accept-Header jetzt. Cursor, Windsurf und andere IDE-Agents holen llms.txt routinemäßig ab, wenn man sie auf eine Site zeigt. Jede dieser Interaktionen funktioniert besser, wenn hinter der Eingangstür sauberes Markdown liegt. Und wenn ein Assistent deinen Artikel sauber liest, statt ihn aus 466 KB Markup herauszuparsen, steigt die Wahrscheinlichkeit, dass er deine Inhalte korrekt wiedergibt. Das ist das realistische Versprechen: billiger zu lesen, schwerer falsch zu zitieren, bereit für den Traffic-Mix, auf den sich das Web sichtbar zubewegt.
So baust du das auf deinem eigenen Stack#
Das Muster ist auf jeden Stack übertragbar, der seine Inhalte zur Build-Zeit kennt.
- Erzeuge die Zwillinge beim Build. Wenn deine Inhalte ohnehin in Markdown leben, bist du zu 80 Prozent fertig: eine
.md-Datei pro Seite pro Sprache, mit Frontmatter für Titel, kanonische URL und Übersetzungen. Schreib relative Links zu absoluten um, damit die Datei auch außerhalb ihres Kontexts funktioniert. - Setz den kanonischen Link-Header. Jede Markdown-Antwort sollte ihr HTML-Geschwister als kanonisch deklarieren. Damit bleibt dein Such-Setup unberührt.
- Mach es auffindbar. Ergänze den alternate-Link-Tag in deinen HTML-Heads und nenn die Konvention einmal in deiner llms.txt. Auffindbarkeit ist die halbe Funktion; ein unauffindbarer Endpunkt existiert nicht.
- Nutz die Abkürzungen deiner Plattform. Auf Cloudflare ist Markdown for Agents eine Zonen-Einstellung. Für WordPress gibt es inzwischen Plugins, die Markdown ausliefern. Wer auf einer Docs-Plattform wie Mintlify sitzt, hat es schon.
Ein funktionierendes Beispiel ist einen Klick entfernt: Genau dieser Artikel hat, wie jeder Artikel in diesem Blog, seinen Zwilling unter dieser URL mit angehängtem .md. Wenn du dieselbe Schicht, plus die strukturierten Daten und den Mess-Stack drumherum, für deine Site gebaut haben willst: genau das machen wir.
Wohin das führt#
Das Web hat die Linie bereits überschritten, an der Maschinen mehr HTML anfragen als Menschen. Jede Trendlinie, die ich sehe, sagt: Die Lücke wird größer. Agent-Traffic wächst, menschliche Seitenaufrufe pro Aufgabe schrumpfen, und die Sites, die Maschinen-Anfragen sauber beantworten, werden mehr gelesen, seltener falsch zitiert und zitiert, wenn es zählt.
Markdown-Zwillinge werden in zwei Jahren selbstverständlich aussehen, so wie Responsive Design heute selbstverständlich aussieht. Der Standard fordert sie bereits, das Tooling existiert auf jedem Stack, und die Kosten sind ein Build-Schritt. Das einzig wirklich Überraschende ist, wie wenige Sites außerhalb der Dokumentations-Welt das ausgeliefert haben. Ausnahmsweise ist früh dran sein billig.
