Headless CMS Was es bedeutet und wann es sich lohnt

Ein klassisches CMS wie TYPO3 oder WordPress erledigt zwei Aufgaben. Die Redaktion pflegt im Backend die Inhalte, und das System baut daraus die fertigen Seiten der Website. Backend und Frontend stecken im selben System.

Bei einem Headless CMS fällt der zweite Teil weg. Das System gibt die Inhalte über eine Schnittstelle aus, meist im Format JSON, und eine eigene Anwendung macht daraus die Oberfläche. Das kann ein Frontend mit React oder Vue sein, eine App für iOS und Android oder die Anzeige auf einem Bildschirm. Daher der Name: Dem CMS fehlt der Kopf, also die Darstellung.

Ob Headless für ein Projekt sinnvoll ist, hängt vor allem davon ab, wo die Inhalte gebraucht werden und was die Oberfläche können muss. In zwei meiner Projekte war Headless die richtige Wahl.

Für eine Agentur habe ich ein Planungstool entwickelt, in dem Aufgaben per Drag-and-drop auf Tage und Personen verteilt werden. Die Oberfläche ist eine React-Anwendung, die im Browser schnell zwischen Wochen und Ansichten wechselt. TYPO3 stellt im Hintergrund Mitarbeitende, Kunden und Jobs über eine REST-Schnittstelle bereit und übernimmt Anmeldung, Rollen und Rechte. Seiten im üblichen Sinn gibt TYPO3 hier gar nicht aus.

Beim Mixometer pflegt der Hersteller den Produktkatalog in TYPO3. Eine App für iOS und Android ruft ihn über eine Schnittstelle ab, hält ihn auf der Baustelle auch ohne Internetverbindung vor und schickt die passende Wassermenge per Bluetooth an das Gerät.

In beiden Fällen ist die Oberfläche keine Website mit Seiten, sondern eine Anwendung. Genau dafür ist Headless gedacht.

Häufiger als ein reines Headless-Projekt ist der Mittelweg. Für ein Theater erzeugt TYPO3 den Spielplan ganz klassisch als Seiten der Website. Dieselben Daten stellt es zusätzlich über eine API für externe Terminkalender bereit, und auch die Displays im Foyer greifen darauf zu. Der Spielplan wird an einer Stelle gepflegt und erscheint überall im selben Stand.

Für die meisten Unternehmenswebsites passt das am besten. Die Website behält alles, was ein CMS mitbringt, und andere Anwendungen bekommen trotzdem ihre Daten.

Ein Headless-Projekt besteht aus zwei Anwendungen, die gebaut, betrieben und aktualisiert werden. Einiges, was ein klassisches CMS von Haus aus mitbringt, übernimmt dann das Frontend: die Vorschau für die Redaktion, Mehrsprachigkeit, Weiterleitungen und Seiten, die Suchmaschinen und KI-Systeme ohne JavaScript lesen können. Frameworks wie Next.js oder Nuxt decken das gut ab. Es bleibt aber Arbeit, die bei einer klassischen Website nicht anfällt.

Die Redaktion arbeitet weiter im gewohnten Backend. Wie ein Inhalt am Ende aussieht, erfährt sie allerdings nur, wenn das Frontend eine Vorschau dafür bereitstellt. Die gehört deshalb von Anfang an in die Planung.

Beide Systeme lassen sich headless betreiben. Für TYPO3 gibt die Extension headless der TYPO3-Community Seiten und Inhaltselemente als JSON aus. Für eigene Datenmodelle kann die Schnittstelle auch direkt in einer individuellen Extension entstehen, zugeschnitten auf das, was die Anwendung braucht. WordPress hat mit der REST-API schon eine Schnittstelle an Bord, für GraphQL gibt es das Plugin WPGraphQL.

Und wenn eine Website gar nicht mehr redaktionell gepflegt wird, geht es auch ganz ohne laufendes CMS: Mit Freezed entsteht aus Fluid-Templates reines HTML.