Googles Warnung vor Markdown-only-Seiten für AI SEO ist in Wahrheit eine Warnung vor einem doppelten Publishing-Stack

John Mueller und Martin Splitt von Google haben sich skeptisch zu der Idee geäußert, für AI Search oder LLM-Konsum separate Markdown-Versionen von Websites zu veröffentlichen. Auf den ersten Blick wirkt das wie eine Nischendiskussion aus dem SEO-Bereich. Praktisch ist es aber eine breitere operative Botschaft für Web-, Content- und IT-Teams: Wenn bereits ein funktionierender HTML-Publishing-Stack existiert, schafft ein zweiter Markdown-orientierter Auslieferungspfad für Modelle oft nur unnötige Duplikation, zusätzlichen Governance-Aufwand und neue Wartungsprobleme.

Das Kernargument ist einfach. HTML ist bereits das etablierte Auslieferungsformat des Webs – mit Struktur, Darstellung und einem seit Jahrzehnten gereiften Ökosystem. Wenn ein Team beginnt, eine Version für Menschen und eine zweite speziell für LLMs zu pflegen, entsteht schnell ein paralleler Rendering- und Content-Stack. Das bedeutet mehr Ausgabepfade, mehr QA-Flächen, mehr Versionsdrift und mehr Risiken für inkonsistente Informationen über verschiedene Kanäle hinweg.

Warum das über SEO hinaus wichtig ist

Für ein IT-nahes Unternehmen ist die entscheidende Frage nicht, ob Markdown technisch legitim ist. Die eigentliche Frage lautet: Löst ein zweites Inhaltsformat ein echtes Geschäftsproblem besser, als die bestehende Website zu verbessern? Viele Teams lassen sich vom Hype rund um AI Search dazu verleiten, neue Publishing-Schichten einzuziehen, bevor überhaupt klar ist, ob diese Schichten Sichtbarkeit, Zitationen oder Conversion wirklich verbessern. Architektonisch ist das selten ein guter Grundsatz.

• Zwei Versionen desselben Inhalts erhöhen redaktionellen und operativen Aufwand.
• Parallele HTML- und Markdown-Pipelines vergrößern das Risiko von Content-Drift und widersprüchlichen Updates.
• Zusätzliche Transformationsschichten schaffen mehr QA-, Templating- und Publishing-Fehlerquellen.
• Eine schwache User Experience droht, wenn Markdown-Seiten direkt oder unsauber gerendert ausgeliefert werden.
• Teams investieren leicht Zeit in Format-Experimente statt in Crawlability, Geschwindigkeit, Struktur und Content-Qualität der Hauptseite.

Wovor Google tatsächlich warnt

1) Markdown ist nicht automatisch das bessere Web-Auslieferungsmodell

Martin Splitts Punkt war nicht, dass Markdown nutzlos sei. Sein Punkt war, dass Markdown allein für Endnutzer meist keine gute Darstellung liefert, solange nicht zusätzliche Mechanik darum gebaut wird. Ab diesem Moment beginnt man im Grunde, Rendering-Logik nachzubauen, die Standard-Web-Stacks längst sauber beherrschen. Für die meisten Organisationen ist das eher architektonische Verdopplung als Vereinfachung.

2) Separate LLM-Versionen können die Arbeit verdoppeln

Wenn eine Organisation eine vollwertige Website für Menschen und zusätzlich einen eigenen Output für AI-Systeme pflegt, wird jede Änderung an Inhalten, Metadaten, Rechtstexten, Produktinformationen oder Navigationsregeln schnell zu einem Synchronisationsproblem. Selbst wenn die Markdown-Version automatisch erzeugt wird, muss die Pipeline trotzdem gebaut, überwacht und getestet werden. Genau diese Betriebskosten werden in Trendphasen oft unterschätzt.

3) Einfacheres Publishing gewinnt meistens

Der bessere Weg ist in der Regel, die kanonische Website zu verbessern, statt einen Nebenkanal zu eröffnen. Wenn HTML-Seiten sauber strukturiert, schnell, crawlbar und semantisch konsistent sind, liefern sie bereits eine stabile Quelle für Nutzer, Suchmaschinen und nachgelagerte AI-Systeme. Einfachheit ist hier ein operativer Vorteil – nicht bloß eine Geschmacksfrage von Entwicklern.

Die praktische Architekturfrage für Unternehmen

Im Kern geht es um Plattformdesign. Will man ein einziges autoritatives Content-System mit klarer Zuständigkeit – oder zwei teilweise überlappende Repräsentationen für unterschiedliche Konsumenten? Für die meisten Unternehmen sollte die Antwort ein autoritatives System sein. Sobald parallele Content-Ausgaben existieren, braucht man Regeln für Synchronisierung, kanonische Ownership, Rollback, Validierung, Zugriffskontrolle und Auditierbarkeit. Aus einem Format-Experiment wird dann sehr schnell ein Governance-Thema.

Was Teams stattdessen tun sollten

Die kanonische HTML-Erfahrung verbessern

Wenn das Ziel bessere Sichtbarkeit in AI-gestützter Suche oder in Zitier-Systemen ist, sollte man zuerst die Seiten verbessern, die das Unternehmen ohnehin repräsentieren. Sauberes semantisches Markup, gute interne Verlinkung, stabile Navigation, strukturierte Metadaten, schnelle Auslieferung und konsistenter Seitenkontext sind deutlich belastbarer als eine zweite Web-Oberfläche mit unklarem Nutzen.

Maschinenlesbare Ausgaben nur dort einsetzen, wo sie klar helfen

Es gibt Fälle, in denen separate maschinenlesbare Artefakte sinnvoll sind – etwa APIs, Produktfeeds, Dokumentations-Exporte oder klar abgegrenzte Hilfsdateien wie `llms.txt`. Diese sollten aber nur entstehen, wenn sie einen definierten operativen Zweck erfüllen, und nicht aus der Hoffnung heraus, dass ein Markdown-Spiegel die gesunde Site-Architektur plötzlich übertrifft.

AI-Search-Optimierung wie eine Engineering-Änderung behandeln

Jedes zusätzliche Publishing-Format sollte wie jede andere Plattformentscheidung bewertet werden: Wer besitzt es, wie wird es getestet, was bricht bei Drift, und welches messbare Ergebnis rechtfertigt die Wartungskosten? Ohne diese Disziplin werden AI-Search-Projekte schnell zu einer weiteren Quelle technischer Schulden, die nur strategisch klingt.

Fazit

Googles Warnung vor Markdown-Versionen für AI SEO ist weniger ein Verbot von Markdown als eine Warnung vor unnötiger Duplikation. Für Publisher und Unternehmen ist der vernünftige Weg meist, die bestehende Website zu stärken, statt einen parallelen Markdown-Publishing-Stack für LLMs aufzubauen. Ein kanonisches, gut strukturiertes und sauber gepflegtes Web-Erlebnis ist langfristig fast immer wertvoller als zwei lose synchronisierte Versionen auf der Jagd nach einem unsicheren AI-Search-Vorteil.