Headless CMS und wann sich der Wechsel wirklich rechnet
Klassisches CMS oder Headless. Ein nüchterner Vergleich von Performance, Mehrkanal und Pflegeaufwand mit klaren Kriterien, für wen sich der Schritt lohnt.
Eine Architekturfrage, keine Modefrage
Headless CMS taucht in vielen Projektgesprächen auf, oft als pauschale Empfehlung für mehr Tempo und mehr Flexibilität. Diese Verkürzung führt in die Irre. Headless ist kein besseres Produkt, sondern eine andere Architektur mit eigenen Stärken und eigenen Kosten.
Die Frage lautet nicht, ob Headless gut ist, sondern ob die Trennung von Inhalt und Darstellung zum konkreten Vorhaben passt. Genau das entscheidet über Nutzen oder unnötigen Aufwand. Der folgende Vergleich ordnet die Begriffe und nennt konkrete Kriterien für die Entscheidung.
Klassisches CMS und Headless im direkten Vergleich
Ein klassisches CMS wie WordPress oder TYPO3 vereint zwei Aufgaben in einem System. Es verwaltet die Inhalte (das Backend) und erzeugt zugleich die ausgelieferte Seite (das Frontend). Beide Teile sind fest miteinander verbunden, daher der Begriff Monolith.
Ein Headless CMS trennt diese beiden Aufgaben. Es kümmert sich ausschließlich um die Inhalte und stellt sie über eine Schnittstelle bereit, meist als REST- oder GraphQL-API. Welches Frontend diese Inhalte abruft und darstellt, bleibt offen. Das kann eine mit Next.js gebaute Website sein, eine native App oder ein Anzeigesystem im Ladengeschäft.
Ein klassisches CMS liefert Inhalt und Darstellung als Paket. Ein Headless CMS liefert nur den Inhalt und überlässt die Darstellung dem Frontend.
Aus dieser Trennung folgt der zentrale Unterschied. Im klassischen Modell hängt die Geschwindigkeit der Seite stark von Theme, Plugins und Server ab. Im Headless-Modell entkoppelt sich die Auslieferung vom Redaktionssystem, was bei sauberer Umsetzung deutliche Vorteile bringt, bei nachlässiger Umsetzung aber auch zusätzlichen Aufwand.
| Kriterium | Klassisches CMS | Headless CMS |
|---|---|---|
| Architektur | Backend und Frontend verbunden | Backend und Frontend getrennt |
| Inhaltsausgabe | fertige HTML-Seite | API (REST oder GraphQL) |
| Kanäle | meist ein Kanal (Website) | mehrere Kanäle aus einer Quelle |
| Performance-Potenzial | mittel, abhängig von Plugins | hoch, mit statischer Generierung und CDN |
| Initiale Komplexität | gering bis mittel | höher, Frontend separat zu bauen |
| Redaktionelle Vorschau | direkt im System | erfordert eigene Einrichtung |
| Typische Setup-Dauer | Tage bis wenige Wochen | mehrere Wochen aufwärts |
Die Vorteile, sachlich betrachtet
Performance durch Entkopplung
Der häufigste Grund für Headless ist Geschwindigkeit. Wenn das Frontend Inhalte zur Bauzeit als statische Seiten erzeugt und über ein Content Delivery Network ausliefert, entfällt die Server-Verarbeitung pro Aufruf. Das wirkt direkt auf die Core Web Vitals, an denen Google die Nutzererfahrung misst.
Die Schwellen sind klar definiert. Der Largest Contentful Paint sollte unter 2,5 Sekunden liegen, die Interaction to Next Paint unter 200 Millisekunden und der Cumulative Layout Shift unter 0,1. Ein gut gebautes Headless-Frontend erreicht diese Werte leichter als ein klassisches CMS mit vielen Plugins, weil weniger zur Laufzeit passieren muss. Der Vorteil ist real, aber an Bedingungen geknüpft, nicht garantiert.
Mehrkanal aus einer Quelle
Inhalte entstehen heute selten nur für eine Website. Dieselbe Produktbeschreibung soll auf der Seite, in einer App und in einem Newsletter erscheinen. Im klassischen Modell wird Inhalt oft mehrfach gepflegt. Im Headless-Modell liegt der Inhalt einmal vor und wird über die API an jeden Kanal ausgegeben.
- Eine Quelle für Website, App und weitere Ausgabeorte
- Änderungen wirken überall, wo die API den Inhalt bezieht
- Neue Kanäle lassen sich anbinden, ohne den Bestand umzubauen
- Weniger doppelte Pflege und damit weniger Fehlerquellen
Flexibilität in der Technik
Weil das Frontend frei wählbar ist, ist die Darstellung nicht an die Vorgaben eines Themes gebunden. Ein individuelles Design, eine eigene Interaktionslogik oder eine spezielle Architektur lassen sich umsetzen, ohne gegen ein bestehendes System zu arbeiten. Das schafft Spielraum, verlangt aber Entwicklungskompetenz, die im klassischen Modell teilweise das CMS übernimmt.
Die Nachteile und der reale Aufwand
Headless ist keine Abkürzung. Was an einer Stelle gewonnen wird, kostet an anderer Stelle Aufwand. Drei Punkte fallen in der Praxis am stärksten ins Gewicht.
Erstens steigt die anfängliche Komplexität. Das Frontend muss eigenständig gebaut werden, inklusive Routing, Datenabruf und Caching. Ein klassisches CMS bringt diese Schicht fertig mit. Ohne ein Team, das mit modernen Frontend-Frameworks umgehen kann, wird der Vorteil zur Belastung.
Zweitens fehlt die unmittelbare Vorschau. Im klassischen System sieht die Redaktion sofort, wie eine Änderung wirkt. Im Headless-Setup muss diese Vorschau eigens eingerichtet werden, sonst arbeitet die Redaktion ohne direktes Bild vom Ergebnis. Das lässt sich lösen, gehört aber von Anfang an eingeplant.
Drittens verteilt sich die Verantwortung auf mehr Teile. Backend, API und Frontend sind getrennt zu betreiben, zu überwachen und abzusichern. Auch die Datenschutz-Grundverordnung bleibt voll wirksam. Jeder Kanal, der personenbezogene Daten verarbeitet, braucht eine Rechtsgrundlage nach Art. 6 DSGVO, unabhängig von der Architektur. Mehr bewegliche Teile bedeuten mehr Stellen, an denen Sorgfalt nötig ist.
| Aufwandsfaktor | Auswirkung im Projekt |
|---|---|
| Frontend von Grund auf | mehr Entwicklungszeit zu Beginn |
| Vorschau einrichten | zusätzlicher Aufbau für die Redaktion |
| Mehrere Systeme betreiben | höherer Wartungs- und Monitoring-Bedarf |
| Team-Kompetenz nötig | Frontend-Know-how wird vorausgesetzt |
Für wen es passt und für wen nicht
Die Entscheidung hängt weniger an der Größe als am Profil des Vorhabens. Headless lohnt sich, wenn mehrere Bedingungen zusammenkommen.
Es passt, wenn Inhalte über mehrere Kanäle ausgespielt werden, wenn Performance ein erklärtes Ziel ist, wenn ein individuelles Frontend gewünscht wird und wenn ein Team oder Partner die technische Schicht dauerhaft betreuen kann. In dieser Lage zahlt sich die Trennung von Inhalt und Darstellung über Jahre aus.
Es passt nicht, wenn eine überschaubare Seite mit wenigen Unterseiten genügt, wenn nur ein einziger Kanal bedient wird, wenn die Redaktion eine sofortige Vorschau ohne Einrichtung erwartet oder wenn kein festes Entwicklerteam zur Verfügung steht. Dann liefert ein klassisches CMS schneller ein gutes Ergebnis und bleibt einfacher in der Pflege.
Headless ist kein Upgrade, das jeder braucht, sondern eine Entscheidung für ein bestimmtes Profil aus Kanälen, Tempo und Team.
Ein verbreiteter Mittelweg ist das hybride Setup. Ein vertrautes System wie WordPress dient als Redaktions-Backend, ein modernes Frontend wie Next.js ruft die Inhalte über die API ab. So bleibt die gewohnte Oberfläche für die Pflege erhalten, während die Auslieferung die Vorteile der Entkopplung nutzt. Für viele Projekte ist das der ehrlichste Kompromiss zwischen Aufwand und Wirkung.
Wie wir die Entscheidung angehen
Eine Architektur ist eine langfristige Festlegung, kein Detail. Darum gehört sie an den Anfang, bevor Code entsteht. Wir prüfen zuerst, welche Kanäle wirklich bedient werden, welche Performance-Ziele gelten, wer die Inhalte pflegt und welche Kompetenzen vorhanden sind. Erst aus diesen Antworten ergibt sich, ob klassisch, Headless oder hybrid die tragfähige Wahl ist.
Dieses Vorgehen gehört für uns zu "weiter planen". Wer die Architektur an der tatsächlichen Nutzung ausrichtet statt am aktuellen Trend, vermeidet teure Korrekturen später. Mehr zu unserer Haltung und den vier Bewegungen weiter denken, weiter planen, weiter umsetzen und weiter gehen steht auf der Seite Mission.
Wer unsicher ist, welche Variante zum eigenen Vorhaben passt, klärt das am besten an konkreten Anforderungen statt an abstrakten Versprechen. Wir besprechen das im Detail und ordnen die Optionen entlang von Kanälen, Performance und Pflege ein.
Klassisch, Headless oder hybrid für ein konkretes Projekt? Wir prüfen es mit klaren Kriterien und nennen die belastbare Empfehlung.