Headless CMS: Was steckt hinter dem Konzept?

Ein Headless CMS verwaltet Inhalte, kümmert sich aber nicht darum, wie sie aussehen. Texte, Bilder und Produktdaten liegen strukturiert in einem Backend und werden über eine Programmierschnittstelle an Website, App oder jedes andere Ausgabegerät geliefert. Das klingt nach einem Detail der Software-Architektur, verändert aber, wer an einer Website was arbeitet, was sie kostet und wie schnell sie lädt. Dieser Beitrag erklärt das Konzept, die Architektur, die Abwägungen und die Frage, für wen sich der Umstieg lohnt.

#was-ist-ein-headless-cms-eine-einfache-definitionWas ist ein Headless CMS? Eine einfache Definition

Ein Content-Management-System, kurz CMS, besteht klassisch aus zwei Teilen: dem Backend, in dem Redakteurinnen Inhalte anlegen und bearbeiten, und dem Frontend, das diese Inhalte als fertige HTML-Seite ausliefert. Bei einem Headless CMS fehlt der zweite Teil. Der Kopf – das Frontend – ist abgetrennt, daher der Name.

Wer auf Englisch nach „headless CMS – what is it?“ sucht, findet meist dieselbe Kurzformel: Content wird einmal gepflegt und über eine API an beliebige Kanäle ausgegeben. API steht für Application Programming Interface, also eine definierte Schnittstelle, über die ein Programm Daten von einem anderen abfragt. Das Frontend ist ein eigenständiges Projekt, das diese Daten abholt und darstellt.

Die Headless-CMS-Definition lässt sich deshalb in drei Merkmalen zusammenfassen:

1. Inhalte sind strukturiert. Statt einer langen Seite mit eingebettetem Layout gibt es Felder: Titel, Teaser, Fließtext, Bild, Autor, Veröffentlichungsdatum.
2. Die Ausgabe läuft über eine API. Üblich sind REST oder GraphQL, die Antwort kommt als JSON.
3. Das Frontend ist frei wählbar. Ob React, Vue, ein statischer Generator wie Hugo oder eine native Smartphone-App – das CMS schreibt nichts vor.

Besonders häufig wird ein Headless CMS mit statischen Generatoren kombiniert. Das CMS liefert die Inhalte, der Generator baut daraus fertige HTML-Dateien, die von einem Content Delivery Network ausgeliefert werden. Wie solche Seiten grundsätzlich funktionieren, erklärt der Beitrag Was ist eine statische Website?

#headless-und-traditionelles-cms-wo-liegen-die-unterschiedeHeadless und traditionelles CMS: Wo liegen die Unterschiede?

Das bekannteste traditionelle CMS ist WordPress. Nach den Zählungen von W3Techs läuft es seit Jahren auf über 40 Prozent aller Websites. Es ist ein monolithisches CMS: Datenbank, Verwaltungsoberfläche, Theme und Ausgabe bilden eine Einheit. Wer einen Beitrag speichert, sieht ihn im Theme so, wie die Besucher ihn sehen werden.

Die Unterschiede zum Headless-Ansatz lassen sich an wenigen Kriterien festmachen:

Zwischen beiden Welten gibt es Mischformen. Ein entkoppeltes, sogenanntes decoupled CMS bringt ein eigenes Frontend mit, stellt die Inhalte aber zusätzlich über eine API bereit. WordPress selbst gehört inzwischen in diese Kategorie: Seit Version 4.7 aus dem Dezember 2016 enthält der Kern eine REST-API, und mit dem Plugin WPGraphQL lässt sich eine GraphQL-Schnittstelle ergänzen. Einige der verbreiteten Vorurteile über WordPress räumt der Beitrag 7 WordPress-Mythen aufgeklärt aus.

Für die Praxis heißt das: Die Frage ist selten „WordPress oder Headless“, sondern wie viel Trennung zwischen Inhalt und Darstellung ein Projekt tatsächlich braucht.

#die-architektur-wie-funktioniert-ein-headless-systemDie Architektur: Wie funktioniert ein Headless-System?

Ein Headless-Projekt besteht aus mindestens drei Bausteinen, die getrennt betrieben werden.

Inhaltsmodell und Backend

Am Anfang steht das Inhaltsmodell. Hier legen Sie fest, welche Inhaltstypen es gibt und welche Felder sie haben – etwa „Blogbeitrag“ mit Titel, Slug, Teaser, Text und Titelbild oder „Produkt“ mit Name, Preis und Varianten. Diese Arbeit ist aufwendiger als bei einem klassischen System, zahlt sich aber aus: Strukturierte Felder lassen sich später in jedem Kanal sauber wiederverwenden, auch für strukturierte Daten nach Schema.org.

API-first: die Schnittstellen

Viele Anbieter folgen einer API-first-Architektur. Das bedeutet, dass jede Funktion des Systems über die Schnittstelle erreichbar ist, nicht nur über die Oberfläche. Häufig gibt es mehrere APIs: eine Content Delivery API, die veröffentlichte Inhalte lesend ausliefert und meist über ein CDN gecacht wird, eine Management-API zum Anlegen und Ändern von Inhalten und eine Preview-API für unveröffentlichte Entwürfe.

Frontend und Auslieferung

Das Frontend holt die Inhalte entweder bei jedem Seitenaufruf ab (Server-Side Rendering) oder einmal beim Bauen der Seite (Static Site Generation). Im zweiten Fall löst ein Webhook – eine automatische Benachrichtigung des CMS – bei jeder Veröffentlichung einen neuen Build aus. Verbreitete Werkzeuge dafür sind Next.js, Nuxt, Astro, Hugo und Eleventy.

Welche Variante sich eignet, hängt davon ab, wie oft sich Inhalte ändern. Ein Blog mit zwei Beiträgen pro Woche kommt mit statischen Builds gut aus. Ein Shop mit Lagerbeständen, die sich minütlich ändern, braucht serverseitiges Rendering oder dynamische Teilbereiche.

#vorteile-und-nachteile-von-headless-content-managementVorteile und Nachteile von Headless Content Management

Die Vorteile eines Headless CMS sind real, gelten aber nicht für jedes Projekt. Ebenso real sind die Kosten, die erst im Betrieb sichtbar werden.

Was für Headless spricht

• Flexibilität im Frontend: Das Entwicklungsteam wählt Framework und Technik frei und kann das Frontend austauschen, ohne die Inhalte zu migrieren.
• Omnichannel: Derselbe Inhalt landet auf Website, App, Infoterminal oder in einem Newsletter-System, ohne doppelt gepflegt zu werden.
• Ladezeit: Statisch erzeugte Seiten aus einem CDN kommen ohne Datenbankabfrage beim Aufruf aus. Wie sich Ladezeiten messen und verbessern lassen, beschreibt der Beitrag Steigerung der Websiteperformance.
• Angriffsfläche: Die Verwaltungsoberfläche ist vom öffentlich erreichbaren Frontend getrennt. Ein Angreifer, der die Website aufruft, erreicht die Datenbank nicht direkt.

Was dagegen spricht

• Entwicklungsaufwand: Ohne Frontend-Entwicklung entsteht keine Website. Funktionen, die bei WordPress ein Plugin erledigt – Kontaktformular, Suche, Weiterleitungen, Sitemap –, müssen gebaut oder als eigener Dienst eingebunden werden.
• Vorschau und Bearbeitung: Redakteurinnen sehen nicht automatisch, wie ein Beitrag auf der Seite aussieht. Manche Anbieter wie Storyblok bringen einen visuellen Editor mit, bei anderen muss eine Vorschau eingerichtet werden.
• Mehrere Rechnungen: Neben dem CMS fallen Kosten für Hosting des Frontends, Build-Dienste und gegebenenfalls Suche oder Formulare an. Bei SaaS-Anbietern hängen die Preise oft an Nutzerzahl, Inhaltsmenge und API-Aufrufen.
• Abhängigkeit vom Team: Wer die Website ändern will, braucht für alles außer Inhalten jemanden, der den Code kennt.

#für-wen-lohnt-sich-der-umstieg-auf-headlessFür wen lohnt sich der Umstieg auf Headless?

Am deutlichsten profitieren Projekte, in denen Inhalte auf mehreren Kanälen erscheinen. Typische Anwendungsbeispiele sind ein Onlineshop mit begleitender App, ein Verlag, der Artikel auf Website, Newsletter und Partnerplattformen ausspielt, oder ein Hersteller, der Produktdaten für Website, Händlerportal und Messedisplays aus einer Quelle pflegt.

Sinnvoll ist Headless auch, wenn ein Entwicklungsteam ohnehin mit einem modernen JavaScript-Framework arbeitet und das Frontend selbst kontrollieren will. Hier fällt der Mehraufwand kaum ins Gewicht, weil das Frontend sowieso gebaut wird.

Weniger sinnvoll ist der Umstieg für eine kleine Unternehmenswebsite mit zehn Unterseiten, die eine Person ohne Programmierkenntnisse pflegt. Für einen Onepager oder eine einfache Firmenpräsenz reicht ein klassisches CMS oder ein Baukasten. Welche Werkzeuge und Kosten für Gründer realistisch sind, fasst der Beitrag Webdesign für Gründer: Werkzeuge, Kosten und Ablauf zusammen.

Bei der Auswahl eines Systems stehen grob zwei Wege offen. SaaS-Dienste wie Contentful, Storyblok, Sanity oder Hygraph laufen beim Anbieter, sind schnell eingerichtet und werden monatlich abgerechnet. Open-Source-Systeme wie Strapi, Directus oder Payload werden selbst gehostet, verursachen keine Lizenzkosten, aber Aufwand für Server, Updates und Backups. Für Projekte mit Daten aus der EU lohnt zudem ein Blick darauf, wo der Anbieter die Daten speichert.

Als Faustregel gilt: Wenn Sie heute nur eine Website brauchen und niemanden haben, der ein Frontend baut und pflegt, ist Headless die teurere Lösung für ein Problem, das Sie noch nicht haben.

#häufige-fragen-faqHäufige Fragen (FAQ)