Headless CMS vs. klassisches CMS für Führungskräfte einfach erklärt
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.
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
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.
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.
Vor- und Nachteile des Headless CMS
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:
| Anbieter | SaaS | OnPremise | Open Source | HQ |
|---|---|---|---|---|
| Contentful | ja | nein | nein | DE |
| Directus | ja | ja | ja | DE |
| Hygraph | ja | nein | nein | DE |
| Kontent.ai | ja | nein | nein | CZ |
| Netlify CMS* | nein | ja | ja | - |
| Sanity | ja | nein | nein | NO |
| Storyblok | ja | nein | nein | AT |
| Strapi | WIP | ja | ja | FR |
| Payload CMS | WIP | ja | ja | US |
| Prismic | ja | nein | ja | FR |
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.
Vor- und Nachteile eines klassischen CMS
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?
| Anbieter | Lizenz | Besonderheit |
|---|---|---|
| Adobe Experience Manager Sites | Commercial | Mächtiges, kommerzielles CMS mit zahlreichen Enterprise-Features |
| craft cms | Commercial Open Source | Variable Inhaltstypen, PHP, basierend auf Yii-Framework |
| Drupal | Open Source | Internationale Community, seit 2000, PHP |
| Ghost | Open Source | moderne Wordpress-Alternative, NodeJS |
| Ibexa DXP | Commercial Open Source | ehemals eZ Publish, auf Symfony-Basis/PHP |
| Kirby CMS | Commercial | Schlankes PHP-CMS für kleine Landingpages |
| Magnolia CMS | Commercial Open Source | Bewährtes Java-CMS, Content-Repository als Basis |
| Neos CMS | Open Source | Mächtiges CMS auf PHP/React-Basis mit herausragender WYSIWYG-Experience |
| Statamic | Commercial | Pragmatisches CMS auf Laravel-Basis/PHP, schicke UI |
| Sulu | Open Source | Sehr flexibles CMS basierend auf Symfony/PHP |
| TYPO3 | Open Source | Solides CMS (seit 2001), großes Agentur-Netzwerk in DE |
| Wordpress | Open Source | Internationale 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.