Was ist ein Headless CMS? Ein Leitfaden für Entscheider

Das Problem mit klassischen CMS-Systemen

WordPress, Typo3, Joomla — die klassischen Content-Management-Systeme haben eines gemeinsam: Sie sind monolithisch. Das bedeutet, dass die Verwaltung der Inhalte und die Darstellung im Browser untrennbar miteinander verbunden sind. Sie erstellen eine Seite im Backend, und das CMS bestimmt, wie diese Seite im Frontend aussieht.

Das hat jahrelang funktioniert. Und für viele Anwendungsfälle funktioniert es immer noch. Aber die Anforderungen haben sich verändert.

Heute müssen Inhalte nicht nur auf einer Website erscheinen, sondern auch in einer App, in einem Newsletter, auf einem Digital Signage Display, in einer KI-gestützten Suche oder als Antwort in einem Chatbot. Ein monolithisches CMS, das Inhalte nur als fertige HTML-Seiten ausgeben kann, stößt hier an seine Grenzen.

Was Headless bedeutet — wörtlich

"Headless" bedeutet übersetzt "kopflos". Der "Kopf" ist in diesem Kontext das Frontend — also alles, was der Nutzer im Browser sieht. Ein Headless CMS liefert keine fertigen Webseiten. Es liefert strukturierte Daten über eine API.

Stellen Sie sich ein Headless CMS wie eine intelligente Datenbank vor: Sie speichern Ihre Inhalte — Texte, Bilder, Produkte, Referenzen, was auch immer — in strukturierter Form. Und dann entscheiden Sie, wie und wo diese Inhalte dargestellt werden. Die Website ist nur ein möglicher Kanal. Die App ist ein weiterer. Ein KI-Agent, der Ihre Inhalte ausliest, ist ein dritter.

Ein konkretes Beispiel

Nehmen wir ein Webinar. In einem klassischen CMS erstellen Sie eine "Webinar-Seite" mit Titel, Beschreibung, Datum und Referenten. Diese Seite existiert genau einmal, in genau einem Format.

In einem Headless CMS definieren Sie ein "Webinar" als Datenstruktur: Titel (Text), Beschreibung (Rich Text), Datum (Datetime), Referent (Referenz auf einen Personen-Datensatz), Kategorie (Auswahl), Aufzeichnung (Video-URL). Diese Daten können dann überall verwendet werden:

• Auf der Website als detaillierte Webinar-Seite
• In einer Übersicht als kompakte Karte
• Im Newsletter als Vorschau mit Anmeldelink
• In der Google-Suche als strukturiertes Event (JSON-LD)
• Von einem KI-Chatbot als Antwort auf "Welche Webinare gibt es zum Thema X?"

Die Daten werden einmal gepflegt und überall verwendet. Das ist der Kern von Headless.

Wie die Architektur funktioniert

Ein Headless CMS besteht im Wesentlichen aus drei Schichten:

1. Das Content-Backend (das Headless CMS selbst)

Hier werden Inhalte erstellt, strukturiert und verwaltet. Die Redaktion arbeitet in einem eigenen Interface — je nach System ein Web-Dashboard, ein Studio oder ein Admin-Panel. Beliebte Headless CMS-Systeme sind Sanity, Storyblok, Contentful, Strapi oder Nuxt Content.

2. Die API (die Verbindung)

Das CMS stellt seine Inhalte über eine API bereit — in der Regel REST oder GraphQL. Das Frontend fragt die Inhalte über diese API ab. Das ist der entscheidende Unterschied zum monolithischen CMS: Die Daten werden nicht als fertige HTML-Seiten ausgeliefert, sondern als strukturierte Datensätze (JSON).

3. Das Frontend (der "Kopf")

Das Frontend ist eine eigenständige Anwendung — gebaut mit einem modernen Framework wie Nuxt, Next.js oder Astro. Es holt sich die Daten vom CMS, rendert sie zu HTML und liefert sie an den Browser aus. Das Frontend kann server-seitig gerendert werden (SSR) für optimale SEO-Performance, statisch generiert werden (SSG) für maximale Geschwindigkeit oder eine Kombination aus beidem nutzen (Hybrid Rendering).

Headless vs. Traditionell: Der Unterschied in der Praxis

Performance

Bei sauberer Umsetzung laden Headless-Websites deutlich schneller als traditionelle CMS-Websites. Der Grund: Das Frontend ist eine schlanke, optimierte Anwendung ohne den Overhead eines monolithischen Systems. Weniger Plugin-Konflikte, gezieltere Datenbankabfragen, kein Template-Overhead.

In der Praxis bedeutet das bessere Core Web Vitals — die Metriken, die Google für das Ranking heranzieht. Schnellere Ladezeiten führen zu besseren Rankings, niedrigeren Absprungraten und höheren Conversion-Raten.

Sicherheit

Ein Headless CMS hat keine öffentlich erreichbare Admin-Oberfläche auf Ihrem Server. Es gibt kein /wp-admin, das angegriffen werden kann. Die Content-Verwaltung läuft in einem separaten, geschützten System. Das Frontend ist eine statische oder server-gerenderte Anwendung ohne direkte Datenbankverbindung.

Das eliminiert ganze Kategorien von Sicherheitsrisiken, die bei WordPress und Co. regelmäßig zu Problemen führen: SQL-Injection, Plugin-Vulnerabilities, Brute-Force-Angriffe auf das Login.

Flexibilität

Mit einem Headless CMS können Sie das Frontend-Framework frei wählen und bei Bedarf wechseln — ohne die Inhalte anfassen zu müssen. Sie können ein Redesign durchführen, ohne das CMS zu migrieren. Sie können eine App anbinden, ohne Inhalte zu duplizieren. Sie können einen neuen Kanal erschließen, ohne das bestehende System zu verändern.

Redaktionserlebnis

Hier gibt es Unterschiede zwischen den Anbietern. Systeme wie Storyblok bieten einen visuellen Editor, in dem Redakteure ihre Seiten per Drag-and-Drop zusammenbauen — ähnlich wie bei einem Page-Builder in WordPress. Andere Systeme wie Sanity setzen auf ein strukturiertes, formularbasiertes Interface, das weniger visuell, dafür aber flexibler und konsistenter ist.

Wichtig: Das Redaktionserlebnis in einem Headless CMS kann genauso intuitiv sein wie in WordPress — es muss nur richtig konfiguriert werden. Ein schlecht aufgesetztes Headless CMS ist für Redakteure frustrierender als ein gut konfiguriertes WordPress. Die initiale Einrichtung macht den Unterschied.

Für wen ist ein Headless CMS die richtige Wahl?

Gut geeignet, wenn:

Sie mehrere Kanäle bedienen. Wenn Ihre Inhalte nicht nur auf der Website, sondern auch in einer App, einem Newsletter, einer Suche oder anderen Systemen erscheinen sollen, spielt ein Headless CMS seine Stärken aus.

Performance entscheidend ist. Wenn Ladezeiten direkt Ihren Umsatz beeinflussen — etwa im E-Commerce oder bei Lead-Generierung — bietet die Headless-Architektur messbare Vorteile.

Sie ein Redesign planen, ohne Inhalte zu verlieren. Wenn Sie Ihr Frontend komplett neu aufsetzen wollen, ohne Monate für eine CMS-Migration einzuplanen, ist die Entkopplung von Content und Darstellung der richtige Ansatz.

Ihr Team technisch versiert ist (oder einen Entwickler hat). Ein Headless CMS erfordert Entwicklungskompetenz für das Frontend. Ohne einen Entwickler, der Nuxt, Next.js oder ein vergleichbares Framework beherrscht, kommen Sie nicht weit.

Sie langfristig denken. Die initiale Einrichtung eines Headless-Systems dauert länger als eine WordPress-Installation. Aber die langfristigen Kosten für Wartung, Sicherheit und Weiterentwicklung sind in der Regel niedriger.

Weniger geeignet, wenn:

Sie eine einfache Unternehmenswebsite mit 5-10 Seiten brauchen. Für eine simple Corporate-Website ohne besondere Anforderungen ist der Headless-Ansatz Over-Engineering.

Ihre Redakteure maximale Eigenständigkeit brauchen. Wenn Ihre Redakteure ohne Entwickler-Unterstützung neue Seitentypen anlegen, Layouts ändern und Plugins installieren wollen, bietet ein traditionelles CMS mehr Freiheit — auf Kosten der Konsistenz.

Kein Budget für die initiale Entwicklung da ist. Ein Headless-Setup erfordert eine initiale Investition in die Architektur. Die CMS-Kosten selbst reichen von 0 Euro (Open Source wie Strapi oder Payload) bis zu mehreren tausend Euro pro Monat (Enterprise-Pläne von Contentful oder Storyblok). Dazu kommen die Entwicklungskosten für das Frontend. Wenn das Budget nur für ein WordPress-Theme reicht, ist das die ehrlichere Wahl.

Was ich aus der Praxis kenne

Ich habe mit HRnetworx einen kompletten Plattform-Relaunch auf Headless-Basis umgesetzt — Sanity als CMS, Nuxt.js als Frontend, Supabase für die User-Verwaltung. Die Entscheidung für Headless fiel, weil die Plattform mehr ist als eine Website: Sie ist ein System, das Webinare verwaltet, Nutzer registriert und Content über verschiedene Kanäle ausspielt.

Die eigene Website, auf der Sie diesen Artikel lesen, läuft ebenfalls auf einem Headless-Stack: Nuxt Content als Git-basiertes CMS mit Server-Side Rendering. Für eine entwicklergeführte Website mit Blog ist das ein schlankes, performantes Setup ohne externen CMS-Service.

Beide Projekte nutzen die Headless-Architektur — aber mit völlig unterschiedlichen Tools und Ansätzen. Und genau das ist der Punkt: Headless ist kein Produkt, sondern ein Architekturprinzip. Die richtige Umsetzung hängt vom konkreten Anwendungsfall ab.

Die wichtigsten Headless CMS im Überblick

Sonderfall: Nuxt Content ist kein klassisches Headless CMS, sondern ein dateibasiertes Content-Modul für das Nuxt-Framework. Es liest Markdown-Dateien aus dem Dateisystem und stellt sie als querybare Daten bereit — ohne eigene Admin-Oberfläche und ohne externe API. Für entwicklergeführte Websites und Blogs ist es eine schlanke Alternative, die ohne externen CMS-Service auskommt. Diese Website nutzt genau dieses Setup.

Fazit

Ein Headless CMS ist kein Ersatz für WordPress — es ist eine andere Architektur für andere Anforderungen. Wenn Sie mehrere Kanäle bedienen, Performance ernst nehmen und bereit sind, in eine saubere Architektur zu investieren, ist Headless die zukunftssicherere Wahl.

Wenn Sie eine einfache Website brauchen und Ihre Redakteure maximale Eigenständigkeit erwarten, ist ein traditionelles CMS nach wie vor eine valide Option.

Die Frage ist nicht "Headless oder nicht?" — die Frage ist: Was sind Ihre konkreten Anforderungen, und welche Architektur bildet diese am besten ab?