WordPress reicht für viele Projekte. Das ist keine Kritik – es ist eine sachliche Einschätzung. Wenn ein Unternehmen eine Website betreiben will, Redakteure ohne Entwickler-Zugang Texte pflegen sollen und das Frontend kein Sonderprojekt ist, macht WordPress nach wie vor Sinn. Aber wenn mehrere Kanäle, mehrere Teams oder mehrere Frontends ins Spiel kommen, stoßt ihr schnell an Grenzen. Das Theme bestimmt die Struktur. Der PHP-Stack bestimmt das Rendering. Und wenn die mobile App dieselben Inhalte braucht wie die Website, fängt das Basteln an.
Was Headless CMS bedeutet – und was es nicht ist
Ein Headless CMS trennt Content-Verwaltung und Content-Darstellung. Das CMS ist API-first: Es speichert strukturierte Inhalte und liefert sie über eine API aus – JSON, GraphQL, REST. Was daraus gemacht wird, entscheidet ihr selbst.
Das "Headless" ist wörtlich gemeint: kein "Head", kein Frontend. Das CMS rendert keine HTML-Seiten. Es verwaltet Daten. Wer, wie und womit diese Daten gerendert werden, ist vollständig entkoppelt.
Im traditionellen CMS – WordPress, TYPO3, Drupal – sind Backend und Frontend eng gekoppelt. Das Template-System des CMS bestimmt, wie Inhalte aussehen. Ihr könnt es anpassen, aber ihr arbeitet immer innerhalb der Architektur des CMS. Beim Headless CMS ist das Frontend vollständig frei: Next.js, Nuxt, Astro, eine native iOS-App, ein Digital-Signage-System – alles, was eine API konsumieren kann.
Die Vorteile: Freiheit, Performance, Multi-Channel
Frontend-Freiheit ist der größte Vorteil. Das Entwicklungsteam arbeitet mit dem Framework, das die beste Developer Experience und Performance bietet – nicht mit dem, das das CMS erzwingt. Für moderne Web-Projekte bedeutet das meistens Next.js oder Astro mit statischer Generierung oder Server-Side Rendering.
Performance folgt daraus. Statisch generierte Sites, die aus einem Headless CMS gebaut werden, sind schnell. Kein PHP-Rendering zur Anfrage-Zeit, kein Datenbankaufruf pro Seitenaufruf. Der Content wird zum Build-Zeitpunkt oder über ISR (Incremental Static Regeneration) aufgebaut.
Multi-Channel ist der Use Case, bei dem traditionelle CMS am schnellsten an Grenzen stoßen. Wenn dieselben Produktbeschreibungen auf der Website, in der App, im Newsletter und auf einem Kiosk-Terminal erscheinen sollen, braucht ihr eine API, nicht ein Template-System. Headless CMS liefert das ohne Workarounds.
Skalierbarkeit: Das CMS skaliert unabhängig vom Frontend. Traffic-Spitzen treffen den CDN, nicht den CMS-Server.
Die Nachteile: Erhöhte Komplexität und höherer Dev-Aufwand
Headless ist kein Allheilmittel. Die Nachteile sind real.
Komplexität: Statt eines Systems habt ihr zwei: CMS und Frontend. Zwei Systeme zu betreiben, zu warten und zu deployen ist aufwändiger.
Live Preview ist out of the box bei den meisten Headless CMS schwieriger als in traditionellen Systemen. WordPress zeigt Redakteuren sofort, wie eine Seite aussieht. In Headless-Setups braucht ihr eine dedizierte Preview-Umgebung, die den Redakteur-Workflow simuliert. Das ist lösbar, aber es ist zusätzlicher Aufwand beim Setup.
Initiale Entwicklungszeit ist höher. Bei WordPress-mit-Theme könnt ihr schnell starten. Ein Headless-Setup mit eigenem Frontend kostet mehr Zeit in der Einrichtung – Zeit, die sich langfristig auszahlt, aber kurzfristig Kosten verursacht.
Sanity.io: Für projekte mit individuellem Content-Modell
Sanity ist der Headless-CMS-Spieler, der am meisten Flexibilität bei der Schema-Definition bietet. Schemas werden in JavaScript definiert – kein GUI, keine Checkbox-Konfiguration, sondern Code. Das bedeutet: vollständige Kontrolle über die Datenstruktur, versionierbar mit Git, reproduzierbar.
GROQ (Graph-Relational Object Queries) ist Sanitys proprietäre Query-Sprache. Sie ist mächtiger als einfaches REST und ermöglicht komplexe Joins und Filter ohne multiple API-Calls. Für Teams, die damit vertraut sind, ist es ein Produktivitätsvorteil. Für Teams, die GraphQL-Kenntnisse mitbringen, ist die Lernkurve kurz – Sanity unterstützt auch GraphQL.
Portable Text ist Sanitys Antwort auf Rich Text: ein strukturiertes, portables Format für formatierten Text, das sich in beliebigen Frontends rendern lässt. Besser als roher HTML-Blob, wartbarer als reiner Markdown.
Echtzeit-Kollaboration: Mehrere Redakteure können gleichzeitig an denselben Dokumenten arbeiten – ähnlich Google Docs. Für Teams mit mehreren Content-Editors ist das ein echter UX-Vorteil.
Für wen: Sanity ist die richtige Wahl für Projekte mit komplexen, individuellen Content-Modellen, Teams die Code-first-Definitionen bevorzugen und Projekte, bei denen mehrere Frontends denselben Content nutzen. Auch ideal wenn Echtzeit-Preview und kollaboratives Editing wichtig sind.
Strapi: Open Source, self-hosted, maximum Kontrolle
Strapi ist das einzige vollständig Open-Source-CMS in dieser Gruppe – und das bedeutet: ihr könnt es selbst hosten, auf eigenem Server, in eigener Cloud-Umgebung, ohne monatliche Lizenzgebühren für den Content-Storage.
Die API-Definition erfolgt über ein UI oder Code. Content Types werden grafisch oder programmatisch definiert. Die API – REST oder GraphQL – wird automatisch generiert. Für Entwickler mit Backend-Erfahrung ist Strapi schnell produktiv.
Plugin-Ökosystem: Strapi hat eine aktive Community und ein wachsendes Plugin-System. Von E-Mail-Integrationen bis zu benutzerdefinierten Feldern.
SQL und NoSQL: Strapi unterstützt PostgreSQL, MySQL, SQLite und MongoDB. Für Teams, die ihre bestehende Datenbankinfrastruktur weiternutzen wollen, ist das ein Vorteil.
Für wen: Strapi ist die richtige Wahl für Projekte, bei denen Datenkontrolle und Self-Hosting entscheidend sind – Compliance-Anforderungen, sensible Daten, oder einfach der Wunsch, keine monatlichen SaaS-Kosten zu haben. Auch gut für Unternehmen, die inhouse Developer haben und die Plattform eigenständig betreiben wollen.
Der Nachteil: Selbst betreiben bedeutet selbst warten. Updates einspielen, Server absichern, Backups managen – das ist Arbeit, die bei SaaS-Optionen entfällt.
Contentful: Enterprise-grade, mit entsprechendem Preisschild
Contentful ist der Enterprise-Player im Headless-CMS-Markt. Ausgereiftes UI, breites Integrations-Ökosystem, zuverlässige Infrastruktur, globales CDN. Viele der größten Marken weltweit setzen Contentful ein.
Lokalisierung ist eine Stärke von Contentful: Multi-Language-Management mit differenzierten Rollen und Workflows für übersetzte Inhalte. Für internationale Projekte mit komplexen Übersetzungsprozessen ist das relevant.
Das Ökosystem ist groß: Hunderte von Integrationen, aktive Partner-Community, ausgereifte SDKs für alle gängigen Frameworks.
Für wen: Contentful ist für Enterprise-Projekte sinnvoll, bei denen hohe Verfügbarkeitsgarantien, Support-Level-Agreements, komplexe Multi-Locale-Anforderungen und ein großes Content-Team vorhanden sind.
Der Haken: Pricing bei Scale ist signifikant. Das kostenlose Tier ist für Proof-of-Concepts ausreichend. Sobald Content-Volumen, Nutzer oder API-Calls wachsen, steigen die Kosten schnell. Für mittelgroße Projekte ohne Enterprise-Budget ist Contentful oft oversized.
Wann Headless wirklich sinnvoll ist
Fünf Signale, dass ihr über Headless nachdenken solltet:
- Mehrere Frontends nutzen denselben Content: Website, App, Digital Signage, API-Partner
- Performance ist kritisch und ein Page-Builder auf PHP-Basis ist keine akzeptable Lösung
- Das Entwicklungsteam will mit modernen JavaScript-Frameworks arbeiten, nicht mit CMS-Templates
- Content-Operations sind komplex: mehrere Teams, mehrere Sprachen, strukturierte Approval-Workflows
- Langfristige Skalierbarkeit ist wichtiger als kurzfristige Time-to-Market
Wann WordPress die bessere Wahl bleibt
Headless ist keine Religion. Es gibt Projekte, bei denen ein klassisches CMS die bessere Entscheidung ist:
- Kleine Websites mit einfachem Content, das ein einzelner Redakteur pflegt
- Projekte mit engem Budget und kurzem Timeline, bei denen ein Theme ausreicht
- Blogs und Content-Sites, bei denen WordPress-SEO-Plugins wie Yoast echten Mehrwert bringen
- Projekte, bei denen das Team WordPress kennt und kein headless Setup lernen will
Die Ehrlichkeit ist wichtig: Headless kostet mehr in der Einrichtung. Wer das Budget nicht hat oder es nicht braucht, sollte es nicht erzwingen.
Die Technologieentscheidung sollte von den Anforderungen getrieben werden – nicht vom Trend. Wenn ihr vor dieser Entscheidung steht und eine zweite Meinung braucht, welche Architektur für euer Projekt wirklich passt, ist ein technisches Beratungsgespräch der schnellste Weg zu einer fundierten Entscheidung, die ihr in drei Jahren nicht bereut.