Headless CMS oder klassisches CMS: Kriterien für die richtige Architektur

Die Entscheidung zwischen Headless CMS und klassischem CMS betrifft nicht nur die technische Auslieferung. Sie verändert, wie Redaktionen Inhalte prüfen, wie Vorschauen funktionieren und wer den Betrieb verantwortet. Für Geschäftsführung, Produktverantwortliche und technische Leitung ist deshalb nicht die Frage entscheidend, welche Architektur moderner wirkt. Entscheidend ist, ob die Trennung von Backend und Frontend einen konkreten Bedarf löst, der sich mit einem klassischen CMS nicht angemessen abbilden lässt.

Ein klassisches CMS verbindet meist Inhaltsverwaltung und Website-Ausgabe in einem System. Ein Headless CMS stellt Inhalte über eine Schnittstelle bereit; die Website oder App wird getrennt davon entwickelt und betrieben. Dazwischen liegen hybride Varianten. Die richtige Wahl ergibt sich aus Redaktion, Ausgabekanälen, Integrationen und Betriebsfähigkeit – nicht aus einer pauschalen Rangfolge.

Kurz gesagt

Ein klassisches CMS passt, wenn Inhalte überwiegend auf einer Website erscheinen und Redaktion, Vorschau und Veröffentlichung eng zusammenarbeiten sollen. Headless ist sinnvoll, wenn Inhalte verlässlich über mehrere eigenständige Kanäle ausgespielt werden oder ein individuelles Frontend klare Anforderungen erfüllt. Die Trennung erhöht aber den Aufwand für Vorschau, Schnittstellen, Tests und Betrieb. Eine hybride Architektur kann sinnvoll sein, wenn einzelne Bereiche eine API brauchen, die Website aber im CMS bleibt. Entscheiden Sie anhand konkreter Prozesse und Zuständigkeiten, nicht anhand des Begriffs „Headless“.

Ausgangslage

Bei einem klassischen CMS liegen Inhalte und Website-Ausgabe typischerweise nah beieinander. Die Redaktion bearbeitet Seiten im Backend und kann Änderungen häufig in einer Vorschau prüfen. Vorlagen und Erweiterungen bestimmen, wie Inhalte auf der Website erscheinen. Für viele Unternehmenswebsites ist diese Verbindung hilfreich: Der Weg vom Entwurf bis zur veröffentlichten Seite bleibt nachvollziehbar, und die Zahl der separat zu betreibenden Komponenten ist begrenzt.

Headless trennt die Inhaltsverwaltung von der Darstellung. Das CMS verwaltet Inhalte und stellt sie über eine API bereit. Ein separates Frontend ruft diese Inhalte ab und rendert die Website, App oder andere Ausgabekanäle. Damit steigt die Freiheit bei der technischen Umsetzung. Gleichzeitig müssen CMS, Schnittstelle und Frontend als zusammenhängendes System geplant und betrieben werden.

Das Problem entsteht, wenn eine Architekturentscheidung nur von der Oberfläche oder dem technischen Stack her getroffen wird. Eine moderne Frontend-Technologie löst keine unklaren Redaktionsprozesse. Umgekehrt verhindert ein klassisches CMS nicht automatisch eine saubere Datenstruktur oder eine gezielte API-Anbindung. Relevant ist, welche Anforderungen tatsächlich bestehen und welche Komplexität die Organisation dauerhaft tragen kann.

Entscheidungskriterien

1. Wo werden Inhalte ausgespielt?

Listen Sie die tatsächlichen Ausgabekanäle auf: Website, App, Kundenportal, interne Anwendung oder weitere Plattformen. Prüfen Sie dabei, ob dieselben Inhalte in mehreren Kanälen wiederverwendet werden oder ob jeder Kanal eigene Inhalte und Regeln benötigt.

Wenn eine redaktionelle Website der zentrale Ausgabekanal ist, bietet die Trennung oft wenig unmittelbaren Nutzen. Wenn mehrere unabhängige Anwendungen dieselben strukturierten Inhalte benötigen, kann eine zentrale API die Wiederverwendung erleichtern. Mehrere Kanäle allein sind jedoch kein ausreichender Grund für Headless: Auch ein klassisches CMS kann eine API für einzelne Integrationen bereitstellen.

2. Wie arbeitet die Redaktion?

Beschreiben Sie den Weg eines Inhalts vom Entwurf bis zur Veröffentlichung. Dazu gehören Rollen, Freigaben, Terminierung, Korrekturen und die Frage, wer die Darstellung prüft. Bei einem klassischen CMS kann die Vorschau direkt mit den Seitenvorlagen verbunden sein. Bei Headless muss die Vorschau zwischen CMS und getrenntem Frontend eingerichtet werden.

Klären Sie deshalb vor der Architekturwahl:

• Können Redakteurinnen und Redakteure Änderungen ohne technische Hilfe prüfen?
• Sind Vorschauen für unveröffentlichte und geplante Inhalte erforderlich?
• Gibt es unterschiedliche Freigabestufen oder Rollen?
• Müssen Inhalte in mehreren Ansichten verglichen werden?

Wenn die Vorschau ein fester Teil des Freigabeprozesses ist, muss sie bei Headless ausdrücklich geplant und getestet werden. Eine API liefert Inhalte; sie garantiert nicht, dass Redaktionsvorschauen funktionieren.

3. Wie individuell ist das Frontend?

Prüfen Sie, ob die bestehende oder geplante Website mit den Vorlagen und Erweiterungsmöglichkeiten eines klassischen CMS umgesetzt werden kann. Relevant sind etwa besondere Interaktionen, Datenansichten, Performance-Anforderungen oder die Einbindung in eine bestehende Produktoberfläche.

Ein individuelles Frontend kann sinnvoll sein, wenn diese Anforderungen tatsächlich bestehen und langfristig betreut werden. Ist der Hauptgrund lediglich der Wunsch nach einem anderen Frontend-Framework, vergleichen Sie zuerst den zusätzlichen Entwicklungs- und Betriebsaufwand mit einer Umsetzung im bestehenden CMS.

4. Welche Daten und Integrationen sind erforderlich?

Unterscheiden Sie zwischen einer Website, die Inhalte veröffentlicht, und einem System, das Daten verarbeitet oder Funktionen bereitstellt. Brauchen andere Anwendungen Zugriff auf strukturierte Inhalte? Gibt es externe Datenquellen, eigene Geschäftslogik oder unterschiedliche Berechtigungen?

Eine API kann auch in einem klassischen CMS eine klar abgegrenzte Aufgabe übernehmen. Headless wird dann interessanter, wenn die API nicht nur eine einzelne Integration bedient, sondern ein verlässlicher Teil der Systemarchitektur ist. Definieren Sie vorab Datenmodell, Zugriffsrechte, Fehlerbehandlung und Zuständigkeit für Änderungen an der Schnittstelle.

5. Wer betreibt das Gesamtsystem?

Bei einer getrennten Architektur gibt es mindestens ein CMS und ein Frontend. Hinzu kommen je nach Umsetzung Hosting, API-Verbindungen, Build- oder Veröffentlichungsprozesse, Monitoring und Umgebungen für Tests. Fragen Sie nicht nur, ob das Team die Komponenten heute entwickeln kann. Klären Sie auch, wer sie aktualisiert, Fehler untersucht und Änderungen nach einem Release überprüft.

Die Kosten der Komplexität zeigen sich häufig nicht beim ersten Aufbau, sondern bei Routineaufgaben: Vorschauen anpassen, Schnittstellenfehler beheben, neue Inhaltstypen ergänzen oder Änderungen sicher ausrollen. Diese Arbeit muss in Planung und Betrieb berücksichtigt werden.

6. Wie wichtig ist die Abhängigkeit von einer konkreten Plattform?

Bei Headless kann das Frontend unabhängig vom CMS entwickelt werden. Das bedeutet nicht automatisch, dass ein Wechsel einfach ist: Inhalte, API-Strukturen, Vorschau und Geschäftslogik können enge Abhängigkeiten schaffen. Umgekehrt kann auch ein klassisches CMS durch individuelle Erweiterungen stark an eine bestimmte Installation gebunden sein.

Bewerten Sie deshalb nicht nur die technische Trennung, sondern auch die Übertragbarkeit von Inhalten und die Dokumentation der Schnittstellen. Ein Wechsel ist leichter planbar, wenn Datenmodell und Abhängigkeiten klar beschrieben sind.

Optionen

Klassisches CMS: Inhalte und Website in einem System

Diese Variante passt, wenn die Website der Hauptkanal ist, die Redaktion direkt mit Seiten arbeitet und Vorschau sowie Veröffentlichung eng verbunden sein sollen. Der Betrieb bleibt vergleichsweise übersichtlich, weil Inhaltsverwaltung und Darstellung gemeinsam geplant werden können.

Die Grenzen zeigen sich, wenn das CMS zunehmend auch als Datenplattform, Anwendungsbackend oder Integrationsschicht genutzt wird. Dann sollten Sie zuerst Datenmodell und Verantwortlichkeiten prüfen, statt jede Anforderung mit weiteren Erweiterungen zu lösen. Eine klare Erweiterung über eine API kann dabei ausreichen, ohne die gesamte Website zu entkoppeln.

Headless CMS: Backend und Frontend getrennt

Diese Variante eignet sich, wenn mehrere Anwendungen strukturierte Inhalte benötigen oder das Frontend Anforderungen erfüllt, die im klassischen CMS nur mit erheblichem Aufwand umzusetzen wären. Sie schafft Freiraum bei der Auslieferung, verlangt aber ein abgestimmtes Zusammenspiel von Redaktion, API und Frontend.

Planen Sie insbesondere Vorschau, Veröffentlichungsablauf, Fehlerbehandlung und Tests. Legen Sie fest, was geschieht, wenn die API nicht erreichbar ist oder ein Inhalt unvollständig ist. Ohne diese Regeln kann die technische Trennung die Fehlersuche erschweren, statt sie zu vereinfachen.

Hybrid: CMS behalten und gezielt APIs nutzen

Eine hybride Lösung lässt die Website im klassischen CMS und stellt ausgewählte Inhalte oder Funktionen zusätzlich über eine API bereit. Sie ist geeignet, wenn ein konkreter Ausgabekanal oder eine Anwendung angebunden werden soll, während die Redaktion mit dem bestehenden System weiterarbeitet.

Wichtig ist, die Grenze bewusst zu definieren: Welche Daten werden über die API bereitgestellt? Welches System ist für Änderungen maßgeblich? Wer verantwortet die Schnittstelle? Ein begrenzter Einsatz kann Komplexität vermeiden; eine unklare Mischung aus mehreren Ausgabepfaden kann sie erhöhen.

Kosten der Komplexität

Ein Architekturvergleich sollte nicht nur Entwicklungsaufwand betrachten. Beziehen Sie den laufenden Aufwand für Redaktion, Tests und Betrieb ein. Bei Headless können beispielsweise Anpassungen an Inhaltstypen Änderungen im Frontend nach sich ziehen. Bei einem klassischen CMS können umfangreiche Sonderfunktionen das Backend unübersichtlich machen. Keine der Varianten ist automatisch wartungsärmer.

Eine einfache Bewertungsmatrix hilft, Annahmen sichtbar zu machen:

Kriterium	Klassisches CMS	Headless CMS
Redaktionelle Vorschau	Häufig eng mit der Website verbunden	Muss für das getrennte Frontend eingeplant werden
Mehrere eigenständige Ausgabekanäle	API kann ergänzen, Grenzen prüfen	Kann Inhalte zentral bereitstellen
Individuelles Frontend	Innerhalb der CMS-Architektur umsetzbar	Frontend unabhängig entwickelbar
Betrieb	Weniger getrennte Komponenten	Mehr Schnittstellen und Betriebsverantwortung
Geeignet, wenn	Website und Redaktion im Mittelpunkt stehen	Mehrere Anwendungen oder besondere Frontend-Anforderungen bestehen

Nutzen Sie die Tabelle als Ausgangspunkt, nicht als Bewertung ohne Kontext. Gewichten Sie die Kriterien nach den konkreten Abläufen Ihrer Organisation.

Typische Fehler

• Headless als Qualitätsmerkmal behandeln. Die Trennung ist eine Architekturentscheidung, keine automatische Verbesserung.
• Nur das Frontend vergleichen. Redaktion, Vorschau, Freigabe und Betrieb gehören zum selben Systementscheid.
• Eine API mit einer Headless-Architektur gleichsetzen. Ein klassisches CMS kann APIs für gezielte Integrationen bereitstellen.
• Vorschau als spätere Ergänzung betrachten. Wenn Redaktionen Inhalte vor der Veröffentlichung prüfen müssen, gehört die Vorschau in die Planung.
• Betriebsverantwortung offenlassen. Für CMS, Frontend und Schnittstellen müssen Zuständigkeiten und Tests feststehen.
• Wiederverwendung nur vermuten. Mehrere Kanäle rechtfertigen eine Trennung erst, wenn sie tatsächlich gemeinsame, strukturierte Inhalte benötigen.
• Ein komplexes CMS durch eine komplexe Eigenlösung ersetzen. Vergleichen Sie die Gesamtheit der laufenden Aufgaben, nicht nur die technische Freiheit.

Praxisbeispiel

Bei Wendewerk umfasst die WordPress-Plattform Krankenkassen- und Leistungsdaten, mehrere Benutzerrollen sowie Besucher-Tools wie einen Vergleich und einen Beitragsrechner. Für eine App gibt es zusätzlich eine token-authentifizierte REST-API unter wendewerk-app/v1. Das Beispiel zeigt eine begrenzte API-Anbindung innerhalb einer größeren CMS-Plattform – nicht, dass die gesamte Website headless umgesetzt wurde. Für die Entscheidung ist diese Unterscheidung wichtig: Eine Anwendung kann eine eigene Schnittstelle benötigen, ohne dass Redaktion und Website-Ausgabe vollständig getrennt werden müssen. Wendewerk ansehen

Empfehlung

• Wenn Ihre Organisation hauptsächlich eine redaktionelle Website betreibt und Vorschau sowie Veröffentlichung eng zusammenarbeiten sollen, wählen Sie ein klassisches CMS und modellieren Sie Inhalte sauber.
• Wenn mehrere eigenständige Anwendungen dieselben strukturierten Inhalte benötigen, prüfen Sie Headless und definieren Sie Datenmodell, API-Verantwortung und Vorschau vor der Umsetzung.
• Wenn nur eine App oder ein einzelner Dienst Daten benötigt, behalten Sie das klassische CMS zunächst bei und prüfen Sie eine klar begrenzte API-Anbindung.
• Wenn individuelle Funktionen das CMS stark überlasten, trennen Sie zunächst die fachlichen Anforderungen: Ein Teil kann eine Web-Anwendung sein, während redaktionelle Inhalte im CMS bleiben.
• Wenn Ihr Team die getrennten Komponenten nicht dauerhaft betreiben und testen kann, wählen Sie keine Headless-Architektur allein wegen ihrer technischen Freiheit.

Checkliste

• Sind alle tatsächlichen Ausgabekanäle und ihre Inhalte erfasst?
• Ist geklärt, ob Inhalte zwischen den Kanälen wiederverwendet werden?
• Sind Redaktionsrollen, Freigaben und Vorschau beschrieben?
• Ist benannt, welche Frontend-Anforderung ein klassisches CMS nicht angemessen erfüllt?
• Sind API-Datenmodell, Zugriffsrechte und Fehlerverhalten definiert?
• Ist klar, wer CMS, Frontend und Schnittstellen betreibt?
• Sind Tests und Veröffentlichungsabläufe für alle Komponenten eingeplant?
• Wurden laufender Redaktions- und Betriebsaufwand mitbewertet?
• Ist eine hybride Lösung als Alternative geprüft worden?

Häufige Fragen

Ist ein Headless CMS automatisch schneller?

Nein. Die Geschwindigkeit hängt unter anderem von Frontend, Datenabruf, Auslieferung und Betrieb ab. Die Trennung allein garantiert keine bessere Performance.

Können Redakteure bei Headless eine Vorschau sehen?

Ja, sofern eine Vorschau für das getrennte Frontend eingerichtet ist. Prüfen Sie, ob sie Entwürfe, geplante Inhalte und die relevanten Seitentypen korrekt abbildet.

Ist ein klassisches CMS für Apps ungeeignet?

Nein. Ein klassisches CMS kann Inhalte über eine API bereitstellen. Ob das ausreicht, hängt von Datenmodell, App-Anforderungen und den benötigten Integrationen ab.

Muss eine bestehende Website vollständig auf Headless umgestellt werden?

Nicht zwingend. Eine gezielte API-Anbindung oder eine hybride Architektur kann einzelne Anforderungen lösen, während die Website im bestehenden CMS bleibt.

Weiterführend

• Monolith oder Headless: Warum Architektur kein Glaubenskrieg sein sollte
• CMS auswählen: 12 Kriterien, die wichtiger sind als Feature-Listen
• Kunden sollen Inhalte bearbeiten können: Welche CMS-Architektur passt?
• Headless WordPress: Wann sich die Trennung von Frontend und Backend lohnt