CMS, Frontmatter, Content Collections: Was Marketing-Verantwortliche wirklich wissen müssen
„Wer als Marketing-Verantwortlicher versteht, wie ein modernes CMS Inhalte strukturiert, kann bessere Briefings schreiben, Qualität einfordern und Projekte realistischer einschätzen – ohne eine einzige Zeile Code zu schreiben. Headless CMS, Frontmatter und Content Collections sind keine Entwicklerthemen, sondern redaktionelle Werkzeuge, die Marketing-Teams direkte Kontrolle über SEO, Seitenstruktur und Veröffentlichungsprozesse geben."
Was ein CMS wirklich macht – und was nicht
CMS steht für Content Management System. Der Name klingt technischer als das Konzept: Im Kern ist ein CMS ein strukturiertes Formular, das Texte, Bilder und Metadaten so ablegt, dass ein technisches System sie weiterverarbeiten kann.
Das bekannteste Beispiel ist WordPress. Was beim Klick auf „Veröffentlichen” passiert, bekommt der Redakteur nicht zu sehen: WordPress speichert den Inhalt in einer Datenbank und baut beim Seitenaufruf für jeden Besucher erneut eine HTML-Seite zusammen. Das kostet Zeit, Rechenleistung und schafft Angriffsflächen.
Ein Headless CMS arbeitet nach einem anderen Prinzip. Es hat keine eigene Darstellungsschicht, verwaltet ausschließlich die Inhalte und stellt sie strukturiert zur Verfügung. Die Website entsteht separat, einmal, beim sogenannten Build-Prozess, und wird danach als fertiges, statisches HTML ausgeliefert. Kein Datenbankzugriff beim Laden, keine Wartezeiten.
Für Marketing-Teams bedeutet das vor allem: schnellere Ladezeiten mit direktem Einfluss auf Google-Rankings, ein überschaubares Sicherheitsrisiko und die Möglichkeit, Texte jederzeit zu ändern, ohne dass dafür jemand in den Code eingreifen muss.
Frontmatter: Strukturierte Metadaten sind kein Tech-Thema
Wer schon einmal ein Briefing für eine Anzeige geschrieben hat, kennt das Prinzip: Headline, Subline, Zielgruppe, Format und Platzierung werden separat definiert, bevor der eigentliche Text entsteht. Frontmatter ist dasselbe Prinzip, übertragen auf Website-Inhalte.
Als Kopfbereich eines Artikels steht Frontmatter ganz oben in der Inhaltsdatei, abgetrennt durch drei Bindestriche, und enthält die strukturierten Informationen zur Seite – also alles außer dem eigentlichen Text:
---
title: "Warum Ihr MarCom-Tech-Stack nicht liefert"
seo_title: "MarCom-Tech-Stack optimieren – Riptide Digital"
seo_description: "Ihr Marketing-Stack liefert keine Ergebnisse? Wir zeigen, woran es liegt."
author: "Dirk Koppert"
pubDate: 2026-03-08
tags: ["MarCom-Tech", "Datenstrategie"]
cta_label: "Discovery Call vereinbaren"
---Marketing-Verantwortliche sehen diesen Block nie direkt. Das CMS übersetzt ihn in ein normales Eingabeformular mit beschrifteten Feldern. Im Hintergrund schreibt das System diese Struktur in die Datei, und die Website liest sie beim Build-Prozess automatisch aus.
Der seo_title landet im <title>-Tag der Seite, dem was Google in den Suchergebnissen anzeigt. Die seo_description wird zur Meta Description unter dem Suchtreffer. Der author fließt in das strukturierte Daten-Markup ein, das Google und KI-Systeme lesen. Der cta_label steuert, was auf dem Button am Ende des Artikels steht.
Wer diese Felder konsequent befüllt, steuert aktiv, wie die Seite bei Google erscheint, wie KI-Systeme sie zitieren und welchen nächsten Schritt Lesende vollziehen. Das ist keine Entwickleraufgabe. Es ist Redaktionsarbeit.
Content Collections: Qualitätssicherung, bevor Fehler passieren
Stellen Sie sich vor, Ihr Team pflegt 30 Blog-Artikel im CMS. Bei 20 ist die Meta Description ausgefüllt, bei 10 nicht. Fünf Artikel haben kein Veröffentlichungsdatum, zwei keinen CTA. Alle 30 gehen live, inklusive der fehlerhaften.
Eine Content Collection mit Zod-Validierung macht genau das unmöglich.
Content Collections sind das Verwaltungssystem von Astro, dem Framework hinter modernen Jamstack-Websites, für Inhalte gleichen Typs. Alle Blog-Artikel bilden eine Collection, alle Leistungsseiten eine eigene, alle Case Studies eine weitere. Für jede Collection wird ein Schema definiert: eine Liste aller Pflichtfelder, ihrer erlaubten Formate und Grenzen.
Zod ist die Bibliothek, die dieses Schema durchsetzt. Fehlt einem Artikel beim Build-Prozess ein Pflichtfeld, zum Beispiel die Kurzzusammenfassung, die für KI-Suchantworten entscheidend ist, bricht der Build mit einer klaren Fehlermeldung ab. Der Artikel gelangt nicht live, bis das Feld korrekt befüllt ist.
Für Marketing-Verantwortliche ist das kein technisches Detail, sondern ein Qualitäts-Gate. Kein Inhalt wird veröffentlicht, der SEO-Anforderungen nicht erfüllt, egal ob aus Vergesslichkeit, Zeitdruck oder weil ein neues Teammitglied die Konventionen noch nicht kennt.
Was das für Ihren Redaktionsalltag bedeutet
Der Nutzen dieser Architektur zeigt sich nicht beim Setup, sondern im laufenden Betrieb.
Texte ändern ohne Entwickler. Weil Inhalt und Darstellung strikt getrennt sind, lassen sich Texte, Metadaten und Bilder jederzeit im CMS anpassen. Eine neue Kampagne starten, einen CTA aktualisieren, einen Preis korrigieren: Das passiert direkt im Browser, ohne dass ein Entwicklerticket gestellt werden muss.
SEO-Kontrolle ohne Agentur-Abhängigkeit. Title Tags und Meta Descriptions liegen als Frontmatter-Felder vor und können von jedem Redakteur mit dem nötigen Wissen direkt gepflegt werden. Die technische Umsetzung ist bereits erledigt. Was bleibt, ist redaktionelle Arbeit.
Nachvollziehbare Versionshistorie. Weil alle Inhalte als Textdateien in einem Git-Repository liegen, ist jede Änderung dokumentiert. Im Zweifel lässt sich jede ältere Version wiederherstellen, ohne CMS-Datenbankdump und ohne Backup-Diskussion mit dem Hoster.
Onboarding neuer Redakteure. Das CMS-Interface führt durch Pflichtfelder, zeigt Hinweise an und verhindert über das Schema unvollständige Einträge. Neue Teammitglieder können schneller eigenständig arbeiten, weil das System ihnen den Rahmen vorgibt.
Häufige Missverständnisse zwischen Marketing und Entwicklung
Drei Annahmen, die in der Zusammenarbeit regelmäßig zu Reibung führen:
„Das CMS macht SEO automatisch.”
Das CMS stellt die Struktur bereit, aber die Inhalte der SEO-Felder muss jemand schreiben. Ein seo_title-Feld, das leer bleibt oder generisch befüllt wird, bringt keine Ranking-Verbesserung. Technische Infrastruktur ersetzt keine redaktionelle Strategie.
„Wir können das später noch anpassen.” Schema-Änderungen nach dem Launch ziehen eine Migration aller bestehenden Inhalte nach sich. Was beim Setup zehn Minuten kostet, kostet nach 50 Artikeln Stunden. Anforderungen an das Frontmatter-Schema gehören ins Briefing, nicht ins Nachgespräch.
„Die Entwickler entscheiden, welche Felder es gibt.” Das Schema einer Content Collection ist eine redaktionelle Entscheidung, die in technische Sprache übersetzt wird. Welche Metadaten braucht jeder Artikel? Welche Felder sind Pflicht? Was muss in einem bestimmten Format vorliegen? Diese Fragen beantwortet das Marketing-Team. Die Entwicklung setzt die Antworten um.
FAQ
Was ist der Unterschied zwischen einem klassischen CMS und einem Headless CMS?
Ein klassisches CMS wie WordPress kombiniert Inhaltsverwaltung und Darstellung in einem System und baut Seiten live beim Aufruf zusammen. Ein Headless CMS verwaltet nur die Inhalte und stellt sie strukturiert bereit. Die Website wird separat als statisches HTML gebaut und ist dadurch schneller, sicherer und unabhängiger von der Datenbank.
Muss ich als Marketing-Verantwortlicher Code schreiben können?
Nein. Das CMS stellt alle Felder als Formular bereit. Was technisch als Frontmatter in einer Datei landet, erscheint im Interface als normales Eingabeformular mit Beschriftungen, Hinweisen und Pflichtfeldern.
Was passiert, wenn ich ein Pflichtfeld im CMS nicht ausfülle?
Bei einer korrekt konfigurierten Content Collection mit Zod-Validierung bricht der Build-Prozess ab. Der Artikel geht nicht live, bis das Feld korrekt befüllt ist. Das schützt die Qualität aller veröffentlichten Inhalte strukturell, nicht nur durch Vereinbarung.
Wer pflegt das Schema einer Content Collection?
Das Schema wird beim Aufbau der Website gemeinsam von Entwicklung und Marketing definiert. Welche Felder Pflicht sind, welche Formate gelten und welche Grenzen gesetzt werden, ist eine redaktionelle Entscheidung. Die technische Umsetzung übernimmt die Entwicklung.
Wie ändere ich einen Meta-Titel oder eine Meta-Description nachträglich?
Direkt im CMS unter dem entsprechenden Artikel, kein Entwickler nötig. Das Feld seo_title steuert, was Google in den Suchergebnissen anzeigt. Nach dem Speichern läuft der Deploy automatisch an; die Änderung ist innerhalb weniger Minuten live.
Was ist „Das Wesentliche” und warum ist es ein Pflichtfeld?
„Das Wesentliche” ist ein 40 bis 60 Wörter langer Absatz direkt unter der Überschrift, der die Kernfrage des Artikels ohne Umschweife beantwortet. KI-Systeme wie ChatGPT und Perplexity bevorzugen genau diese Struktur für ihre generierten Antworten. Als Pflichtfeld im Schema stellt es sicher, dass kein Artikel ohne dieses Element veröffentlicht werden kann.
Was kostet es, das Schema nachträglich zu erweitern?
Neue optionale Felder lassen sich jederzeit ergänzen. Alle bestehenden Artikel bleiben gültig, weil das Feld nicht als Pflichtfeld definiert ist. Neue Pflichtfelder hingegen erfordern eine Migration aller bestehenden Inhalte. Die Anforderungen sollten daher vollständig geklärt sein, bevor das Schema festgelegt wird.
Moderne Web-Infrastrukturen entfalten ihren Wert nicht beim Launch, sondern im Redaktionsalltag. Ob das funktioniert, entscheidet sich in den ersten Gesprächen zwischen Marketing und Entwicklung, nicht im Nachhinein.
In 30 Minuten analysieren wir gemeinsam,
welche Architektur zu Ihren Anforderungen passt.