Agent-Native: Wie Ihre Website für KI-Agenten lesbar wird

Wenn heute jemand ChatGPT oder Claude nach einem Unternehmen fragt, passiert selten, was der CEO glaubt. Der Agent googelt nicht, sondern fetcht ein paar Seiten direkt von der Website. Und dann passiert eines von drei Dingen:

1. Er bekommt eine Bot-Challenge von Cloudflare zurück und rendert “Turnstile”-HTML in die Antwort.
2. Er bekommt das komplette HTML inkl. Navigation, Footer, Cookie-Banner und Scripts, parsed sich das Wesentliche raus und halbiert dabei sein Token-Budget.
3. Er bekommt eine saubere Markdown-Version der Seite zurück, direkt konsumierbar.

Fall 3 ist die Ausnahme. Wir haben dectria.com letzte Woche umgebaut, damit es die Regel wird. Dieser Beitrag beschreibt, wie der Umbau aussieht, welche Fallen dabei liegen und warum sich das Pattern auf fast jede statische Website übertragen lässt.

Warum HTML für Agenten das falsche Format ist

Ein Mensch überfliegt ein Layout. Ein Agent rechnet in Tokens. Eine typische Marketing-Seite enthält rund 80% Boilerplate, das für Menschen selbstverständlich ist: Navigation, Footer-Links, Social-Icons, Skript-Loader, Kommentar-Widgets. Für einen Agenten ist davon nichts relevant, und jedes Byte erhöht die Wahrscheinlichkeit, dass Teile dieser Boilerplate in der Antwort an den Nutzer landen.

Markdown kehrt das Verhältnis um. Keine Scripts, keine CSS, keine Layout-Container. Nur Überschriften, Listen, Links und Fließtext. Ein Agent, der eine Seite in Markdown bekommt, liefert messbar bessere Antworten, bei einem Bruchteil der Kosten.

Zwei Ansätze, einer ist falsch

Der naheliegende Weg ist, für jede Seite eine zweite URL zu veröffentlichen. Aus /about wird /about.md. Einfach umzusetzen, aber auf Dauer problematisch: zwei URLs pro Inhalt schaffen ein Duplicate-Content-Problem, zwingen zu Canonical-Tags und hinterlassen die offene Frage, ob der Agent vom einen zum anderen Pfad raten soll.

Der bessere Weg ist eine Konvention, die seit 1999 im HTTP-Standard steht und trotzdem kaum genutzt wird: Content Negotiation. Ein Client schickt einen Accept-Header mit, der Server entscheidet, in welchem Format er antwortet. Eine URL, zwei Repräsentationen.

GET /about HTTP/2
Accept: text/markdown

Der Server liefert Markdown. Ruft ein Browser dieselbe URL mit Accept: text/html auf, kommt HTML zurück. Gleiche URL, gleicher Canonical, kein SEO-Konflikt.

Die Umsetzung in drei Teilen

Teil 1 - Der Build-Schritt. Nach dem normalen Site-Build läuft ein Post-Processor, der durch jede erzeugte HTML-Datei geht, den Hauptinhalt extrahiert und eine gleichnamige .md-Datei daneben legt. Für dectria.com erledigen das rund 40 Zeilen JavaScript mit cheerio zum Parsen und turndown zum Konvertieren. Ergebnis: 133 Markdown-Dateien neben 133 HTML-Dateien.

Teil 2 - Die Middleware. Vor jedem Request prüft eine Edge Function den Accept-Header. Nennt der Client text/markdown ausdrücklich, liefert die Function die .md-Shadow-Datei. Sonst fällt sie auf die HTML-Version zurück. Wichtig: generische Accept-Header wie */* müssen als HTML-Präferenz behandelt werden, nicht als Markdown-Wunsch. Sonst bekommt jeder cURL-Nutzer ungewollt Markdown.

Ein weiteres Detail, das viele Implementierungen falsch machen: Vary: Accept muss auf jeder Antwort stehen. Ohne diesen Header cached Cloudflare oder jeder andere Reverse-Proxy die HTML-Version und liefert sie anschließend auch an Agenten, die Markdown wollen.

Teil 3 - Die Discovery. Damit Agenten überhaupt wissen, dass die Site dieses Feature anbietet, hinterlegt man drei Signale:

• /llms.txt und /llms-full.txt als maschinenlesbare Site-Zusammenfassung.
• Link:-Header auf jeder Antwort, die auf diese Dateien sowie die sitemap-index.xml verweisen.
• /.well-known/agent-skills/index.json mit einer SKILL.md, die die Accept-Negotiation-Konvention dokumentiert.

Die letzten beiden folgen etablierten Standards (RFC 8288 Link-Header, Agent Skills Discovery v0.2.0) und werden von modernen Agent-Frameworks aktiv ausgewertet.

Training ja, Training nein

Eine Website für Agenten zu öffnen heißt nicht automatisch, sie für das Training von Foundation Models freizugeben. Diese Unterscheidung lässt sich präzise in robots.txt abbilden, dank der Content-Signal-Spezifikation von Cloudflare, die auf Artikel 4 der EU CDSM-Richtlinie 2019/790 aufbaut:

User-agent: *
Content-Signal: search=yes, ai-input=yes, ai-train=no
Allow: /

Übersetzt: Suchindexierung erlaubt, Real-Time-Fetching für Nutzerantworten erlaubt, Verwendung für Training verboten. Zusätzlich blockiert eine Liste von Hard-Blocks alle Crawler, die ausschließlich Trainings-Korpora sammeln: GPTBot, Bytespider, CCBot, Amazonbot, Applebot-Extended, Meta-ExternalAgent. Die Real-Time-Crawler ClaudeBot, ChatGPT-User und PerplexityBot bleiben frei.

Das ist der Unterschied, der oft verwässert wird. ClaudeBot und GPTBot sind nicht dasselbe Ding mit unterschiedlichen Namen. ClaudeBot fetcht, wenn Anthropics Claude gerade eine Nutzerfrage beantwortet. GPTBot sammelt Daten für das nächste Training. Wer beide gleich behandelt, verschenkt entweder Reichweite oder gibt ungewollt Trainingsdaten frei.

Die Cloudflare-Falle

Wer auf Cloudflare hostet, läuft in eine Dopplung, die im Dashboard nirgends zusammen sichtbar ist. Cloudflare hat zwei unabhängige Crawler-Blocking-Layer:

• Bot Fight Mode (Security → Bots → Settings) schickt AI-Crawlern eine HTML-Challenge. Das ist der Grund, warum ChatGPT gelegentlich “Turnstile”-Seiten zitiert.
• AI Crawl Control (Security → Bots → AI Crawl Control) hat eine pro-Crawler Allow/Block-Tabelle. Standardmäßig blockt sie ClaudeBot und PerplexityBot.

Beide müssen für eine agent-native Site konfiguriert werden. Wer nur eines ausschaltet, bekommt immer noch 403-Antworten, aber vielleicht in einem anderen Format. Die Diagnose dauert genau so lange, bis man realisiert, dass es zwei separate Features sind.

Was das misst

Ob eine Site agent-ready ist, lässt sich objektiv prüfen. isitagentready.com führt einen Checklist-Scan durch und gibt einen Score von 0-100. Ein realistisches Zielbild:

Ebene	Check	Status
Basis	llms.txt vorhanden	Muss
Discovery	Link-Header auf jeder Antwort	Muss
Negotiation	Accept: text/markdown liefert Markdown	Muss
Policy	Content-Signal in robots.txt	Sollte
Skills	.well-known/agent-skills/index.json	Kann

Die ersten drei reichen aus, um 80% des Agent-Verkehrs sauber zu bedienen. Die letzten beiden sind Zukunftsmusik, die heute aber mit wenig Aufwand mitgenommen werden kann.

Warum sich das lohnt

Die Anzahl der User Queries, die von AI-Agenten live beantwortet werden, wächst im Moment schneller als jeder andere Web-Traffic-Kanal. Wer heute Markdown ausliefert, hat eine saubere Repräsentation in den Antworten von Claude, ChatGPT und Perplexity. Wer es nicht tut, steht vor der Wahl zwischen HTML-Parsing mit Fehlerrate und einer Turnstile-Challenge in der Agent-Antwort.

Der Umbau einer bestehenden statischen Website dauert einen halben Tag. Die Architektur ist framework-agnostisch: was für Astro funktioniert, funktioniert genauso für Next, Nuxt, Hugo oder 11ty. Die Pattern-Kosten sind einmalig, der Effekt ist dauerhaft.

Was als Nächstes kommt

Das Vorgehen ist heute noch neu genug, dass Standards und Konventionen parallel entstehen. Agent Skills Discovery ist in Version 0.2.0, Content-Signal ist ein Cloudflare-Proposal auf dem Weg in die IETF, llms.txt ist ein Grassroots-Vorschlag ohne formale RFC. Das heißt: wer jetzt einsteigt, muss damit rechnen, in sechs Monaten eine Version aktualisieren zu müssen. Das ist ein überschaubarer Preis dafür, zu den ersten Sites zu gehören, die in AI-Antworten sauber repräsentiert werden, statt als Parsing-Unfall.

Wer prüfen will, wie die eigene Site heute bei Agenten ankommt, startet mit einem einzigen Befehl:

curl -I -H "Accept: text/markdown" https://eigene-domain.example/about

Wenn das Ergebnis 200 text/markdown ist, läuft das Setup. Wenn 200 text/html oder 403 zurückkommt, gibt es Arbeit.