Was ist ein Headless CMS und wann lohnt es sich wirklich?

Das Entscheidungsdilemma

In keinem anderen Bereich der Webentwicklung wird gerade so viel mit Fachbegriffen geworfen wie bei Content-Management-Systemen. Headless, API-First, Decoupled, Jamstack – wer diese Begriffe zum ersten Mal hört, hat schnell das Gefühl, mit einem klassischen CMS auf der Verliererseite zu stehen. Doch das Gegenteil ist oft wahr. Ein klassisches CMS wie WordPress kombiniert Backend, wo Inhalte gepflegt werden, und Frontend, wie sie ausgespielt werden, in einem System. Headless trennt diese beiden Ebenen konsequent: Das CMS verwaltet ausschließlich Inhalte und stellt sie über eine API bereit, das Frontend holt sich die Daten selbst. Headless CMS ist eine legitime Architektur, aber sie löst spezifische Probleme – und nur wenn diese Probleme wirklich vorhanden sind, rechnet sich der zusätzliche Aufwand.

Wann sich Headless CMS lohnt

• Multichannel-Publishing: Inhalte sollen gleichzeitig auf Website, App, Digital Signage und weiteren Kanälen ausgespielt werden
• Hochleistungs-Frontend: Ein React- oder Next.js-Frontend soll maximale Performance und Developer Experience bieten
• Großes Entwickler-Team: Frontend- und Backend-Entwickler arbeiten unabhängig voneinander und wollen entkoppelte Workflows
• API-First-Anforderungen: Inhalte werden von Drittanwendungen oder Microservices konsumiert
• Sehr große Content-Mengen: Tausende Artikel, Produkte oder Seiten, die strukturiert und skalierbar verwaltet werden müssen
• Marken-Konsistenz über Plattformen hinweg: Derselbe Inhalt muss auf jedem Kanal identisch erscheinen
• Hohe Skalierungsanforderungen: CDN-basiertes Hosting mit statischer Generierung für globale Performance

Wann ein klassisches CMS besser ist

• Kleines Budget: Headless erfordert erheblich mehr Entwicklungsaufwand, ohne dediziertes Dev-Team wird es teuer
• Kein Entwickler-Team vorhanden: Klassische CMS wie WordPress oder TYPO3 laufen weitgehend ohne Entwickler im Alltag
• Einfache Website oder Blog: Für eine 20-seitige Unternehmenswebsite ist Headless massiv überdimensioniert
• Schnelle Umsetzung nötig: Headless-Projekte dauern von ersten Designs bis zum Launch deutlich länger
• WYSIWYG-Anforderung: Redakteure wollen sehen, wie der Inhalt live aussieht – das ist bei Headless deutlich komplexer
• Plugin-Ökosystem wichtig: WordPress hat mehr als 60.000 Plugins, Headless hat davon keines
• Wartung in Eigenregie: Klassische CMS lassen sich von technisch versierten Nicht-Entwicklern pflegen

Fünf Entscheidungsfragen

1. Haben Sie mehr als einen Ausgabekanal, also Website plus App oder weitere? Wenn ja, ist Headless sinnvoll, wenn nein, reicht ein klassisches CMS. 2. Haben Sie ein dediziertes Frontend-Entwickler-Team, das React oder Ähnliches beherrscht? Wenn nein, führt Headless zu massiven Zusatzkosten. 3. Brauchen Ihre Redakteure eine Live-Preview und einfache Bedienung ohne technisches Wissen? Dann ist ein klassisches CMS oder ein Headless-Anbieter mit gutem Preview-System wie Storyblok oder Sanity sinnvoller. 4. Ist Performance auf globalem Level mit CDN und statischer Generierung eine harte Anforderung? Dann ist Headless in Kombination mit Next.js oder Nuxt die richtige Wahl. 5. Wie hoch ist Ihr Budget für Entwicklung, Betrieb und laufende Wartung? Headless verdoppelt den Aufwand realistisch, mindestens.

Was Headless unterschätzt kostet

Wer nur auf die CMS-Lizenzkosten schaut, vergleicht Äpfel mit Birnen. Headless kostet in der Entwicklung deutlich mehr: Ein eigenes Frontend muss vollständig entwickelt werden, es gibt keine Templates, keine Themes, kein schnelles Fertigwerden. Das Plugin-Ökosystem klassischer CMS existiert nicht, jede Funktion – SEO, Formulare, E-Commerce, Suche – muss separat integriert werden. Preview-Funktionen für Redakteure sind komplex und müssen aufwendig implementiert werden, und der laufende Betrieb erfordert DevOps-Kenntnisse, die über normales CMS-Hosting hinausgehen. Für ein mittelständisches Unternehmen ohne eigenes Entwickler-Team kann Headless leicht dreimal so teuer werden wie eine professionell umgesetzte WordPress-Lösung – bei keinem messbaren Mehrwert im Alltag.

Anbieter im Kurzüberblick

Wer sich trotzdem für Headless entscheidet, hat mehrere ausgereifte Optionen: Contentful ist der Platzhirsch, enterprise-tauglich und gut dokumentiert, aber ab wachsendem Inhaltsvolumen kostspielig (Team-Pläne beginnen bei rund 300 US-Dollar im Monat). Strapi ist Open Source und selbst gehostet, ideal für Teams, die Kontrolle über ihre Infrastruktur behalten wollen und mit einem VPS ab rund 10 US-Dollar im Monat auskommen. Sanity besticht durch ein extrem flexibles Schema und herausragendes Developer-Tooling, besonders für komplexe Content-Strukturen. Storyblok bietet den besten visuellen Editor – Redakteure sehen Änderungen live, was die Akzeptanz im Team spürbar erhöht. Directus ergänzt das Feld als flexible Datenbankoberfläche mit CMS-Funktionen — besonders attraktiv, wenn das Datenmodell komplex oder ungewöhnlich ist.

Migration von WordPress zu Headless

Wer von einem klassischen CMS auf Headless wechseln will, unterschätzt häufig den Aufwand. Bestehende Shortcodes, Custom Fields und Page-Builder-Layouts müssen einzeln in das neue Contentmodell übersetzt werden — das ist manuelle, zeitaufwendige Arbeit, kein technischer Automatismus. Realistisch sind für eine mittelgroße Website: Inhaltsanalyse und Contentmodellierung (2–4 Wochen), parallele Frontend-Entwicklung (4–12 Wochen je nach Komplexität), Content-Migration und Qualitätssicherung (2–4 Wochen) sowie Redirect-Management und SEO-Absicherung (1–2 Wochen) — in Summe 3 bis 6 Monate. Eine einfache Headless-Umsetzung (etwa Strapi mit Next.js) liegt bei rund 8.000–15.000 Euro Entwicklungsaufwand, eine komplexe Enterprise-Implementierung mit Contentful oder Sanity bei 30.000–100.000 Euro. Sinnvoll ist es, die Migration nicht als reines Umziehen der Inhalte zu planen, sondern als Gelegenheit, ein schlecht strukturiertes Contentmodell neu aufzusetzen — was in WordPress unübersichtlich war, wird im Headless-CMS nicht automatisch besser.