Headless CMS oder klassisches WCMS?

Häufig ist bei neu geplanten Architekturen ein Headless CMS bereits gesetzt und ebenso häufig wird genau deshalb das bestehende WCMS eingestampft. Einerseits verständlich, denn Headless ist hip und wird von Microservice-Fetischisten als das einzig Wahre gesehen. Ein altbackenes WCMS ist out und den Monolith-Puristen gehen schnell die Argumente aus. Andererseits vollkommen unverständlich, denn es werden Äpfel mit Birnen verglichen. Ein Headless CMS und ein klassisches WCMS sind zwar irgendwie ähnlich, denn beide haben mit Content zu tun, aber sie sind doch verschieden. Schaut man nämlich genauer hin, stellt man fest: nur weil beides CMS im Namen trägt, wird nicht die gleiche Anforderung bedient. Die Frage „möchten sie ein DAM oder ein CMS?“ würde auch niemand stellen. Und falls doch, die Antwort wäre klar: „Natürlich beides!“

Doch woher kommt dieses Missverständnis und warum wird einfach davon ausgegangen, dass man das eine ohne Weiteres durch das andere ersetzen kann? Warum wird immer wieder gefordert, ein klassisches WCMS durch ein Headless CMS zu ersetzen? Und ergibt ein solcher Umstieg Sinn? Um das zu beantworten, lohnt ein kurzer Blick auf beide CMS Varianten.

Was hier klassisches WCMS genannt wird, ist ein System, welches es Redakteuren erlaubt, Inhalte für eine Webseite (oder allgemeiner für eine Webanwendung) bereitzustellen. Die Pflege sowie die Auslieferung ist optimiert für eben diesen Ausgabekanal. Häufig werden hierzu Inhalte (also Überschriften, Texte, Bilder) mit Konfigurationen (also Position und Art von Überschriften, Größe und Position von Bildern) vermischt und anschließend eng mit einer Struktur (welcher Inhalt taucht an welcher Stelle der Seite auf) verzahnt. Diese Vermischung ist nicht falsch, ganz im Gegenteil. Für eine Redakteurin, deren Arbeit sich ausschließlich an Inhalten der Webseite orientiert, ist diese Vermischung sogar gewünscht, denn es erleichtert ihre Arbeit ungemein.

Ganz im Gegensatz dazu steht die Grundidee hinter einem Headless CMS. Es gibt nicht die eine Stelle (also bspw. die Webseite), für die Inhalte erstellt werden. Theoretisch können Teile der gepflegten Inhalte auf einer Webseite erscheinen, vielleicht aber auch nicht. Möglicherweise werden Teile der Inhalte zusätzlich in E-Mails benötigt, vielleicht aber auch nicht. Oder der Inhalt erscheint auf Werbebannern, in Apps, in Feeds, auf gedruckten Flyern oder er erscheint überhaupt nirgendwo. Die Entscheidung, wo der Inhalt auftaucht, obliegt nicht mehr der Content Managerin im Headless CMS, sondern den Verantwortlichen für die konsumierenden Applikationen und das können letztlich sehr viele sein.

In der Headless-Welt folgt der Inhalt einer klaren Struktur, spiegelt in der Regel Fachlichkeiten wider, ist losgelöst von Layout und kann im besten Fall von vielen Systemen konsumiert werden. Die Fachabteilung gibt also nicht mehr die Inhalte an die Webredaktion weiter, welche diese wiederum im WCMS pflegt. Vielmehr hinterlegt die Fachabteilung die Inhalte direkt im Headless CMS. Das ergibt durchaus Sinn, denn damit behält die Fachabteilung die Hoheit über den von ihr bereitgestellten Content.

Verdeutlichen lässt sich das, wenn man für die Fachabteilung beispielhaft die Unternehmenskantine betrachtet. In der „alten“ Welt erstellt die Küchenchefin einen wöchentlichen Essensplan. Dieser wird mehrfach ausgedruckt und in der Kantine ausgehängt. Außerdem wird er an die HR-Abteilung geschickt, damit er im regelmäßig erscheinenden Mitarbeiternewsletter veröffentlicht wird. Zu guter Letzt folgt eine weitere E-Mail an die Webredaktion, damit der Essensplan auch auf den Seiten des Intranets aktualisiert werden kann.

In der Headless Welt pflegt die Küchenchefin den Plan direkt im Headless CMS. In den Mitarbeiternewsletter wird der aktuelle Plan automatisch eingefügt und das Intranet bezieht die aktuellen Infos ebenfalls automatisiert. Ob der Plan für die Kantine noch gedruckt werden muss oder ob das leckere Gulasch für nächsten Mittwoch direkt in der Kantine auf Monitoren erscheint, ist nebensächlich. Wichtig ist, dass alle unnötigen Zwischenschritte entfallen und es letztlich nur noch ein System für die Inhalte gibt, aus denen sich alle Applikationen bedienen.

Die zuvor beschriebene neue Welt klingt perfekt. Es gibt nur noch eine zentrale Stelle für Inhalte, dort ist alles schön geordnet und jede Abteilung ist in der Lage, die eigenen Inhalte zu verwalten. Diese perfekte Welt offenbart jedoch Risse, denn nur weil der Content existiert, heißt es noch lange nicht, dass er irgendwo konsumiert oder präsentiert wird.

Die Küchenchefin wird nicht für das Intranet verantwortlich sein, denn dann würde sie mit anderen Abteilungen um den prominentesten Platz im Intranet streiten. Diese Verantwortung ist durch die Einführung eines Headless CMS nicht verschwunden. Es braucht weiterhin jemanden der entscheidet, welcher Inhalt wann und wo erscheint. Dabei ist es unerheblich, ob diese Entscheidung automatisiert getroffen wird (hänge automatisch den aktuellen Kantinenplan an den Mitarbeiternewsletter an) oder ob eine Redaktion entscheidet (platziere den aktuellen Kantinenplan auf der Startseite des Intranets).

Es werden immer Applikationen benötigt, welche die Headless Inhalte konsumieren und es wird immer Verantwortliche für diese Applikationen geben. Ein WCMS ist das ideale Werkzeug, um den Verantwortlichen die flexible Nutzung des Headless Content in Webanwendungen zu ermöglichen und gegebenenfalls, um spezifische Inhalte zu ergänzen.

Ein klassisches WCMS sollte also nicht mehr als reines System zur Pflege von Inhalten betrachtet werden. Stattdessen ist es in erster Linie ein System zur Konfiguration einer Webanwendung und zusätzlich ein Konsument für Content aus einem Headless CMS.

Natürlich ist die Notwendigkeit von redaktioneller Freiheit in hohem Maße abhängig von der Art der Webanwendung. Eine Webseite die ausschließlich stark strukturierten Inhalte ohne viel Schnick-Schnack präsentiert, kann diese vollständig automatisiert aus einem Headless CMS laden. Eine Agentur, die sich im Web mit einem flexiblen und individuell gestalteten Auftritt präsentiert, bedient sich vielleicht bei Stellenausschreibungen und News an einem Headless CMS. Die restlichen Inhalte sind jedoch aller Voraussicht nach exklusiv für die Webseite produziert oder zumindest abgestimmt auf die Webseite gestaltet und konfiguriert.