Die Wahl zwischen Headless-, gekoppelter und hybrider CMS-Architektur

Ein klassisches, gekoppeltes CMS speichert Inhalte und rendert die Seiten, die sie anzeigen. Redakteure arbeiten in einem System, das weiß, wie die Seite aussieht; Entwickler erstellen Templates innerhalb dieses Systems. Ein Headless CMS speichert und verwaltet Inhalte und stellt sie über eine API bereit, und der „Head“ (die Website, die mobile App, der Kiosk-Bildschirm) ist eine separate Anwendung, die Inhalte abruft und eigenständig rendert.

Diese Trennung macht den gesamten Unterschied aus. Jeder Vorteil, der Headless zugeschrieben wird (Geschwindigkeit, Flexibilität, moderne Frontend-Frameworks, Multichannel-Ausspielung), folgt daraus – und ebenso jeder Nachteil. Inhalte werden zu strukturierten Daten statt zu Seiten; das schafft Flexibilität, bedeutet aber auch, dass jemand diese Struktur entwerfen muss. Das Rendering wird zur eigenen Anwendung des Unternehmens; damit ist dessen Team für Performance, Barrierefreiheit und Verfügbarkeit verantwortlich.

Das stärkste Argument für Headless sind Inhalte, die an mehr als einer Stelle erscheinen müssen. Beispiele sind eine Unternehmensgruppe mit einem Dutzend Markenwebsites, die Produktinformationen, Rechtstexte und Pressemitteilungen teilen; ein Unternehmen, das dieselben Inhalte auf einer Website, in einer mobilen App und auf Displays in Filialen veröffentlicht; oder eine Organisation, die drei Sprachen bedient und deren Übersetzungen mit dem Original Schritt halten müssen. In jedem dieser Fälle erspart es viel Kopierarbeit und die damit verbundenen Inkonsistenzen, Inhalte einmal als strukturierte, sprachbewusste Einträge zu speichern und über eine API auszuliefern.

Headless eignet sich auch für Unternehmen mit einem starken Frontend-Team, das bereits mit React oder ähnlichen Frameworks arbeitet und die Website als Produkt behandeln möchte – mit denselben Pipelines, Test- und Deployment-Verfahren wie bei den übrigen Anwendungen. Gibt es ein solches Team, passt eine Content-API besser als ein Template-System.

Entwickler bevorzugen in der Regel Headless: eine saubere API, ein Frontend unter eigener Kontrolle, keine veraltete Template-Sprache. Redakteure sind oft weniger begeistert – und ihre Erfahrung entscheidet darüber, ob Inhalte veröffentlicht werden. In einem gekoppelten CMS sieht ein Redakteur die Seite so, wie sie erscheinen wird, zieht eine Komponente an ihren Platz und klickt auf Veröffentlichen. In einem reinen Headless-Setup füllen Redakteure Formularfelder aus und verlassen sich darauf, dass das Frontend sie gut darstellt. Eine Vorschau der echten Seite mit unveröffentlichten Inhalten muss eigens entwickelt werden, ebenso Zeitplanung, Workflow und Freigaben, sofern das CMS sie nicht mitbringt.

Befragen Sie die Redakteure, bevor Sie sich für Headless entscheiden. Klären Sie, wie viele Seiten sie pro Woche veröffentlichen, ob sie Landingpages selbst erstellen oder einen Entwickler damit beauftragen und ob sie die Seite beim Bearbeiten sehen müssen. Muss das Marketing Seiten ohne Hilfe der Entwicklung erstellen und ändern, braucht das Unternehmen entweder ein CMS mit echter visueller Bearbeitung auf Basis seiner API oder ein hybrides Modell – und sollte in beiden Fällen Budget für Vorschau- und Gestaltungswerkzeuge einplanen.

Im E-Commerce hat die Entscheidung die weitreichendsten Folgen. Eine Headless-Architektur kombiniert eine Content-Plattform mit einer separaten Commerce-Engine, einem Suchdienst und einem Zahlungsanbieter – eine Anordnung, die als Composable Stack bezeichnet wird. Für einen Händler mit besonderen Anforderungen und einem leistungsfähigen Team bedeutet das Best-of-Breed-Funktionalität und die Freiheit, jeden Baustein auszutauschen. Für die meisten Unternehmen bedeutet es aber auch, die Integration zwischen Katalog, Inhalten, Warenkorb, Checkout und Aktionen selbst zu verantworten und die Roadmaps mehrerer Anbieter aufeinander abzustimmen.

Eine integrierte Plattform, in der Inhalte und Commerce ein Datenmodell und eine Verwaltungsoberfläche teilen, beseitigt diesen Integrationsaufwand und bietet dem Sortimentsmanagement im Alltag meist die bessere Arbeitsumgebung. Entscheidend ist, ob die Commerce-Anforderungen so ungewöhnlich sind, dass sie den eigenen Aufbau des Stacks rechtfertigen. In vielen Unternehmen ist das nicht der Fall.

Headless-Websites sind oft schnell, doch die Geschwindigkeit ergibt sich aus der Bauweise des Frontends, nicht aus der Architektur selbst. Schnell sind sie, wenn Seiten vorab oder am Edge gerendert, konsequent gecacht und Inhalte beim Build oder bei der Anfrage abgerufen werden statt bei jedem Besuch im Browser. Eine Headless-Website, die für jede Komponente die Content-API aus dem Browser aufruft, kann langsamer sein als das gekoppelte CMS, das sie ersetzt hat. Auch ein gut konfiguriertes gekoppeltes CMS hinter einem CDN liefert Seiten sehr schnell aus.

Behandeln Sie Performance als Anforderung mit einem Budget (Zeit bis zum ersten Inhalt, größtes Inhaltselement, Interaktionsbereitschaft) und lassen Sie sich von jeder infrage kommenden Architektur zeigen, wie sie dieses Budget einhält – auch in Mobilfunknetzen und nicht nur über eine Büroverbindung.

Wählen Sie ein gekoppeltes oder hybrides CMS, wenn die Inhalte auf einer Website liegen, die Redakteure Seiten selbst gestalten müssen, das Entwicklungsteam klein ist oder auch andere Systeme betreut und eine schnelle Markteinführung wichtiger ist als architektonische Wahlfreiheit. Das trifft auf sehr viele Marketing-Websites, Intranets und Serviceportale von Unternehmen zu. Ein hybrides CMS, das Seiten rendert und zugleich alles über eine API bereitstellt, deckt heute die Website ab und lässt Raum für eine App oder einen zweiten Kanal in der Zukunft.

Wählen Sie Headless, wenn Inhalte mehrere Ziele haben, wenn Übersetzungen und Markenwebsites über viele Auftritte hinweg konsistent bleiben müssen, wenn ein starkes Frontend-Team die Nutzererfahrung selbst verantworten will oder wenn die Commerce-Anforderungen einen Composable Stack erfordern und das Unternehmen bereit ist, ihn zu betreiben. Die Entscheidung hängt vom Unternehmen ab, nicht vom Ruf der Technologie.