Stell dir vor, du bittest ChatGPT, den Inhalt einer Website zusammenzufassen.
Aktuell bekommen Modelle nicht das, was du im Browser siehst. Es bekommt ein Dokument voller <div>-Container, CSS-Klassen, Navigationsleisten, Cookie-Banner, Footer-Links und Schema-Markup. Irgendwo dazwischen steckt der eigentliche Inhalt. Drei Absätze Text, eingebettet in 400 Zeilen HTML.
Wir haben uns in der Agenturpraxis gefragt: Was wäre, wenn wir Websites eine zweite Ausgabe geben – eine, die genau das liefert, was ein Sprachmodell braucht?
Das Problem: Rauschen zwischen Website und KI
Moderne Websites sind komplex. Ein typischer Blogpost hat vielleicht 800 Wörter Inhalt, aber das zugehörige HTML-Dokument umfasst schnell 2.000–3.000 Zeilen. Navigation, Sidebar, Related Posts, Tracking-Snippets, strukturierte Daten – alles wichtig für den Browser, aber für ein LLM ist es Ballast.
Wenn ChatGPT, Claude oder ein anderes Sprachmodell eine Website crawlt oder über eine API verarbeitet, muss es erst einmal filtern: Was ist Inhalt, was ist Struktur, was ist Dekoration? Moderne Modelle sind darin erstaunlich gut – aber „erstaunlich gut“ ist nicht „perfekt“.
In der Praxis sehen wir regelmäßig, dass LLMs:
- Navigationselemente als Teil des Inhalts interpretieren
- Cookie-Hinweise oder CTA-Banner in Zusammenfassungen aufnehmen
- Hierarchien falsch gewichten, weil CSS-basierte visuelle Hierarchie im HTML nicht abgebildet ist
- Redundante Inhalte aus Footer oder Sidebar mitzählen
Das Ergebnis: Die Kernbotschaft einer Seite geht im Rauschen unter.
Was ist eine Markdown Response und warum ist sie relevant?
Eine Markdown Response ist eine alternative Ausgabe deiner Website, die denselben Inhalt in reinem Markdown liefert – ohne HTML-Overhead, ohne Layout-Elemente, ohne Dekoration. Typischerweise wird sie über einen separaten Endpunkt oder einen Accept-Header bereitgestellt.
Statt:
<article class="post post--featured">
<div class="post__header">
<h1 class="post__title font-bold text-3xl">Unser neues Feature</h1>
<div class="post__meta">
<span class="post__date">15. Juni 2025</span>
</div>
</div>
<div class="post__content prose lg:prose-xl">
<p>Wir haben unser Dashboard komplett überarbeitet...</p>
</div>
</article>
bekommt ein LLM:
# Unser neues Feature
*15. Juni 2025*
Wir haben unser Dashboard komplett überarbeitet...
Kein Rauschen. Klare Struktur. Der Inhalt steht im Vordergrund. Für Sprachmodelle ist das ein massiver Unterschied – nicht weil sie HTML nicht lesen können, sondern weil weniger Kontext verbraucht wird und die Signal-to-Noise-Ratio drastisch steigt.
Für wen macht es Sinn? Die ehrliche Analyse
Wir haben Markdown Responses für verschiedene Projekttypen evaluiert und sind zu einer klaren Einschätzung gekommen: Es macht für fast jeden Sinn – aber aus unterschiedlichen Gründen.
Agenturen und Dienstleister
Eure Websites sind eure Visitenkarte. Wenn ein potenzieller Kunde ChatGPT fragt „Was macht Agentur X?“, wollt ihr, dass die Antwort eure Kernbotschaft trifft – nicht euren Cookie-Banner zitiert. Markdown Responses geben euch Kontrolle darüber, wie LLMs euren Inhalt interpretieren.
Blogs und Content-Seiten
Hier ist der Nutzen am offensichtlichsten. Blog-Inhalte sind textlastig, und genau dieser Text soll bei LLMs ankommen. Markdown ist das native Format für strukturierten Text – Überschriften, Listen, Code-Blöcke, Links. Alles, was ein guter Blogpost braucht, bildet Markdown 1:1 ab.
SaaS-Produkte
Dokumentationen, Changelogs, Feature-Seiten – SaaS-Websites haben oft Inhalte, die direkt in LLM-Kontexte fließen. Wenn eure Nutzer ChatGPT fragen, wie euer Produkt funktioniert, ist eine saubere Markdown-Ausgabe Gold wert.
Wo es Overhead ist
Reine Web-Apps mit wenig öffentlichem Content – ein Dashboard, ein internes Tool – brauchen keine Markdown Response. Wenn es keinen Inhalt gibt, den ein LLM sinnvoll interpretieren soll, ist der Aufwand nicht gerechtfertigt. Gleiches gilt für Seiten, die primär interaktiv sind: Ein Konfigurator oder ein Kartenwidget lässt sich nicht sinnvoll in Markdown abbilden.
Die kritische Gegenfrage: Sollten LLMs nicht HTML verstehen?
Diese Frage haben wir uns selbst gestellt, und sie ist berechtigt. GPT, Claude und vergleichbare Modelle sind beeindruckend gut darin, HTML zu parsen und den relevanten Inhalt zu extrahieren. Die Modelle werden besser, nicht schlechter.
Das Argument lautet: Wenn wir anfangen, Inhalte speziell für LLMs aufzubereiten, schaffen wir eine Parallelstruktur, die gewartet werden muss. Und wir lösen ein Problem, das die Modelle selbst bald lösen werden.
Trotzdem glauben wir, dass zum aktuellen Zeitpunkt Markdown Responses sinnvoll sind. Drei Gründe:
-
Token-Effizienz zählt. Selbst wenn ein LLM HTML korrekt interpretiert, verbraucht es dafür Kontext-Tokens. Ein Markdown-Dokument ist oft 70–80 % kleiner als das HTML-Äquivalent. Bei API-Calls mit Token-Limits ist das ein harter, messbarer Vorteil.
-
Kontrolle über die Botschaft. HTML gibt dem LLM alles – und das Modell entscheidet, was relevant ist. Markdown gibt ihm genau das, was ihr als relevant definiert habt. Das ist kein Bug, das ist ein Feature.
-
Zukunftssicherheit. Die Art, wie LLMs Webinhalte konsumieren, verändert sich gerade fundamental. Wer jetzt eine saubere Markdown-Schicht hat, ist vorbereitet – egal ob für AI-Crawler, RAG-Pipelines oder zukünftige Standards wie
llms.txt.
Heißt das, HTML-Verständnis von LLMs ist irrelevant? Nein. Es heißt, dass wir es den Modellen nicht schwerer machen müssen, als es sein muss.
Praktische Umsetzung: Laravel und Drupal
Laravel: Spatie’s Markdown Response
Für Laravel-Projekte empfehlen wir das Paket spatie/laravel-markdown-response. Spatie liefert wie gewohnt eine saubere, gut dokumentierte Lösung.
composer require spatie/laravel-markdown-response
Der grundlegende Ansatz: Ihr definiert für eure Routes eine alternative Response, die den Content als Markdown ausliefert. Das kann über Content Negotiation via Accept-Header geschehen oder über einen dedizierten Endpunkt wie /seite.md.
use Spatie\MarkdownResponse\MarkdownResponse;
Route::get('/blog/{post}.md', function (Post $post) {
return new MarkdownResponse(
$post->toMarkdown()
);
});
Auf eurem Model könnt ihr eine toMarkdown()-Methode implementieren, die den Inhalt strukturiert:
public function toMarkdown(): string
{
return implode("\n\n", [
"# {$this->title}",
"*{$this->published_at->format('d. F Y')}*",
$this->body_markdown,
]);
}
Drupal: Markdownify-Modul
Für Drupal-Projekte gibt es das Markdownify-Modul, das HTML-Inhalte in Markdown konvertiert. Der Ansatz ist hier umgekehrt: Statt Markdown direkt zu speichern, wird bestehendes HTML zur Auslieferung konvertiert.
Das Modul lässt sich als Textformat-Filter einsetzen oder programmatisch nutzen, um für bestimmte Routes eine Markdown-Ausgabe zu generieren. Besonders praktisch für bestehende Drupal-Seiten, bei denen ihr den Content nicht umschreiben wollt.
Allgemeiner Tipp
Unabhängig vom Framework: Setzt einen Content-Type: text/markdown-Header und denkt über eine llms.txt im Root-Verzeichnis nach – eine Art robots.txt für Sprachmodelle, die auf eure Markdown-Endpunkte verweist.
Fazit: Ist Markdown Response ein Must-Have oder Nice-to-Have?
Unsere ehrliche Einschätzung: Für die meisten Websites ist es ein strategisches Nice-to-Have, das schnell zum Wettbewerbsvorteil wird.
Der Implementierungsaufwand ist gering – besonders mit Tools wie Spatie’s Paket oder Drupal’s Markdownify. Der Nutzen wächst mit jedem LLM, das eure Inhalte konsumiert. Und die Richtung ist klar: KI-Crawler werden mehr, nicht weniger.
Wenn ihr eine content-lastige Website betreibt – ob Blog, Agenturseite oder SaaS-Produkt – gibt es wenig Gründe, es nicht zu tun. Der Aufwand liegt bei wenigen Stunden, der potenzielle Impact auf eure Sichtbarkeit in KI-generierten Antworten ist erheblich.
Wer wartet, bis es ein Standard ist, hat den Vorteil des Early Movers verpasst. Wer es jetzt umsetzt, gibt LLMs genau das, was sie brauchen: klaren, strukturierten Inhalt ohne Rauschen.