Direkt zum Hauptinhalt

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

KAPITEL 1

Was ist ein Headless-CMS? (Kurzversion)

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

Bevor wir zu technisch werden, beginnen wir damit, was das im Kontext des Markenerlebnisses bedeutet.

Headless-Architektur ist teilweise das Ergebnis der Art und Weise, wie sich die Beziehung zwischen Web-Content und der Erstellung von Content entwickelt hat. Lange Zeit wurden die meisten Webinhalte über einen Browser, oftmals in Form von Webseiten, bereitgestellt. Es kommen jedoch ständig neue vernetzte Geräte auf den Markt und die Zielgrupppen konsumieren Content über unterschiedliche Benutzeroberflächen, etwa Smart Devices, Wearables, KI-gestützte Sprachassistenten und Virtual-Reality-Headsets (VR).

Eine Headless-CMS-Architektur ist grundlegend für die Bewältigung dieser neuen Content-Herausforderungen. Das bedeutet, dass Sie ganz einfach die notwendige Menge an Content für Ihre Zielgruppe erstellen und verwalten und einen Omnichannel-Ansatz verfolgen können, der Inhalte an alle relevanten Touchpoints liefert.

play-button

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

Wussten Sie, dass Ihr Sprachassistent nicht so smart ist, wie es klingt? Hier stellen wir zwei technologische Entscheidungen vor, seitenbasierte und objektbasierte Architektur.

play-button

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.

play-button

KAPITEL 2

CMS-Architektur 101: Headless, entkoppelt und API-First

Headless-CMS: Frontend oder Backend

Herkömmliche, monolithische Content-Management-Systeme haben zwei Bestandteile: das Frontend und das 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: die Auswahl und Anordnung der Produkten und das Branding.

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“?

Bei einem traditionellen CMS waren die Frontend-Präsentation, auch Präsentationsschicht genannt, und das Backend eng miteinander verbunden. Die Anwender:innen konnten Content auf einer zentralen Oberfläche erstellen, speichern, verwalten und veröffentlichen.

Für technisch nicht ganz so versierte Anwender:innen und Redakteur:innen von Content, die einfachen Content veröffentlichen wollten – wie z. B. einen WordPress-Blog – war das eine tolle Sache.

Aber im Zuge der Entwicklung der digitalen Erlebnisse und des E-Commerce mussten die Entwickler:innen sehr viel Zeit für die Entwicklung benutzerspezifischer Behelfslösungen aufwenden, um optimierte Erlebnisse und anspruchsvollen 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:innen 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 RESTful API oder GraphQL 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:innen 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:innen 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.

KAPITEL 3

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

Headless-CMS-Lösungen sind sicherlich die Zukunft des Content-Managements, und das aus zwei wichtigen Gründen:

  1. Digitaler Content und Content-Ersteller werden immer komplexer und die Erwartungen der Anwender:innen werden immer größer. Um sich vom Wettbewerb abzuheben und außergewöhnliche Customer Experiences zu bieten, müssen Sie ansprechenden, bedürfnisgerechten und interaktiven Content erstellen – und das möglichst schnell.
  2. Zum anderen kommen laufend neue Kanäle, Contenttypen 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. Ein SaaS-basiertes Headless-CMS bedeutet, dass Marketer und Entwickler:innen heute wirkungsvollen Content entwickeln und – das ist das Entscheidende – ihre Content-Prozesse zukunftssicher machen können, um durchgängig ansprechenden Content auf Websites, mobilen Apps und allen relevanten Touchpoints bereitzustellen..

Marken können ihre Content Operations verbessern und ihren Kund:innen ein besseres Erlebnis bieten, indem sie strukturierte Inhalte und Content Modeling in einem Headless-CMS integrieren.

play-button

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

… sie Content nur einmal erstellen müssen und die Entwickler:innen 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.

Die Möglichkeit, Content wiederzuverwenden, macht der zentrale Content Hub manuelle Vorgänge wie Kopieren und Einfügen überflüssig. Marketer und Content-Ersteller:innen können das Update außerdem einmal bearbeiten und überall teilen.

Das ist hervorragend für Anwender:innen, weil ...

… das Nutzererlebnis 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:innen, 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.

Entwickler:innen haben die Flexibilität, ihr bevorzugtes Frontend-Framework auszuwählen, und es stehen verschiedene Optionen für statische Site-Generatoren zur Verfügung, zum Beispiel Next.js, Gatsby.js und NUXT.js. In einem Open-Source-Headless-CMS können Entwickler:innen auf Code (JavaScript, PHP) zugreifen, um ihre eigenen API-Aufrufe und Vorlagen zu erstellen.

KAPITEL 4

Was sind die Nachteile eines Headless-CMS?

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

Erstens: Was Sie durch diese Art von Content-Speicher an Flexibilität gewinnen, verlieren Sie an Zugänglichkeit. Da die Präsentation Sache der Entwickler:innen 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 Kund:innen vermutlich abwandern – und zwar sehr schnell. Wie soll man darauf reagieren?

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

KAPITEL 5

Einstieg in das hybride Headless-CMS

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

Genau das leistet die modulare Headless-Bereitstellungsoption von Sitecore.

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

Diese Optionen verfügen auch über eine Benutzerschnittstelle, die mit der kontextbezogenen Content-Bereitstellung verbunden werden kann, sodass Anwender:innen personalisierten Content auf der Grundlage von Profilinformationen, früheren Interaktionen und mehr in Echtzeit sehen.

Nächster Beitrag in Ihrer Leseliste

Erfahren Sie mehr über die Grundlagen

Eine leistungsstarke Plattform für digitale Erlebnisse

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