Was ist eigentlich ein Headless CMS?

Immer mehr Unternehmen und Administratoren entscheiden sich bei der Auswahl eines passenden Redaktions- oder Content-Management-System für ein Headless CMS. Wir erklären, was ein Headless-CMS eigentlich ist und benennen die Vor- und Nachteile dieser »kopflosen« CMS-Variante.

Die grundlegenden Aufgaben eines Content Management Systems haben sich seit Jahren eigentlich kaum verändert: Contentproduktion und Website-Management sowie Inhalte zur richtigen Zeit an die jeweils relevante Zielgruppe über verschiedene Kanäle ausspielen. Content-Management- oder Redaktionssysteme verwalten, pflegen und organisieren die Content-Distribution – und das auch ohne Programmierkenntnisse oder IT-Wissen. Allerdings ist es gar nicht so einfach, das »richtige« CMS zu identifizieren: Was will ich? Was brauche ich? Welches Bundle bietet das beste Setup? Soll’s ein „traditionelles“ Content-Management-System – oft auch als  monolithisches, reguläres oder gekoppeltes CMS bezeichnet – sein oder doch lieber ein sogenanntes Headless-CMS? Letztere gewinnen an Beliebtheit, denn sie sind die Antwort darauf, dass Menschen inzwischen Inhalte im Internet anders konsumieren. 

Das könnte Sie auch interessieren

     In unserem Marktvergleich „CMS Lösungen 2020″ haben wir 17 Anbieter miteinander verglichen.              Hier kostenlos herunterladen!

Headless CMS versus reguläres CMS

Die üblichen Content-Management-Systeme verknüpfen ein Backend, also ein Sammelort für Artikel, Bilder und andere Medien mit dem Frontend, also der Plattform, wo diese ausgespielt werden. Häufig ist dies eine Webseite. Diese Content Management Systeme ermöglichen das einfache Bearbeiten und verwalten von Content per „What you see is what you get“, kurz: WYSIWYG-Editor. Man lädt Texte, Bilder oder Videos in das CMS, arrangiert sie und sieht direkt, wie die fertige Webseite aussieht: Das CMS stellt die im Backend gepflegten Daten automatisch im Frontend dar. Inhalte werden aber nicht länger nur auf Webseiten ausgespielt. Inzwischen gibt es eine Vielzahl weiterer Medien und Darstellungsarten wie etwa Apps, Smartphones, Wearables oder VR-Anwendungen. Möchte man diese parallel mit Bildern, Texten oder Videos füttern, dann braucht es beim klassischen CMS-Ansatz eben pro Medium ein eigenes Content-Management-System. Die Inhalte lassen sich für unterschiedliche Zielmedien nicht zentral verwalten. Und genau hier setzt ein Headless-CMS an.

Was ist ein Headless CMS?

Eine Headless-CMS-Architektur ist dem traditionellen Content-Management-System im Unterbau prinzipiell ähnlich. Allerdings ist das Headless-CMS ein reines Backend-Content-Management-System. Und hier erklärt sich der Name: Die Headless-Architektur trennt den »Kopf« (Backend beziehungsweise Content-Katalog) vom „Körper“ (Frontend, also etwa dem Webseiten Editor). Templates, Seitenstruktur und Design sind hier erst einmal völlig irrelevant. Was bleibt ist »purer« Content. Für das Frontend ist der System-Administrator in Eigenregie verantwortlich. Ein »kopfloses« Redaktionssystem erfüllt im Grunde also vordergründig eine Aufgabe: Das zentralisierte Speichern und Bereitstellen strukturierter Inhalte.

Das bedeutet, dass das einfache Erstellen und Aufbereiten von Inhalten, etwa im Form von Blogbeiträgen nicht so simpel funktioniert. Das mag aufgrund des Aufwands und Know-hows ein vermeintlicher Nachteil oder Schwachpunkt sein. Jedoch kann durch die Entkopplung des Content-Management-Systems von dem „Presentation Layer“ ein Frontend-Entwickler ohne Einschränkungen jede ihm vertraute Technologie nutzen. Ganz nach Gusto und Belieben. So kann etwa ein neues Produkt in einem Onlineshop gleichermaßen für die Website und für die App gleichermaßen eingepflegt werden. Ebenso lässt sich die Seitengeschwindigkeit für Google deutlich einfacher optimieren. 

Eine REST-API dient hier als Schnittstelle zwischen „Headless CMS“ und den (verschiedenen) Frontends der Ausgabemedien. Dabei wartet das reaktive Content-Management-System auf externe Anfragen (Datenzugriffe). Die sogenannte Content-Delivery-API (CDA) organisiert dann den Datentransfer des entsprechenden Contents an (fast) jedes beliebige Ausgabemedium. Allerdings – und das muss man einkalkulieren und in Kauf nehmen – kann nicht mal so im vorbeigehen auf die Schnelle eine Microsite gebastelt werden. Da braucht es für die Anpassungen immer den Kollegen vom Fach.

Fazit: Für wen lohnt sich ein „Headless CMS“?

Headless CMS lohnen sich also in erster Linie für Unternehmen, die in ihrer Content-Strategie auch verschiedene Ausgabemedien berücksichtigen wollen. Für den klassischen Anwendungsfall einer Firmen-Webseite oder eines Unternehmensblog ist oftmals noch die klassische Variante eines CMS zu empfehlen. Wer aber auf eine Multi- oder Omnichannel Strategie in seinen Content-Plänen setzt und Medien wie Webseite, Blog, Apps und andere vereinen will, für den lohnt sich der Blick auf ein Headless CMS. Denn bei verschiedenen Kanälen erspart es viel Arbeit, da man sich hier auf das Ausspielen der Inhalte konzentrieren kann und die Inhalte an sich nur einmal zentral bereitgestellt werden müssen.

Vorteile eines „Headless CMS“ auf einem Blick

• Uneingeschränkte Fokussierung auf den Content und geringere Komplexität
• Plattformunabhängig sowie Cross-Platform-Support
• Optimierte(s) Content-Distribution und Omnichannel-Marketing
• Professionelle Lokalisierung
• Einfache Codierung und »Developers First«
• Freie Wahl der Technologie respektive Programmiersprache durch REST-API
• Mehr Gestaltungsspielraum für Frontend-Entwickler und (Web-)Designer
• JAMstack (Entwicklung mit JavaScript, APIs und TML-M) wird unterstützt
• Dynamische Daten und Contenterstellung

Nachteile eines „Headless CMS“ auf einem Blick

• Mehr Aufwand bei der Administration (Headless CMS können in der Regel keine Seitenstruktur etc. verwalten)
• Kein Frontend: Jedes Medium braucht eine eigene Software zum Ausspielen der Inhalte
• Kein „WYSIWYG“: Seiten müssen programmiert und aufgesetzt werden, keine Templates o.ä. möglich
• Microsites u.ä. „schnelle Projekte“ müssen einzeln programmiert werden
• Höherer Programmieraufwand für einzelne Frontend-Lösungen
• Mehr Aufwand beim Ausspielen durch mehrere Frontend-Lösungen