Was ist der Unterschied zwischen einem Headless CMS und einem klassischen CMS?

Ein klassisches CMS verwaltet Inhalte und liefert die fertige Website in einem System aus. Ein Headless CMS trennt diese Aufgaben: Es kümmert sich nur um die Inhaltsverwaltung und gibt die Daten über eine API aus. Das Frontend – die sichtbare Website oder App – wird separat gebaut. Der Gewinn ist Flexibilität bei der Darstellung und Kanalunabhängigkeit. Der Preis ist mehr Komplexität und ein höherer Entwicklungsaufwand.

Kann ich WordPress als Headless CMS nutzen?

Ja. WordPress bringt eine JSON-API mit, über die Inhalte ausgelesen werden können. Das Frontend wird dann mit einem separaten Tool gebaut – zum Beispiel Astro. Der Vorteil: Das bestehende WordPress-Backend und die Redaktions-Gewohnheiten bleiben erhalten. Der Nachteil: WordPress ist ursprünglich nicht für den Headless-Einsatz gebaut, was in manchen Bereichen spürbar ist.

Für welche Projekte lohnt sich ein Headless CMS?

Headless lohnt sich vor allem dann, wenn ihr dieselben Inhalte auf mehreren Kanälen ausspielen wollt, wenn Performance kritisch ist oder wenn euer Entwicklungsteam das Frontend unabhängig vom CMS bauen soll. Für eine einfache Website mit einem Redakteur und einem Ausspielkanal ist Headless dagegen oft zu aufwendig.

Welche Headless-CMS-Systeme sind am verbreitetsten?

Zu den meistgenutzten Systemen gehören Storyblok (SaaS, visueller Editor), Sanity (SaaS, flexibles Datenschema), Strapi und Directus (beide Open Source). Wer bereits WordPress im Einsatz hat, kann es auch headless betreiben. Welches System passt, hängt von Teamgröße, Budget und DSGVO-Anforderungen ab.

Was ist ein Headless CMS? Einfach erklärt

Ein Headless CMS ist ein Content-Management-System, das Inhalte speichert und über eine Programmierschnittstelle (API) bereitstellt, ohne selbst eine Website auszuliefern. Das sichtbare Frontend – also das, was Besucher im Browser sehen – wird separat entwickelt. Dieselben Inhalte lassen sich so ohne Mehraufwand über mehrere Kanäle ausspielen: Website, App, Newsletter.

Wer im Netz nach „Headless CMS” sucht, findet meistens Anbieter-Marketing. Dieser Artikel nicht. Hier geht es darum, was hinter dem Begriff steckt – ohne Werbung, ohne Hype.

Was ist ein Headless CMS?

Bei einem klassischen CMS wie WordPress sind Inhaltsverwaltung und Websiteauslieferung in einem System gebündelt. Ihr schreibt einen Beitrag, WordPress erzeugt daraus eine fertige HTML-Seite und liefert sie aus. Praktisch – aber es koppelt eure Inhalte an eine bestimmte Darstellungslogik und an genau einen Ausspielkanal.

„Headless” bedeutet wörtlich „ohne Kopf”. Der Kopf ist das Frontend – die sichtbare Website. Ein Headless CMS liefert nur den Body: die Inhalte, strukturiert in einem Format wie JSON, bereitgestellt über eine API. Das Frontend – die Seite, die Besucher sehen – wird von einem separaten System gebaut.

Das ist kein Allheilmittel. Es ist eine Architekturentscheidung mit klaren Vorteilen auf der einen und echten Kosten auf der anderen Seite.

Wie funktioniert ein Headless CMS?

Klassisches CMS: alles in einem System

In einem klassischen Setup läuft beides auf demselben Server. Ein Redakteur schreibt im Backend, das CMS baut daraus HTML und liefert es aus. Für einen Ausspielkanal – die Website – funktioniert das reibungslos und ohne zusätzliche Komplexität. Ihr braucht kein zweites System, keinen definierten Veröffentlichungsweg, keine API-Anbindung.

Headless CMS: getrennte Schichten

Bei einem Headless-Setup gibt es zwei unabhängige Schichten:

Inhaltsverwaltung (das CMS): Hier pflegt ein Redakteur Texte, Bilder und Metadaten. Das CMS speichert sie strukturiert – zum Beispiel als JSON-Objekt mit Feldern für Titel, Teaser, Bild-URL und Veröffentlichungsdatum.

Frontend: Ein Entwickler baut eine separate Website oder App, die sich die Inhalte über die API des CMS holt und daraus HTML erzeugt. Das kann Astro sein, Next.js, React Native oder ein beliebiges anderes Framework.

Der Ablauf in der Praxis: Redakteur erstellt Inhalt im CMS → CMS speichert ihn → Frontend ruft ihn per API ab → Besucher sieht die fertige Seite.

Das klingt aufwendiger – und das ist es auch. Der Gewinn liegt darin, dass das Frontend frei wählbar ist und dieselben Inhalte ohne Mehraufwand über mehrere Kanäle ausgespielt werden können.

Vorteile und Grenzen

Headless wird oft als reiner Fortschritt dargestellt. Das ist es nicht – es ist ein Tausch. Was ihr gewinnt, und wofür ihr es bezahlt:

Was ihr gewinnt

Kanalunabhängigkeit. Einmal gepflegte Inhalte lassen sich über API überall ausspielen: Website, mobile App, Newsletter, Digital Signage, Voice-Interface.

Freie Frontend-Wahl. Das Frontend kann in jeder Technologie entwickelt werden. Kein CMS schreibt vor, wie die Darstellung auszusehen hat oder welche Templates verfügbar sind.

Bessere Performance. Da das CMS keine Seiten dynamisch generiert, kann das Frontend als statische Site ausgeliefert werden – was deutlich schneller ist und Hosting erheblich einfacher macht.

Unabhängige Entwicklung. CMS und Frontend können getrennt voneinander weiterentwickelt und skaliert werden. Ein Team arbeitet am Frontend, ohne das CMS zu berühren.

Was ihr dafür in Kauf nehmt

Mehr Systemkomplexität. Zwei Systeme statt einem. Ein Veröffentlichungsweg muss definiert werden. Updates müssen für beide Systeme eingeplant werden. Wenn das CMS ausfällt, fällt die Inhaltspflege aus.

Höherer Entwicklungsaufwand. Das Frontend muss vollständig gebaut werden. Es gibt kein Themes-System mehr, auf das man zurückgreifen kann.

Kein klassisches WYSIWYG per Default. Manche Systeme – Storyblok zum Beispiel – bieten heute einen visuellen Editor mit Live-Vorschau. Aber das ist nicht überall Standard und erfordert zusätzliche Konfiguration.

Für einen ehrlichen Vergleich der verschiedenen Headless-Ansätze – dediziertes SaaS-CMS, WordPress headless, Git-basiert, Self-Hosted – lohnt sich der Headless CMS Vergleich.

Für wen sich Headless eignet

Drei Szenarien, in denen Headless die richtige Wahl ist:

Mehrere Ausspielkanäle. Wenn dieselben Inhalte auf einer Website, in einer App und auf Digital-Signage-Displays erscheinen sollen, ohne mehrfach gepflegt zu werden. Das ist der stärkste Grund für Headless.

Performance als Anforderung. Wenn Ladezeiten geschäftskritisch sind – bei hohem Traffic, bei E-Commerce-Sites oder bei Projekten, bei denen Core Web Vitals direkt auf Conversion einzahlen.

Frontend-Unabhängigkeit. Wenn euer Entwicklungsteam das Frontend in einer bestimmten Technologie bauen will und das CMS nur Daten liefern soll – ohne Einschränkungen durch Template-Systeme oder CMS-eigene Rendering-Logik.

Wenn keines dieser Szenarien auf euch zutrifft – wenn ihr eine Website mit einem Redakteur und einem Ausspielkanal betreibt – ist Headless meist überdimensioniert. Ein klassisches CMS ist dann die ehrlichere und günstigere Wahl.

Bekannte Headless-CMS-Systeme

Ein kurzer Überblick ohne Kaufempfehlung. Für eine ausführliche Einschätzung mit Kosten, DSGVO-Bewertung und konkreten Empfehlungen je nach Projekttyp lohnt sich der Headless CMS Vergleich.

Storyblok – SaaS aus Wien, mit einem visuell editierbaren Frontend (Visual Editor). Beliebt bei Agenturen und Marketingteams, die Redakteuren eine WYSIWYG-Oberfläche bieten wollen.

Sanity – SaaS aus Oslo, mit einem sehr flexiblen, schemabasierten Ansatz. Gut für Projekte mit komplexen, stark individualisierten Inhaltsstrukturen und eigenem Entwicklerteam.

Strapi – Open Source, selbst gehostet oder als Managed-Lösung. Gibt vollständige Kontrolle über Datenstruktur und Hosting – DSGVO-konformes EU-Hosting inklusive.

Directus – Open Source, selbst gehostet oder SaaS. Directus legt sich über eine bestehende SQL-Datenbank, statt eine eigene Struktur vorzugeben. Gut für datengetriebene Projekte.

WordPress headless – WordPress als reines Backend mit JSON-API. Kein neues System lernen, bestehende Redaktionsprozesse behalten. Wie das konkret in Kombination mit Astro als Frontend funktioniert, beschreiben wir in Headless WordPress mit Astro.

Wenn ihr ein Headless-Projekt plant – von der Systemwahl über die API-Integration bis zum Frontend-Aufbau – helfen wir gerne weiter: Headless-CMS-Entwicklung.