Headless CMS

Der Name beschreibt die Abnahme des „Kopfes“: der Präsentationsschicht, die die Seiten gezeichnet hat, abgenommen von dem Körper, der die Inhalte verwaltet. Was bleibt, speichert typisierte Felder und liefert sie über REST oder GraphQL aus, und eine separate Frontend-Anwendung entscheidet, was Besucher zu sehen bekommen. Drupals Dokumentation nennt dieselbe Anordnung decoupled, definiert Decoupled Drupal als die Trennung des Backends, das Inhalte verwaltet, vom Frontend, das sie darstellt, und behandelt Headless als weiteren Namen dafür.

Diese Trennung bestimmt von da an, wie die Website gebaut und gepflegt wird. Was folgt, behandelt die Teile, die ein einkaufendes Team spürt: wie Inhalte zu Besuchern gelangen, was mit dem Frontend und mit der Vorschau geschieht, was Redakteure sehen, wenn sie einen Eintrag öffnen, und die Aufstellung der Arbeit, die auf Ihr Team übergeht. Eine direkte Gegenüberstellung der beiden Modelle finden Sie unter Headless- und traditionelles CMS im Vergleich.

Die Auslieferung ist ein API-Aufruf, und etwas anderes rendert das Ergebnis

Die Anfrage eines Besuchers endet nicht mehr im CMS. Eine Frontend-Anwendung nimmt sie entgegen, ruft das CMS über REST oder GraphQL auf, erhält typisierte Felder als JSON zurück und setzt daraus das HTML zusammen, das der Browser empfängt. Die Aufgabe des CMS endet, wenn es die Daten zurückgegeben hat.

Weil Inhalte als Felder ankommen, kann ein Eintrag mehrere Ziele bedienen. Eine Website, eine native App, ein Display in der Filiale und ein E-Mail-Template nehmen sich jeweils die Felder, die sie brauchen, und ordnen sie auf ihre eigene Weise an. Wie viel von dieser Wiederverwendung tatsächlich zur Verfügung steht, hängt davon ab, wie die Inhalte modelliert wurden, und darum geht es bei strukturierten Inhalten und beim Inhaltsmodell. Wurde das Modell um ein einziges Seitenlayout herum gebaut, erhalten andere Kanäle die Felder dieses Layouts und wenig sonst.

Frontends cachen Seiten häufig oder rendern sie vorab, weshalb das Veröffentlichen im CMS und das Erscheinen der Änderung für Besucher zu zwei getrennten Ereignissen werden, verbunden durch eine Cache-Invalidierung, die meist ein Webhook auslöst. Redakteure bemerken das am ersten Tag. „Ich habe es veröffentlicht und es ist noch nicht da“ ist eine Support-Frage, die ein traditionelles CMS selten hervorbringt.

Das Frontend wird zu einer zweiten Anwendung mit eigenem Build und Deploy

Die Präsentationsschicht ist jetzt eine Codebasis im Besitz Ihrer Organisation, mit Abhängigkeiten, einem Build-Schritt, einer Deploy-Pipeline, Umgebungen, Fehler-Monitoring und einem Upgrade-Pfad für das Framework. Zwei Systeme laufen nun in Produktion, und eine Änderung kann in beiden brechen.

Das Routing wandert mit. Im App Router von Next.js definieren Ordner die Routen-Segmente, die auf URL-Segmente abgebildet werden, und ein in eckige Klammern gesetzter Ordnername erzeugt ein dynamisches Segment, sodass die URL-Struktur der Website im Frontend-Code festgelegt ist. Vergleichen Sie damit, was ein traditionelles CMS und sein Theme gemeinsam übernehmen: WordPress gleicht eine Anfrage gegen eine Template-Hierarchie ab und verwendet die erste passende Template-Datei darin, sodass search.php, archive.php, 404.php und der Rest vom Theme geliefert werden. Unter Headless existieren die Entsprechungen in Ihrem Frontend, und jemand schreibt sie: die Übersichtsseite, die Detailseite, die 404-Seite, die Weiterleitungstabelle, die Sitemap, die Canonical-Tags.

Ein traditionelles Theme liefert diese Arbeit mit. Unter Headless werden daraus gewöhnliche Entwicklungsstunden, und die stehen auf keinem Lizenzangebot. CMS-TCO behandelt, wo sie im Budget landen.

Die Vorschau wird zu einer Integration, die Sie bauen und funktionsfähig halten

In einem traditionellen CMS ist die Vorschau die Rendering-Engine, die einen unveröffentlichten Datensatz liest. Sobald das Rendering in einer separaten Anwendung liegt, muss eine Vorschau diese Grenze überqueren, und beide Seiten dokumentieren dieselbe Form.

Das CMS öffnet eine URL im Frontend, die ein gemeinsames Geheimnis und den Pfad zur Vorschau trägt. Ein Route-Handler im Frontend prüft das Geheimnis, aktiviert den Entwurfsmodus, indem er ein Cookie setzt, das jede Cache-Schicht umgeht, und leitet auf die Seite weiter, die daraufhin Entwurfsinhalte abruft. Next.js dokumentiert diesen Ablauf bis hinunter zum Namen des Cookies und weist darauf hin, dass der Handler für jeden öffentlich ist, der ihn findet, solange die Prüfung des Geheimnisses fehlt. Strapi dokumentiert die CMS-Hälfte: Ein Handler bildet jeden Inhaltstyp auf einen Frontend-Pfad ab und gibt die Entwurfs- oder die veröffentlichte URL zurück, und die Dokumentation stellt ausdrücklich fest, dass die Einrichtung der Vorschau-Route im Frontend stark vom verwendeten Framework abhängt. Diese Vorschau innerhalb des Admin-Bereichs einzubetten verlangt zusätzlich, dass das Frontend das Einbetten in einen Frame erlaubt, über die CSP-Direktive frame-ancestors.

Eine Vorschau nebeneinander verlangt mehr. Payload rendert das Frontend in einem iframe innerhalb des Admin-Bereichs und sendet bei jeder Änderung am Dokument window.postMessage-Ereignisse; das Frontend muss auf diese Ereignisse hören und sich mit den empfangenen Daten neu rendern. Sanitys Visual Editing verlangt vom Frontend, seinen Client so zu konfigurieren, dass er Content Source Maps anfordert und die zurückkommenden Zeichenketten stega-kodiert, und enableVisualEditing() aufzurufen, wenn der Entwurfsmodus aktiv ist, damit ein Klick auf gerenderten Text die Dokument-ID und den Feldpfad an das Studio schickt, das daraufhin das Feld öffnet.

Die Abläufe sind gut dokumentiert, und sie sind fortlaufend. Jede neue Route und jede Komponente, die Felder auf neue Weise zusammensetzt, muss den Vorschau-Vertrag intakt halten, weshalb die Vorschau ebenso in die Position für laufende Betreuung gehört wie in die Aufwandsschätzung.

Redakteure sehen Felder, und die Seitenansicht ist etwas, das Sie bewusst einplanen müssen

Eine Redaktionsoberfläche in einem Headless-CMS zeigt die typisierten Felder eines Eintrags. Teams, die ohne die Vorschau-Integration live gehen, verlangen von Redakteuren, das Layout im Kopf zu behalten, und die Kosten zeigen sich als zusätzliche Abstimmungsrunden und als Gewohnheit, vor dem Veröffentlichen alles auf Staging zu prüfen.

Auf inhaltsreichen, layoutlastigen Seiten bietet ein feldbasierter Editor typisierte Blöcke aus einem definierten Satz. Inhalte bleiben portabel, und ein Redakteur kann keine einmalige Anordnung erfinden. Marketing-Teams, die es gewohnt sind, einen Hero, ein zweispaltiges Band und ein Testimonial auf eine Seite zu ziehen, werden diese Fähigkeit zurückfordern, und die Antwort darauf ist eine Blockbibliothek, die jemand entwirft, baut und dokumentiert. Redaktionelle Kontrolle, die früher von der Plattform durchgesetzt wurde, muss nun im Modell und im Code ausgedrückt werden, und das ist das Thema von Content-Governance in einem Headless-CMS.

Was das CMS liefert und was Ihr Team liefert

Die Anbieterdokumentation deckt die linke Spalte ab; die rechte Spalte ist der Teil, den ein einkaufendes Team selbst bemessen muss.

Fähigkeit	Was ein Headless-CMS üblicherweise liefert	Was Ihr Team liefert
Inhaltsmodellierung	Feldtypen, Beziehungen, Validierung, Lokalisierung, Entwürfe und Versionen	Das Modell selbst: welche Typen es gibt, welche Felder sie tragen, wie sie zueinander stehen, und die Disziplin, es kohärent zu halten
Redaktionsoberfläche	Aus dem Modell erzeugte Formulare, Rollen und Berechtigungen, Medienbibliothek	Alles jenseits von Feldern: eine Blockbibliothek, Layout-Komposition, Bearbeiten im Kontext
Content-Auslieferung	REST- und GraphQL-Endpunkte, Filterung, Paginierung, API-Tokens	Die Abfragen, die Caching-Strategie und die Invalidierung, die eine Veröffentlichung sichtbar macht
Frontend	Nichts	Die gesamte Anwendung: Komponenten, Designsystem, Barrierefreiheit, Performance-Budget, Build- und Deploy-Pipeline, Framework-Upgrades
Routing und URLs	Ein Slug-Feld	Routen-Definitionen, Übersichts- und Detailseiten, Paginierung, 404-Seiten, die Weiterleitungstabelle, Canonical-Tags, Sitemap und robots
Vorschau	Eine Einstellung für die Vorschau-URL und eine Entwurfs-API oder ein Token	Den Vorschau-Endpunkt, den Umgang mit dem Geheimnis, das Umgehen des Caches, das Abrufen von Entwürfen, das Banner für die Redaktion und die CSP-Freigabe für das Einbetten
Website-Suche	Gefilterte Abfragen über die eigenen Inhalte, manchmal einfache Volltextsuche	Das Sucherlebnis: Indizierung, Ranking, Tippfehlertoleranz, Facetten, die Ergebnisseite. Häufig ein separater Suchdienst und dessen Abonnement
Formulare	Die Felder eines Formulars als Inhalt modelliert	Rendering, Validierung im Client und auf dem Server, Spam-Behandlung, Speicherung der Einsendungen, Benachrichtigungen und die Anbindung an CRM oder Marketing-Systeme
Medien	Upload, Ablage, meist abgeleitete Größen und ein CDN	Welche Formate und Größen jede Oberfläche anfordert, Bildregie, die Praxis für Alt-Texte und die Ladestrategie auf der Seite
Hosting und Betrieb	Das CMS selbst, sofern als SaaS eingekauft	Hosting, CDN, TLS, Konfiguration der Umgebungen und Monitoring für das Frontend. Beim Self-Hosting dasselbe noch einmal für das CMS
Personalisierung, Testing, Analytics, Einwilligung	Üblicherweise nichts	Jedes davon, separat ausgewählt und integriert

Mehrere dieser Zeilen treffen nach dem Launch als gewöhnliche Entwicklungsarbeit ein, weshalb ein Funktionsvergleich zweier Produkte sie nicht zeigen wird. Fähigkeiten auf diese Weise zusammenzusetzen ist die Abwägung, die zusammensetzbare Architektur beschreibt, und die laufenden Kosten dafür gehören neben die Lizenz in CMS-TCO.

Wo Headless die falsche Antwort ist

• Eine Website, ein Ziel, kein zweiter Kanal auf der Roadmap. Die Plattform leitet die Anfrage bereits weiter, ein Theme liefert die Suchergebnisseite und die 404-Seite, und Plugins decken Formulare ab. Headless macht aus jedem dieser Punkte eine Aufwandsposition, und die Wiederverwendung von Inhalten, die die Trennung bezahlt, setzt voraus, dass ein zweites Ziel existiert.
• Kein dauerhaftes Budget für das Frontend. Ein Headless-Setup unterstellt eine Anwendung, die Abhängigkeits-Updates, Framework-Upgrades und kleine Korrekturen erhält, solange die Website läuft. Teams, die den CMS-Kauf als Ende der Ausgaben behandelt haben, stellen fest, dass das Frontend eine eigene Position für laufende Betreuung trägt.
• Redakteure, deren Hauptaufgabe das Zusammenstellen einmaliger Seiten ist, solange niemand eine Blockbibliothek oder das Bearbeiten im Kontext in den Umfang aufgenommen hat. Beides lässt sich bauen, sobald es bemessen und finanziert ist.
• Kurzlebige Kampagnen- und Event-Websites. Der Aufwand, eine zweite Anwendung aufzubauen, kommt innerhalb der Lebensdauer der Website selten zurück.
• Plugins, die derzeit tragende Aufgaben erfüllen. Mitgliedschaften, E-Commerce, Anmeldung für Veranstaltungen, geschützte Downloads, ein ausgereifter Stack für Formulare und Spam-Abwehr. Jedes davon wird zu einem Dienst, den Sie kaufen, oder zu Code, den jemand schreibt.
• Eine hybride Anordnung deckt die Anforderung bereits ab. WordPress liefert eine REST-API im Kern aus, die Inhalte als JSON sendet und empfängt, und Drupal dokumentiert die decoupled Nutzung direkt, sodass ein Team eine App oder eine zweite Oberfläche versorgen kann, während die Hauptwebsite ihre gerenderten Seiten behält.
• Der genannte Grund ist, dass das aktuelle System veraltet wirkt. Die Anforderung ist noch nicht aufgeschrieben. Schreiben Sie sie auf, bevor Sie Produkte vergleichen. Fünf Anzeichen, dass Sie Ihrem CMS entwachsen sind behandelt die Symptome, die einen Wechsel rechtfertigen.

Was das Wort „headless“ offenlässt

Headless beschreibt eine Achse: wo das Rendering stattfindet. Mehreres, was der Begriff mitzumeinen scheint, bleibt davon offen. Wo die Software läuft, ist eine eigene Frage und steht unter Selbst gehostet und SaaS im Vergleich. Das Preismodell, die Qualität der Redaktionsoberfläche und wie leicht sich Ihre Inhalte und Ihre Konfiguration herauslösen ließen, sind alle produktspezifisch; das letzte davon ist Anbieterbindung. Headless-Produkte unterscheiden sich in jedem dieser Punkte erheblich, weshalb sich eine Bewertung auf das konkrete Produkt beziehen muss.

Ein Headless-CMS ist oft der inhaltsverwaltende Teil einer umfassenderen Content-Plattform, und es ist eine der vier Ideen in MACH. Das Suite-Modell, gegen das es üblicherweise abgewogen wird, ist die DXP. Der Wechsel zwischen zwei Headless-Systemen ist ein eigenes Projekt mit derselben Form wie jeder andere Plattformwechsel, und eine Checkliste vor der Migration für nicht-technische Teams behandelt, was vor einer Entscheidung geklärt sein sollte.