Headless CMS: Was es ist, wie es funktioniert und für wen es sich lohnt

In einem klassischen CMS wie WordPress sind Backend und Frontend eng miteinander verzahnt. Das CMS verwaltet Inhalte und rendert gleichzeitig die HTML-Seiten, die der Browser anzeigt. Das ist bequem für einfache Websites und ermöglicht Redakteuren eine WYSIWYG-Vorschau direkt im System. Der Nachteil: Inhalte sind an dieses eine Frontend gebunden. Wer dieselben Inhalte auch in einer App, einem Voice-Assistant oder einem Kassensystem nutzen will, muss duplizieren oder aufwändige Schnittstellen bauen.

Ein Headless CMS macht genau an dieser Stelle einen grundlegenden Schnitt. Es trennt den »Body« (die Inhaltsverwaltung) vom »Head« (dem Frontend, das Inhalte darstellt). Das CMS speichert und verwaltet Inhalte strukturiert und stellt sie über eine API bereit – typischerweise REST oder GraphQL. Das Frontend kann dann eine beliebige Technologie sein: Next.js, Nuxt, Gatsby, eine native App, eine Sprachausgabe oder ein Digital-Signage-System. Alle Kanäle greifen auf denselben Content-Pool zu.

Das klingt nach reiner Freiheit – und ist es in gewisser Weise auch. Aber diese Freiheit hat ihren Preis: Wer das Frontend selbst bauen muss, braucht Entwickler, die das können. Die einfache WordPress-Logik »Theme aktivieren, fertig« gilt im Headless-Kontext nicht mehr. Für kleine Websites ohne Multichannel-Anforderungen ist diese Komplexität in den meisten Fällen nicht gerechtfertigt.

Der Headless-CMS-Markt ist vielfältig. Die wichtigsten Anbieter unterscheiden sich in Hosting-Modell (SaaS vs. Self-Hosted), Preis, Entwicklerfreundlichkeit und Redakteursoberfläche.

Contentful ist der Platzhirsch unter den SaaS-Lösungen: ausgereifte API, exzellente Dokumentation, globales CDN. Nachteil: teuer bei wachsendem Inhaltsvolumen (ab ~300 $/Monat für Teams). Sanity punktet mit dem realtime-fähigen GROQ-Query-System und einer sehr flexiblen Content-Modellierung – beliebt bei Agenturen und Entwicklern, die maximale Kontrolle wollen. Storyblok bietet als einziges System eine echte visuelle Vorschau (Visual Editor) im Headless-Kontext – ein erheblicher Vorteil für Redakteure, die WYSIWYG gewohnt sind.

Strapi ist die führende Open-Source-Lösung zum Selbst-Hosten: kostenlos, sehr anpassbar, aber mit mehr Betriebsaufwand verbunden. Directus ist eine flexible Datenbankoberfläche mit CMS-Funktionen, besonders attraktiv wenn das Datenmodell komplex oder ungewöhnlich ist. Für KMU-Projekte mit eigenem Hosting ist Strapi oder Directus oft der pragmatischste Einstieg; für Enterprise-Anforderungen mit SLA-Garantien sind Contentful oder Storyblok die sichere Wahl.

Eine Migration von WordPress zu einem Headless-CMS ist kein triviales Projekt. Wer heute 200 WordPress-Seiten hat, hat auch 200 Seiten mit individuellen Shortcodes, Custom Fields, möglicherweise Page Builder-Layouts und Plugin-abhängigen Funktionen. Alle diese Strukturen müssen in das Contentmodell des neuen Systems übersetzt werden – und das ist manuell und zeitaufwändig.

Die realistische Planung einer solchen Migration: Inhaltsanalyse und Contentmodellierung (2–4 Wochen), parallele Entwicklung des neuen Frontends (4–12 Wochen je nach Komplexität), Content-Migration und Qualitätssicherung (2–4 Wochen), Redirect-Management und SEO-Absicherung (1–2 Wochen). Insgesamt sind für eine mittelgroße Website 3–6 Monate ein realistischer Rahmen. Wer das unterschätzt, riskiert halbfertige Migrationsprojekte, die teurer werden als ein Neubau.

Empfehlung für die Praxis: Migration nicht als Lift-and-Shift planen, sondern als Neustrukturierung des Contentmodells nutzen. Inhalte, die schon in WordPress schlecht strukturiert waren, werden im Headless-CMS nicht automatisch besser – die Architekturarbeit muss vorher stattfinden.