RATGEBER

Headless CMS vs. klassisches CMS für Führungskräfte einfach erklärt

Martin BrüggemannProfilfoto von Martin Brüggemann

Martin Brüggemann

am

Was ist eigentlich ein Headless CMS (Content-Management-System)? Und wann sollte man überlegen ein Headless CMS einzusetzen? Wo liegen die Unterschiede zu einem klassischen CMS und haben diese jetzt ausgedient? In diesem Artikel erkläre ich dir wo die Unterschiede liegen und was man als Führungskraft beachten sollte.

Der Begriff "Headless CMS" und seine Bedeutung

Ein Headless CMS ist ein Content-Management-System, bei dem standardmäßig kein Frontend (z.B. um eine Website aus den Inhalten zu generieren) mit ausgeliefert wird. Stattdessen konzentriert sich bei einem Headless CMS alles auf die flexible Verwaltung komplexer Inhalte und die Bereitstellung einer API (Application Progamming Interface). Die API ermöglicht es dann, die Inhalte aus dem Headless CMS optimal in andere Systeme zu integrieren.

Das 'headless' in Headless CMS meint: Kein Frontend integriert. Exzellente API. Komplexe Inhaltstypen möglich.

Die Nutzer arbeiten in einer allgemein gehaltenen, webbasierten Verwaltungsoberfläche in der alle Inhaltstypen und Inhalte mit wenigen Klicks konfiguriert und erfasst werden können. Da die komplette Ausgabelogik fehlt, braucht es also immer mindestens ein weiteres System, dass die Inhalte aus dem Headless CMS abruft, aufbereitet und in Form einer Website oder einer App (z.B. iOS oder Android) ausgibt.

Klassisches CMS vs. Headless CMS

Erfrischend anders, aber gar nicht so unähnlich: Während beim klassischen CMS alles integriert ist und es oft sogar eine API gibt, besticht das Headless CMS mit der Möglichkeit extrem einfach flexible Inhaltstypen zu erstellen und alles per API zu steuern.

Wann macht ein Headless CMS Sinn?

Gerade in gewachsenen Content-Projekten, die über viele Jahre betrieben und immer wieder erweitert wurden (z.B. eine große Unternehmenswebsite mit Produktseiten, Kunden- und Newsbereich und verschiedenen Ausgabeformaten), stellt sich irgendwann die Frage, ob das eingesetzte CMS überhaupt noch zeitgemäß ist. In vielen Projekten fühlt es sich einfach nicht mehr effizient an, das in die Jahre gekommene CMS durch selbst entwickelte Funktionen oder den Einsatz von Drittanbieter-Erweiterungen zu verbiegen. Hier kann ein Headless CMS seine Vorteile voll ausspielen. Anstatt das CMS vom eigenen Entwicklerteam oder einer externen Agentur kompliziert erweitern lassen zu müssen (z.B. durch "Custom Fields" oder "Freigabe-Workflows") kann auch von technisch wenig versierten Anwendern auf die Standard-Funktionen eines Headless CMS zurückgegriffen und sofort losgelegt werden.

Individuelle Inhaltstypen einfach zusammenklicken

Standard für jedes Headless CMS ist hier der "Content Type Builder" (oft auch einfach "Content Model" genannt), mit dem selbst komplexe Inhaltstypen mit wenigen Klicks erstellt und verwaltet werden können.

Komplexe Inhaltstypen einfach zusammenklicken: Hier am Beispiel eines Inhaltstyps 'Fonds' einer fiktiven Bank im Content-Type-Builder des Headless CMS Contentful

Sind die Inhaltstypen erstellt, stellt das Headless CMS automatisch eine einfach zu bedienende Verwaltungsoberfläche für diese zur Verfügung, in der nun alle Inhalte bequem erfasst und gespeichert werden können. Auch Datei-Uploads, Relationen zu anderen Inhaltstypen und komplexe Auswahlfelder (z.B. Multiselect oder Tags) sind möglich.

Außerdem generiert das Headless CMS im Hintergrund automatisch eine vollwertige API (z.B. REST, GraphQL), um die Inhalte optimal in andere Systeme zu integrieren oder Daten automatisiert in das Headless CMS zu importieren.

Den Wald vor lauter Inhaltstypen nicht mehr sehen

Das Headless CMS hat kein Frontend und man kann somit auch schlecht nachvollziehen, was die inhaltlichen Änderungen in einem Headless CMS für die Ausgabe (z.B. die Webseite, Inhalt in einer App,...) bewirken. Zwar bietet jedes gute Headless CMS die Möglichkeit eine individuelle Vorschau-Funktion in das Headless CMS zu integrieren, allerdings muss diese dann wieder kompliziert entwickelt werden und lässt sich von nicht-technischen Anwendern oft nicht intuitiv bedienen. "What you see" ist dann leider oft nicht "what you get" und Änderungen am Inhalt müssen teilweise kompliziert im "Trial-And-Error-Verfahren" vom Nutzer ausprobiert werden.

Außerdem verliert man bei vielen Inhaltstypen im Headless CMS schnell den Überblick, da die Verwaltungsoberfläche automatisiert aus den Inhaltstypen generiert wird und alles gleich aussieht. Gerade bei komplexen, verschachtelten Inhaltstypen sorgt das für eine hohe Fehleranfälligkeit und oft unnötig komplizierte Bearbeitungs-Workflows. Wo man im klassischen CMS einfach mit Point & Click editieren konnte, muss heute zunächst der Inhalt gefunden, selektiert, bearbeitet und mit mehreren Klicks umständlich geändert werden.

Egal ob man Äpfel, Birnen oder Fonds-Inhaltstypen verwaltet - im Headless CMS sieht schnell alles gleich aus.

Vor- und Nachteile des Headless CMS

Die Vor- und Nachteile eines Headless CMS auf einen Blick

Meiner Erfahrung nach gibt es folgende Fälle, in denen ein Headless CMS besonders Sinn macht:

  • Es soll ein zentrales, modernes CMS für multiple Ausgabeformate (z.B. Webseite, App, Newsletter, Print, ...) eingeführt werden
  • Es gibt kein klassisches CMS oder das klassische CMS lässt sich nur schwer um komplexe Inhaltstypen erweitern
  • Es sollen viele individuelle Inhaltstypen und massenhaft Inhalte verwaltet werden
  • Es gibt massive Performance-Probleme mit dem Alt-CMS (z.B. über Jahre gewachsenes Wordpress mit ACF-Plugin und unzureichender Datenbank-Struktur)
  • Das alte CMS hat keine oder nur eine unzureichende API, um Inhalte an Drittsysteme anzubinden
  • Alle CMS-Nutzer haben ein gewisses technisches Grundverständnis und brauchen kein WYSIWYG/Live-Preview
  • Die Anforderungen an Revisionssicherheit, Freigabeworkflows und Rollenverwaltung sind überschaubar

Welche Headless CMS sind aktuell einen Blick wert?

Bei der Auswahl eines Headless CMS gilt es zwischen SaaS-Anbietern und OnPremise-Lösungen, also CMS-Systeme, die im eigenen Rechenzentrum betrieben werden können zu unterscheiden. Einige Anbieter bieten auch beide Möglichkeiten für ihr Headless CMS an. Anbei eine Liste der 10 populärsten Headless-CMS-Anbieter, die mir bei meiner Tätigkeit als TECH-Coach regelmäßig über den Weg laufen:

AnbieterSaaSOnPremiseOpen SourceHQ
ContentfuljaneinneinDE
DirectusjajajaDE
HygraphjaneinneinDE
Kontent.aijaneinneinCZ
Netlify CMS*neinjaja-
SanityjaneinneinNO
StoryblokjaneinneinAT
StrapiWIPjajaFR
Payload CMSWIPjajaUS
PrismicjaneinjaFR

Stand 06.01.2023, alphabetisch geordnet, kein Vollständigkeitsanspruch. WIP = Work in progress. *Netlify CMS basiert auf git und ist für weniger technische Nutzer eher nicht geeignet.

Wann ein klassisches CMS oft mehr Sinn macht

Wem der technische Aufwand hinter einem Headless CMS schon beim Lesen dieses Artikels zu hoch für die eigenen Anforderungen erscheint und z.B. eigentlich nur seine Firmenwebsite mit wenigen Mitarbeitern möglichst einfach pflegen möchte, kann auch weiterhin an einem klassischen CMS sehr viel Freude haben. Oft gibt es ja auch bereits ein Bestandssystem, dass nicht einfach so abgelöst werden kann.

Was man beim aktuellen Headless-CMS-Hype auch oft vergisst, ist die User-Experience für Redakteure. Was sich am Anfang eines Content-Projekts mit einem Headless CMS eventuell noch schön pragmatisch anfühlt, kann schnell zu einem echten Problem werden, wenn hunderte Mitarbeiter, die später täglich mit dem CMS arbeiten müssen, sich schlecht oder nur mit vielen Workarounds zurechtfinden.

Komplexe Inhaltstypen im klassischen CMS (hier Neos CMS) bearbeiten: Einfach durch die Website navigieren, zu bearbeitenden Inhalt anklicken, direkt bearbeiten, Änderungen wie live nachvollziehen und speichern. Warum eigentlich nicht? (Quelle: neos.io Website)

Vor- und Nachteile eines klassischen CMS

Die Vor- und Nachteile eines klassischen CMS: Das Frontend wird mitgeliefert, es gibt meistens einen guten What-You-See-Is-What-You-Get-Editor aber die Einrichtung ist komplex und inhaltstypen müssen oft erst mühsam von Entwicklern eingerichtet werden.

Meiner Erfahrung nach gibt es folgende Fälle, in denen ein klassisches CMS mehr Sinn macht:

  • Die Anforderungen an das CMS sind vergleichsweise einfach und es gibt keine großen Anforderungen an die Flexibilität der Inhalte
  • Die CMS-Nutzer sind NICHT technisch versiert und benötigen eine einfache Oberfläche mit Klickibunti-Oberfläche ( echtes What-You-See-Is-What-You-Get/WYSIWYG)
  • Die Integration der CMS-Inhalte in andere Systeme steht nicht an erster Stelle
  • Es werden granulare Freigabe-Prozesse und Rollen benötigt
  • Es gibt kein oder nur ein kleines internes Technik-Team

Welche klassischen CMS sollte man kennen?

AnbieterLizenzBesonderheit
Adobe Experience Manager SitesCommercialMächtiges, kommerzielles CMS mit zahlreichen Enterprise-Features
craft cmsCommercial Open SourceVariable Inhaltstypen, PHP, basierend auf Yii-Framework
DrupalOpen SourceInternationale Community, seit 2000, PHP
GhostOpen Sourcemoderne Wordpress-Alternative, NodeJS
Ibexa DXPCommercial Open Sourceehemals eZ Publish, auf Symfony-Basis/PHP
Kirby CMSCommercialSchlankes PHP-CMS für kleine Landingpages
Magnolia CMSCommercial Open SourceBewährtes Java-CMS, Content-Repository als Basis
Neos CMSOpen SourceMächtiges CMS auf PHP/React-Basis mit herausragender WYSIWYG-Experience
StatamicCommercialPragmatisches CMS auf Laravel-Basis/PHP, schicke UI
SuluOpen SourceSehr flexibles CMS basierend auf Symfony/PHP
TYPO3Open SourceSolides CMS (seit 2001), großes Agentur-Netzwerk in DE
WordpressOpen SourceInternationale Community, extrem viele Plugins, gut für Blogging, wenig Enterprise-Features und schwierig zu betreiben

Stand 06.01.2023, alphabetisch geordnet, kein Vollständigkeitsanspruch.

Oder einfach beides nutzen?

Am Ende stellt sich noch die Frage, warum man überhaupt eine Entscheidung zwischen einem klassischen und einem Headless CMS treffen sollte? Angenommen es ist bereits ein klassisches CMS erfolgreich im Einsatz (z.B. TYPO3, Neos CMS, Magnolia, Wordpress) aber es kommen komplexe Anforderungen hinzu (z.B. ein großes Verzeichnis-Projekt, Multi-Channel-Inhalte,...). Diese neuen Anforderungen können oft nur mit extrem viel Programmieraufwand in das Altsystem integriert werden und oft macht das auch überhaupt keinen Sinn. Alles auf ein Headless CMS umzustellen und damit die bewährte Website komplett neu zu bauen aber auch nicht. Was also tun?

Ein eleganter Weg, der in diesem Fall oft übersehen wird, besteht darin, das Headless CMS einfach parallel zum vorhandenen, klassischen CMS einzuführen und einfach später in das vorhandene, klassische CMS zu integrieren. Gerade in frühen Phasen bei neuen Content-Projekten ist es zum Beispiel extrem hilfreich mit einem Headless CMS schon einmal die Inhaltstypen und Inhalte zu definieren, ohne sich Gedanken über die Ausgabe machen zu müssen. So können ganze Redaktionen bereits mit dem neuen Headless-CMS arbeiten und riesige Mengen an Inhalten anlegen, die dann später "nur noch" von einem Frontend aufbereitet und ausgegeben werden müssen. Auch die direkte Integration der neuen Inhalte aus dem Headless CMS in das klassische Alt-CMS ist mit der neuen API meist schnell erledigt.

Fazit

Nur weil das Thema "Headless CMS" gerade in Mode sind, heißt das nicht, dass es für alle Anwendungsfälle eingesetzt werden sollte. Gerade aus unternehmerischer Perspektive kann es oft sinnvoll sein, die bestehende Website mit einem klassischen CMS weiterzubetreiben und durch ein Headless CMS zu ergänzen. Was erst einmal kompliziert klingt, kann sich schnell als effiziente Lösung erweisen, um auf der einen Seite den Livebetrieb nicht zu gefährden und auf der anderen Seite die Umsetzung neuere Content-Projekte massiv zu beschleunigen.

Die verschiedenen Headless CMS Anbieter unterscheiden sich übrigens überraschenderweise hauptsächlich in ihrer Benutzerfreundlichkeit, Integrationsmöglichkeiten und dem Preis - die Grundfunktionalität ist bei allen hier erwähnten Anbietern relativ ähnlich und auf einem hohen Niveau. Ob man seine Inhaltstypen nun in Strapi oder Contentful managed sieht ziemlich ähnlich aus und ist am Ende einfach auch eine Vertrauens- und Geschmacksfrage. Wem es z.B. wichtig ist, das Headless CMS im eigenen Rechenzentrum selbst zu betreiben, wird sich eher für ein Open Source Headless CMS entscheiden. Wer schnell starten möchte und mit den Datenschutzbedingungen des jeweiligen Anbieters einverstanden ist, wählt ein Saas Headless CMS.