What is a headless CMS?

Headless CMS architecture separates back-end content functions (like creation, management, and storage) from front-end functions (like presentation and delivery). Headless architecture is partly a response to the way web content has evolved. For a long time, most web content was delivered through a browser, often as a web page. But new connected devices are arriving all the time. Today, audiences consume content through new interfaces with different form factors—things like smartphones, wearables, AI-enabled voice assistants, and even virtual reality headsets.

Was ist ein Headless-CMS?

Alles, was Marketer und Entwickler über „Headless“, „Decoupled“ und „API-first“ im Zusammenhang mit Content-Management-Systemen wissen müssen

1. Was ist ein Headless-CMS?

2. CMS-Architektur 101

3. Wozu (und für wen) ist ein Headless-CMS sinnvoll?

4. Was sind die Nachteile eines Headless-CMS?

5. Einstieg in das hybride Headless-CMS

6. Weitere Headless-Ressourcen

1. Was ist ein Headless-CMS? (Kurzversion)

Bei einer Headless-CMS-Architektur sind Backend-Content-Funktionen (wie Erstellung, Verwaltung und Speicherung) von Frontend-Funktionen (wie Präsentation und Bereitstellung) getrennt.

Jetzt wollen wir es aber wissen: Was ist ein Headless-CMS?

Was bedeutet das? Warum ist eine Headless-Architektur wichtig für die Zukunft digitaler Erlebnisse?

Headless-Architektur ist teilweise das Ergebnis der Art und Weise, wie sich Web-Content im Laufe der Zeit entwickelt hat. Lange Zeit wurden die meisten Webinhalte über einen Browser, oftmals in Form von Webseiten, bereitgestellt. Es kommen aber laufend neue vernetzte Geräte hinzu.

Heute wird Content über neue Oberflächen mit unterschiedlichsten Formfaktoren konsumiert – wie Smartphones, Wearables, KI-fähige Sprachassistenten und VR-Headsets.

Eine Headless-CMS-Architektur ist grundlegend für die Bewältigung dieser neuen Content-Herausforderungen. Das bedeutet, dass viel mehr Inhalte einfach erstellt und verwaltet und an viel mehr Stellen bereitgestellt werden können.

Bevor wir aber zu technisch werden, beginnen wir mit den Grundlagen.

Sitecore Symposium registration now open

How does Sitecore.com deliver digital experience for our customers?

Join your peers to learn how Sitecore delivers on the promise of DX for its own customers on Sitecore.com, across a global organization in a rapidly changing business.

Headless CMS architecture is foundational to addressing these new content challenges. It means you can easily create and manage more things and deliver them to more places.

But before we get too technical, let’s start with the basics.

Here’s an overview of two fundamental architecture decisions –

and how they impact how content is created, stored, managed, delivered, and even personalized.

Welchen Einfluss hat eine CMS-Architektur darauf, wie Content auf einer Seite präsentiert wird?

Wir wollen herausfinden, was die Unterschiede zwischen seitenbasierter und objektbasierter Architektur sind, und befassen uns mit der Frage, warum Ihr KI-fähiger Sprachassistent nicht ansatzweise so smart ist wie er sich anhört.

Welchen Einfluss hat eine CMS-Architektur darauf, wie (und wo) Content den Nutzern präsentiert wird?

Erfahren Sie, welche Unterschiede es zwischen einer Headless- und einer herkömmlichen Architektur gibt und wie Sie vermeiden können, dass Personalisierung und Analysen durch die Entscheidung für eine Headless-Strategie beeinträchtigt werden.

2. CMS-Architektur 101

CMS: Frontend und Backend

Ein traditionelles CMS besteht aus zwei Hälften: dem Frontend und dem Backend.

Allgemein gesprochen: Das Backend eines CMS hat damit zu tun, wie Content verwaltet wird, und das Frontend damit, wie er präsentiert wird. Das kann man sich wie eine Schaufensterauslage in einem Geschäft vorstellen.

Zu Frontend-Aufgaben gehört alles, was Sie sehen würden, wenn Sie von der Straße in das Fenster schauen: Auswahl und Anordnung der Produkte sowie der zugehörigen Schilder.

Backend-Aufgaben beinhalten die Logistik – Erstellen der Schilder, Lagerung der Produkte und Verwaltung der Warenbewegungen im Geschäft.

Bei einer einfachen Website könnte das Backend Folgendes beinhalten:

Eine einfache Oberfläche, um Content zu erstellen
Eine Datenbank zur Speicherung digitaler Assets
Eine Anwendungsebene zur Erstellung und Anwendung von Design-Frameworks

Das Frontend würde dann auf Content, gespeicherte Assets und Designs zugreifen und diese auf einer HTML-Seite veröffentlichen.

Was ist ein „Decoupled CMS“?

Traditionell waren das Frontend und Backend bei einem CMS eng verzahnt. Die Benutzer konnten Content auf einer zentralen Oberfläche erstellen, speichern, verwalten und veröffentlichen.

Für technisch nicht ganz so versierte Benutzer, die einfachen Content veröffentlichen wollten – wie z. B. einen Blog – war das eine tolle Sache.

Aber im Zuge der Entwicklung digitaler Erlebnisse mussten die Entwickler sehr viel Zeit für die Entwicklung benutzerspezifischer Behelfslösungen aufwenden, um optimierten Content für ein immer breiteres Spektrum an Geräten bereitzustellen.

Decoupled CMS sind in Backend- und Frontend-Aufgaben unterteilt. In der Praxis bedeutet dies, dass die Entwickler Frontend-Erlebnisse in der von ihnen bevorzugten Sprache schnell programmieren und entwickeln können, ohne durch restriktive Backend-Technologien ausgebremst zu werden. Stattdessen können sie Application Programming Interfaces (API) nutzen, um die Backend-Funktionen – wie Content-Speicherung und -Verwaltung – mit einer beliebigen Frontend-Bereitstellungsumgebung zu verknüpfen.

Was ist ein „API-first CMS“?

Auch wenn bei Decoupled CMS die Backend- und Frontend-Funktionen getrennt sind, beinhalten sie oftmals Frontend-Bereitstellungstools wie Seitenvorlagen oder Modulintegrationen.

API-first CMS sind von der Funktion her mit Headless CMS vergleichbar, weil auch sie kein Standard-Frontend besitzen. Entwickler haben die Möglichkeit, so viele Bereitstellungsebenen wie benötigt zu erstellen (in der von ihnen bevorzugten Sprache), um Content in beliebigen neuen Kanälen bereitzustellen.

API-first CMS sind eine tolle Sache, wenn Sie bereits ein Team erfahrener Entwickler haben – das CMS verwaltet einfach nur Content und wartet auf API-Aufrufe von einer vom Entwicklerteam angelegten Frontend-Bereitstellungsebene.

Decoupled CMS hingegen sind für Unternehmen geeignet, die Wert auf die Flexibilität eines separaten Frontend und Backend legen, aber Unterstützung bei der Veröffentlichung benötigen.

3. Wozu (und für wen) ist ein Headless-CMS sinnvoll?

Headless-CMS sind sicherlich die Zukunft des Content-Managements, und das aus zwei wichtigen Gründen.

Zunächst einmal wird digitaler Content immer komplexer und die Erwartungen der Nutzer werden immer größer. Um sich vom Wettbewerb abzuheben, müssen Sie ansprechenden, bedürfnisgerechten und interaktiven Content erstellen – und das möglichst schnell.

Zum anderen kommen laufend neue Kanäle und Nutzergeräte hinzu. Es reicht längst nicht mehr, nur tollen Content zu produzieren – Sie müssen auch sicherstellen, dass er so effizient wie möglich und überall bereitgestellt wird. Headless-CMS bedeutet, dass Marketer und Entwickler heute wirkungsvollen Content entwickeln und – das ist das Entscheidende – ihre Content-Prozesse zukunftssicher machen können, um durchgängig überall ansprechenden Content bereitzustellen.

Das ist eine feine Sache für Marketer, Entwickler und Benutzer.

Das ist hervorragend für Marketer, weil ...

… sie Content nur einmal erstellen müssen und die Entwickler diesen dann überall veröffentlichen können. Das bedeutet, dass weniger Zeit für die Administration aufgewendet werden muss und mehr Zeit für wirkungsvolle, konsistente Erlebnisse zur Verfügung steht.

Das ist hervorragend für Nutzer, weil …

… das Benutzererlebnis schnell, konsistent und bedürfnisgerecht ist. Das liegt daran, dass die Client-Seite nicht mit dem Backend-System kommunizieren muss – sie muss den Content lediglich wiedergeben.

Das ist hervorragend für Entwickler, weil …

… sie am Backend nicht mehr an Programmiersprachen gebunden sind, mit denen sie keine Erfahrung haben. Stattdessen können sie Benutzererlebnisse vom Look & Feel und von der Funktionalität her mit Tools entwickeln, die sie kennen und mit denen sie gerne arbeiten (z. B. JavaScript-Bibliotheken und -Frameworks), und den Content dann mithilfe der neuesten APIs überall veröffentlichen.

4. Was sind die Nachteile eines Headless-CMS?

Standard-Headless-CMS sind kein Wundermittel für alle Ihre Content-Herausforderungen. Es gibt zwei große Nachteile, die bedacht werden müssen.

Auf der einen Seite gewinnen Sie Flexibilität, auf der anderen Seite leidet die Zugänglichkeit. Da die Präsentation Sache der Entwickler ist, die mit JavaScript arbeiten, können nicht-technische Marketer nicht WYSIWYG (What You See Is What You Get)-Authoring oder -Bearbeitung nutzen.

Der zweite Nachteil ist schwerwiegender:

Wenn das CMS seines „Kopfes“ beraubt wird, passiert etwas Drastisches – es gibt keine Möglichkeit mehr, Kundeninteraktionsdaten zwischen Frontend und Backend in Echtzeit auszutauschen.

Das bedeutet, dass keine Erlebnisse personalisiert oder Content-Analysen durchgeführt werden können.

Personalisierung ist aber von einem „Nice-to-have“ zu einem erfolgskritischen Erfordernis geworden. Amazon, Netflix, Spotify und andere machen schließlich vor, wie Personalisierung geht.

Wenn Sie nicht ein ähnliches Erlebnis bereitstellen können, werden die Kunden vermutlich abwandern – und zwar sehr schnell. Wie soll man darauf reagieren?

5. Einstieg in das hybride Headless-CMS

Eine ideale CMS-Architektur kombiniert die Flexibilität und Erweiterbarkeit eines Headless-CMS mit den Personalisierungs- und Content-Analysefunktionen herkömmlicher gekoppelter CMS.

Genau das leistet die Headless-Bereitstellungsoption von Sitecore.

Mehrere Headless-Optionen unterstützen die Frontend-Entwickler beim Bau von Lösungen und Apps, die Inhalte auf alle Geräte und Browser zuschneiden. Die Entwickler können ganz einfach auswählen, was sie brauchen, gleich ob sie JavaScript-Bibliotheken wie Vue.js, React.js und Angular.js verwenden oder die neue ASP.NET Core SDK und Headless-Rendering-Hostarchitektur nutzen.

Diese Optionen sind außerdem mit einer API ausgestattet, die eine Anbindung an den Sitecore Delivery Server für kontextabhängigen Content ermöglicht. Verwendet werden Informationen aus der Sitecore Experience Database™, damit Geräte und Browser Content- und Personalisierungsregeln in Echtzeit interpretieren können. Jeder Benutzer sieht also anderen Content, weil sich dieser nach Profildaten, dem Interaktionsverlauf und anderen Merkmalen richtet.

6. Erfahren Sie mehr über Headless

Headless in Aktion

Als diese Unternehmen vor der Herausforderung standen, bestimmte Zielgruppen zu erreichen und anzusprechen, konnten sie mit Headless-Implementierungen die Time-to-Market verkürzen und ihren Marketingexperten mehr Kontrolle über den Content geben.

Laden Sie den folgenden Bericht herunter und erfahren Sie, wie der schwedische Kosmetikhersteller Oriflame mit einem Headless-Ansatz seine Reichweite vergrößern konnte.

So hat es funktioniert

Nicht alle CMS sind gleich aufgebaut

Die CMS-Architektur hat Auswirkungen auf Funktionalität, Integration, Erweiterbarkeit und mehr. Lernen Sie die Grundlagen einer CMS-Architektur kennen, um zu verstehen, wie Headless funktioniert.

E-Book lesen

Next up on your reading list

Get more insights into the basics

CMS 101: Die Grundlagen (20 Min. Lesedauer)

Eine leistungsstarke Plattform für digitale Erlebnisse

Erfahren Sie mehr über unsere End-to-End-Lösungen für Content-Management und E-Commerce.

Produkte ansehen