Nuxt Content und MDC: Seiten wie Komponenten schreiben

Warum statisches Markdown nicht immer ausreicht

Markdown ist großartig zum Schreiben. Es ist schnell, lesbar und portabel. Aber die meisten Webseiten bestehen nicht nur aus Absätzen und Überschriften — sie haben Heroes, Grids, CTAs und gebrandete Sektionen, die kein noch so sorgfältig gesetztes ## ausdrücken kann.

Die klassische Lösung ist, diese Seiten in Vue oder HTML zu schreiben. Das funktioniert gut, bis das Content-Team sie bearbeiten muss oder man merkt, dass der Inhalt über Komponentendateien verstreut ist, ohne klare Zuständigkeit.

Genau dieses Problem löst MDC.

Was ist MDC?

MDC steht für Markdown Components. Es ist eine Syntaxerweiterung auf Basis von Standard-Markdown, direkt in Nuxt Content v3 integriert, die es erlaubt, Vue-Komponenten direkt in .md-Dateien einzubetten.

Ein einfaches Beispiel:

::u-page-hero
---
title: Hallo, Welt.
description: Eine Komponente, gerendert aus Markdown.
---
::

Der Block ::u-page-hero entspricht direkt der Nuxt-UI-Komponente UPageHero. Props werden im Frontmatter-Stil als YAML innerhalb von --- geschrieben. Jeder Inhalt zwischen öffnendem und schließendem :: wird zum Default-Slot.

Komponenten lassen sich verschachteln, komplexe Props übergeben, Klassen hinzufügen — ganze Seitenlayouts können aus einer einzigen .md-Datei zusammengestellt werden.

Wie ich es auf dieser Website einsetze

Jede Seite auf dieser Website — die Startseite, das Blog-Verzeichnis, die Service-Seiten — ist eine Markdown-Datei in content/. Keine davon ist eine .vue-Datei.

Hier ein vereinfachtes Beispiel der Startseite:

::page-hero
---
title: Web Development neu gedacht.
description: Moderne, performante Anwendungen, die Ästhetik und Funktionalität vereinen.
---
:::hero-singularity
::

::page-section
---
title: Was ich für dich tue
---
:::u-page-grid
::::u-page-card
---
title: Frontend-Entwicklung
description: Performante, barrierefreie Interfaces mit Vue 3 und Nuxt.
---
::::
:::
::

page-hero und page-section sind dünne Wrapper, die ich in components/content/ geschrieben habe — sie fügen ContainerCorners und andere projektspezifische Details zu den Standard-Nuxt-UI-Komponenten hinzu. MDC löst sie automatisch auf, weil sie im richtigen Verzeichnis liegen.

Warum dieser Ansatz funktioniert

Trennung von Zuständigkeiten. Layout liegt in Vue-Komponenten. Inhalte liegen in Markdown. Keines davon vermischt sich mit dem anderen.

Keine CMS-Abhängigkeit. Der Inhalt sind schlichte Dateien im Repository. Jedes Teammitglied kann sie bearbeiten, Git trackt jede Änderung, und Deployment ist nur ein Push.

Volle Komponentenstärke. Props, Slots, verschachtelte Komponenten und Auto-Imports stehen alle zur Verfügung. Was in einem Vue-Template funktioniert, funktioniert auch in MDC.

Typsicherheit. Nuxt Content v3 ermöglicht Collection-Schemas über content.config.ts. z.string()-Felder für date und tags definieren — und die Query-Ergebnisse sind überall in der App vollständig typisiert.

Worauf man achten sollte

MDC konvertiert Komponentennamen für die Auflösung in PascalCase. ::u-page-hero wird zu UPageHero, ::page-section zu PageSection. Das bedeutet: Die Komponenten müssen als auto-importierbare Komponenten existieren — entweder global registriert oder in components/content/ für inhaltsspezifische Komponenten.

Wird eine Komponente nicht gefunden, rendert Nuxt Content sie stillschweigend als rohes HTML-Element. Die Lösung ist einfach: zuerst components/content/ prüfen und sicherstellen, dass die Benennung korrekt zugeordnet ist.

Fazit

MDC ist eines jener Features, das wie ein Nischenfall klingt — bis man es tatsächlich einsetzt. Hat man einmal ein komplettes Seitenlayout aus einer .md-Datei gebaut und gesehen, wie wartbar es wird, fühlt es sich falsch an, Inhalte wieder in .vue-Dateien zu verstreuen.

Wer Nuxt Content verwendet und MDC noch nicht erkundet hat: Klein anfangen. Eine Seite auswählen, sie in MDC umwandeln, und beobachten, wie klar die Struktur wird.