Markdown per Accept-Header: So servieren Sie AI-Agenten Ihre Inhalte direkt

Ich stimme Roy Fielding zu:

> Es ist ein schlechter Design-Kompromiss, bei jeder Anfrage eine Reihe von Header-Feldern zu senden, nur um dem Server alle möglichen Variationspräferenzen des Nutzers mitzuteilen, insbesondere wenn die Wahrscheinlichkeit sehr gering ist, dass eine dieser Dimensionen auf die Zielressource zutrifft. Das war schon seit der sehr kurzen Zeit 1993-94 ein schlechter Design-Kompromiss, als die Leute nicht wussten, welches Bildformat auf allen UAs verwendbar sein würde und es kein CSS oder JavaScript für clientseitige Anpassung gab.

> ...Die Auswirkung auf den Cache bei proaktiver Aushandlung ist weitaus schlimmer als der eine zusätzliche Roundtrip pro Website bei reaktiver Aushandlung, und selbst dieser Roundtrip ist in Formaten, die clientseitige Anpassung unterstützen, nicht notwendig.

Zur Cache-Auswirkung schrieb Simon Willison:

> ...man kann keine Anwendung, die Inhaltsaushandlung über den Accept-Header nutzt, hinter dem Cloudflare-CDN bereitstellen – zum Beispiel, um je nach eingehendem Accept-Header JSON oder HTML für dieselbe URL auszuliefern. Wenn man das tut, kann Cloudflare zwischengespeichertes JSON an einen HTML-Client ausliefern oder umgekehrt.

Hinweis: Ich habe dies in einem anderen Kommentar mit Links zu diesen beiden Zitaten gepostet, die ich jetzt nicht einfach kopieren konnte – werde sie später hinzufügen.

Das mache ich, sobald einer der Top-4-KI-Chatbots sagt, dass sie Anfragen mit diesem Header stellen werden. Davor ist es nur eine nette Idee ohne Akzeptanz.

Ich denke auch, dass es äußerst unwahrscheinlich ist, dass einer der Top-4-Chatbots Websites auf diese Weise laden würde. Zu viele Risiken für eine 0,01%ige Akzeptanz selbst Jahre später.

Was ist mit sauberem, semantischem HTML?

Es war bereits für Bots und Suchmaschinen (die Bots sind) optimiert und wird seit Jahrzehnten verwendet. Warum müssen wir jetzt in Markdown ausliefern?

Es gibt auch viele Teile des HTML, wie Navigationen, die für Bots und KI nützlich sind und in der Markdown-Version entfernt werden könnten.

Ich habe das Gefühl, ich werde verrückt. Wer bei klarem Verstand würde einem LLM überhaupt rohes HTML füttern??

HTML ist eine Auszeichnungssprache. User Agents präsentieren sie so, dass sie für den Nutzer Sinn ergibt – visuell oder durch assistive Technologie. Nichts daran, LLM-"Nutzer" hinzuzufügen, sollte das ändern – ihr User Agent, das Harness, sollte HTML so präsentieren, dass sie es nativ verstehen, indem er es in Markdown übersetzt.

Wir werden nicht das gesamte Web neu schreiben, nur weil Harness-Entwickler zu faul oder zu dumm sind, ein HTML-zu-Markdown-Paket von npm zu ziehen. Wenn einige Websites es trotzdem tun wollen, gut für sie, in vielen Fällen würde ich gerne das CSS/JS überspringen und das Markdown direkt lesen (oder besser, schön formatiert). Aber gebt nicht den Website-Autoren die Schuld dafür, dass euer Harness eure Tokens verschwendet.

Angesichts aller Fragen in diesem Thread empfehle ich dringend Dachary Careys Beitrag zum Thema agentenfreundliche Doku: https://dacharycarey.com/2026/02/18/agent-friendly-docs/

Ich hoffe, dass das Mainstream wird, damit ich die Seiten einfach ohne Werbung, JS und Ballast ansehen kann.

Warum sollte eine Website zusätzliche Mühe darauf verwenden, ihren Inhalt als Markdown an KI zu "verschenken" und nichts dafür zurückzubekommen?