Schema: Links die Redaktionsoberfläche mit Eingabefeldern für Titel, Text und Bild, in der Mitte die Inhaltsdatenbank mit einer API-Schnittstelle, rechts drei getrennte Ausgabekanäle Website, Handy-App und Info-Bildschirm, die alle dieselben Inhalte über die Schnittstelle abrufen.

Headless CMS

Ein Headless CMS ist ein System zur Verwaltung von Texten, Bildern und anderen Inhalten, das selbst keine Webseite anzeigt. Es gibt die Inhalte über eine technische Schnittstelle heraus, und andere Programme entscheiden, wie sie dargestellt werden.

Eine große Nachrichtenseite besteht aus tausenden Artikeln, Bildern und Videos. Damit Redakteure diese Inhalte bearbeiten können, ohne Programmcode anzufassen, gibt es Redaktionssysteme, im Englischen Content-Management-Systeme oder kurz CMS. Klassische Systeme dieser Art machen zwei Dinge gleichzeitig: Sie verwalten die Inhalte und sie bauen daraus fertige Webseiten. Ein Headless CMS macht nur noch die erste Hälfte. Es speichert und verwaltet die Inhalte, liefert sie aber als reine Daten aus. Wie diese Daten am Ende aussehen, entscheidet ein völlig getrenntes Programm. Der Name kommt daher: Dem System fehlt der Kopf, also die Anzeigeschicht.

Ein Inhalt, viele Ausgabekanäle

Vor zwanzig Jahren landeten Inhalte fast nur auf einer Website. Heute erscheint derselbe Artikel im Browser, in einer Handy-App, in einem Newsletter, auf einem Bildschirm im Bahnhof und in der Antwort eines Sprachassistenten. Ein klassisches System, das Webseiten baut, passt zu genau einem dieser Kanäle. Für alle anderen braucht man Umwege oder ein zweites System.

Ein Headless CMS löst das anders. Der Inhalt wird einmal geschrieben und einmal gespeichert. Jeder Kanal holt sich denselben Text ab und formt ihn nach seinen eigenen Regeln. Ändert die Redaktion eine Überschrift, ändert sie sich überall. Das spart Arbeit und verhindert widersprüchliche Versionen.

Für Unternehmen ist noch ein zweiter Punkt wichtig. Die Darstellung einer Website wird alle paar Jahre komplett erneuert, die Inhalte bleiben. Wenn beides getrennt ist, kann man das Design austauschen, ohne die Inhaltsdatenbank anzufassen. Bei einem klassischen System hängt oft beides so eng zusammen, dass ein Redesign zum Großprojekt wird.

Die Schnittstelle als Übergabepunkt

Redakteure arbeiten in einer normalen Eingabemaske im Browser. Sie füllen Felder aus: Titel, Autor, Fließtext, Bild, Veröffentlichungsdatum. Diese Felder legt man vorher fest, ähnlich wie ein Formular. Der Text wird also nicht als fertige Seite gespeichert, sondern in klar benannten Einzelteilen.

Herausgegeben werden die Inhalte über eine Schnittstelle, oft API genannt. Eine Schnittstelle ist eine feste Adresse, an die ein anderes Programm eine Anfrage schickt und eine strukturierte Antwort erhält. Die Antwort ist meist eine nüchterne Liste aus Feldnamen und Werten, ohne Schriftarten, Farben oder Layout. Zwei verbreitete Techniken dafür heißen REST und GraphQL. Bei GraphQL kann das anfragende Programm genau angeben, welche Felder es braucht.

Das Darstellen übernimmt dann das sogenannte Frontend, also der Teil einer Anwendung, den Nutzer sehen. Es ruft die Inhalte ab und baut daraus die sichtbare Seite oder den App-Bildschirm. Ein häufiger Irrtum ist, ein Headless CMS sei automatisch schneller. Die Geschwindigkeit hängt vor allem am Frontend und daran, ob Seiten vorab fertig erzeugt werden. Klar ist dagegen: Ohne funktionierendes Frontend zeigt ein Headless CMS überhaupt nichts an. Die Vorschau eines Artikels muss deshalb extra gebaut werden, was Redaktionen als Nachteil empfinden.

Wer so arbeitet und wann es sich nicht lohnt

Bekannte Anbieter sind Contentful, Strapi, Sanity und Storyblok. Auch WordPress, das klassische System hinter Millionen Websites, lässt sich per Schnittstelle headless betreiben. In Stellenanzeigen und Techniknachrichten taucht der Begriff oft zusammen mit Frameworks wie Next.js auf, mit denen das Frontend gebaut wird.

Typische Nutzer sind Online-Shops, Verlage mit App und Website sowie Konzerne mit Auftritten in vielen Ländern und Sprachen. Auch für KI-Produkte wird der Ansatz interessant. Sauber strukturierte Inhalte lassen sich leichter durchsuchen und einem Sprachmodell als Wissensquelle vorlegen als unübersichtlicher Seitencode.

Für eine kleine Vereinsseite ist ein Headless CMS dagegen meist übertrieben. Man braucht Entwickler für das Frontend, wo ein klassisches System sofort eine sichtbare Website liefert. Die Entscheidung ist deshalb weniger eine Frage von modern oder veraltet, sondern eine Frage der Anzahl an Kanälen.

Subscribe free. Unsubscribe the second it sucks.

High-signal news across AI, business, UX, and tech. Every morning.