Glossar Headless CMS
Ein Headless CMS ist ein Content-Management-System, das Inhalte speichert und ordnet und sie als Daten über eine API ausliefert, ohne eigene Darstellungsschicht. Die Website, die App oder der Bildschirm, auf dem die Inhalte erscheinen, wird getrennt gebaut. Contentful definiert es als CMS, das die Darstellungsschicht vom Backend trennt, in dem die Inhalte verwaltet werden. Manchmal wird es mit „Decoupled CMS“ gleichgesetzt, obwohl decoupled genau genommen eine andere Bauart ist.
Ein Headless CMS verwaltet Inhalte und liefert sie per API aus, ohne eigene Darstellung. Wie es funktioniert und was es von decoupled trennt.
„Headless“ heißt auf Englisch „kopflos“. Merriam-Webster belegt das Adjektiv seit der Zeit vor dem 12. Jahrhundert, mit den Bedeutungen „ohne Kopf“ und „ohne Oberhaupt“. Bei einem CMS ist der Kopf die Darstellungsschicht. Sanity erklärt das mit dem Bild von Körper und Kopf: Im Körper werden die Inhalte gespeichert, im Kopf werden sie dargestellt. Ein Headless CMS behält den Körper und überlässt den Kopf anderen Systemen, die die Inhalte per API abfragen.
Diese Daten markieren den Weg der Architektur, nicht die Entstehung des Worts:
Am Anfang steht das Content-Modell. Laut Contentful legt das Team zuerst die Inhaltstypen und die Felder jedes Typs fest, zum Beispiel einen Typ „Artikel“ mit Titel, Haupttext, Veröffentlichungsdatum und Autor, und legt danach die Einträge an. Contentful erlaubt außerdem Verweise zwischen Einträgen, so dass der Autor ein eigener Eintrag sein kann, den mehrere Artikel nutzen.
Die Inhalte verlassen das CMS über eine API, meist als JSON. Contentful trennt zwei Haupt-APIs. Die Content Delivery API ist nur lesend, liefert veröffentlichte Inhalte und Mediendateien (Bilder, Videos) aus und läuft über ein CDN. Die Content Management API liest und schreibt: Mit ihr legst du Inhalte an und änderst sie, und sie gibt auch Unveröffentlichtes und alle Sprachfassungen zurück. Contentful rät aber davon ab, mit ihr große Mengen an Inhalten auszuliefern. Strapi bietet seine Content API über REST und GraphQL an.
Ändert sich etwas, kann das CMS andere Systeme per Webhook benachrichtigen. Contentful definiert Webhooks als HTTP-Callbacks, die bei Änderungen Bescheid geben, damit externe Systeme reagieren, etwa mit einem Neuaufbau der Website. In Strapi wählst du die Ereignisse je Inhaltstyp, zum Beispiel entry.publish.
Weil das CMS kein HTML erzeugt, entscheidet das Frontend, wo und wann jede Seite gerendert wird. Astro rendert Seiten standardmäßig beim Build als statische Dateien vor; laut Astro zeigt eine auf Abruf gerenderte Seite frisch geänderte Daten, ohne dass die ganze Website neu gebaut wird. Next.js behandelt Layouts und Seiten standardmäßig als Server Components, die auf dem Server gerendert werden. Bei statischen Seiten startet der Webhook beim Veröffentlichen den neuen Build; beim serverseitigen Rendering kommt der neue Inhalt mit der nächsten Anfrage. Wird alles im Browser zusammengesetzt, ist das clientseitiges Rendering.
Für die Redaktion ändert sich vor allem die Vorschau, denn das CMS hat die fertige Seite nicht. Contentful bietet eine Preview API mit veröffentlichten und unveröffentlichten Inhalten und eigenem Token; Produktions-Tokens funktionieren dort nicht, damit keine unveröffentlichten Inhalte nach außen gelangen. In Next.js sehen Redakteure im Draft Mode, wie ein Entwurf aussehen wird, während alle anderen Besucher weiter die gecachte Fassung bekommen. Storyblok bietet einen visuellen Editor mit Vorschau im Kontext und Abläufe für Entwurf, Prüfung und Veröffentlichung.
| Art | Wie es läuft | Beispiele |
|---|---|---|
| Cloud-Dienst mit API | Der Anbieter betreibt Backend und API; das Team baut nur das Frontend | Contentful, Storyblok |
| Selbst betrieben | Das Team installiert und wartet das CMS auf eigener Infrastruktur; manche Anbieter haben zusätzlich eine Cloud-Fassung | Directus, Payload, Strapi |
| Git-basiert | Inhalte liegen als Dateien im Repository, neben dem Code | Decap CMS |
| Klassisches CMS im Headless-Betrieb | Ein CMS mit eigenen Vorlagen liefert seine Inhalte zusätzlich per API aus | WordPress (REST API), Drupal (JSON:API), Ghost (Content API) |
Quelle: Dokumentation und Seiten von Contentful, Storyblok, Directus, Payload, Strapi, Decap CMS, WordPress, Drupal und Ghost (abgerufen am 15.11.2026).
Die Kategorien überschneiden sich. Hygraph nennt Strapi Cloud als Beispiel für einen Cloud-Dienst, der auf Open Source aufbaut. Wie WordPress als Headless CMS läuft, erklärt sein eigener Eintrag.
Contentful beschreibt den Aufruf einer Produktseite so:
Dieselbe API kann gleichzeitig eine Website, eine App oder einen Bildschirm versorgen, jeweils mit eigenem Design. Ein Beispiel für das Veröffentlichen auf einer statischen Website: Eine Redakteurin veröffentlicht in Strapi einen Artikel, Strapi schickt das Ereignis entry.publish, der Build-Dienst erzeugt die Seiten mit Astro neu und das CDN liefert die neue Fassung aus.
Ob sich ein Headless CMS lohnt, hängt vom Fall ab:
| Fall | Was es bringt | Was es kostet |
|---|---|---|
| Eine Website, viel Redaktion, wenig Entwicklung | Hängt davon ab, was die Redaktion braucht; ein klassisches CMS bringt das meiste schon mit | Eigenes Frontend, eigens gebaute Vorschau und weniger Bearbeitung direkt auf der Seite |
| Mehrere Kanäle (Web, App, Bildschirme) | Ein Inhaltsspeicher und eine API für alle Frontends | Ein Frontend je Kanal, jedes mit eigener Wartung |
| Mehrere Sprachen | Das CMS verwaltet die Übersetzungen jedes Eintrags | URLs je Sprache und hreflang-Tags erzeugt das Frontend |
| Onlineshop | Inhalte werden getrennt von Katalog und Bestellungen gepflegt | Das CMS mit dem Shopsystem verbinden |
Quelle: Contentful, „Headless CMS explained in one minute“; Sanity, „Headless CMS 101“; Dries Buytaert, „How to decouple Drupal in 2019“ (abgerufen am 15.11.2026).
Dries Buytaert fasst es so zusammen: Für eine überwiegend redaktionelle Organisation kann die Entkopplung problematisch sein, weil sie der Redaktion Kontrolle über die Darstellung nimmt.
| Bauart | Wer das HTML erzeugt | Beispiel |
|---|---|---|
| Gekoppelt (traditionell) | Das CMS selbst mit seinen Vorlagen oder Themes | Drupal oder WordPress mit Theme |
| Decoupled | Das CMS bringt eine Darstellungsschicht mit, die du nutzen kannst, aber nicht musst; es liefert auch per API aus | Ghost mit seiner Theme-Schicht; progressiv entkoppeltes Drupal |
| Headless | Ein anderes System; das CMS hat keine Darstellungsschicht | Contentful, Strapi |
Quelle: Contentful, Abschnitt „The difference between headless CMS and decoupled CMS“; Sanity, „Headless CMS 101“; Dries Buytaert, „How to decouple Drupal in 2019“; Ghost-Dokumentation (abgerufen am 15.11.2026).
Die Begriffe werden nicht einheitlich verwendet: Contentful schreibt, manche benutzten sie gleichbedeutend, obwohl sie nicht identisch seien, und Sanity, sie würden oft vermischt. Bei Drupal heißt das, was beide headless nennen, „vollständig entkoppelt“.
Den Grundvergleich zwischen traditionellem und Headless CMS findest du im Eintrag CMS. Dasselbe Prinzip im Shop heißt Headless Commerce: Das Headless CMS verwaltet Inhalte, die Commerce-Engine die Verkaufslogik.
| Werkzeug | Laut Anbieter |
|---|---|
| Contentful | Liefert Inhalte über eine nur lesende API unter cdn.contentful.com aus, über ein CDN; Vorschau über eine eigene API |
| Directus | „Collaborative Backend & Headless CMS“; selbst betrieben oder in der Directus Cloud; eigene Lizenz (MSCL-1.0), jede Version steht nach vier Jahren zusätzlich unter GPL-3.0 |
| Hygraph | Plattform für strukturierte Inhalte: modelliert Inhalte als Entitäten und Beziehungen und liefert sie über eine GraphQL-API aus |
| Payload | „The Next.js Headless CMS and App Framework“; MIT-Lizenz |
| Sanity | „The Content Operating System for the AI era“; der Editor Sanity Studio steht unter MIT-Lizenz |
| Storyblok | Vom Anbieter betriebener Cloud-Dienst mit visuellem Editor und Vorschau im Kontext |
| Strapi | „Open-Source TypeScript Headless CMS“; MIT-Lizenz außer dem Code der Enterprise Edition; Strapi Cloud oder selbst betrieben |
| WordPress | Klassisches CMS, das seit Version 4.7 seine Inhalte über die REST API ausliefert |
Quelle: Seiten, Dokumentation und Lizenzen der Anbieter (abgerufen am 15.11.2026). Alphabetisch, ohne Wertung.
Das Frontend ist nicht dabei: Laut Contentful liegt es immer in der Verantwortung des Kunden. Sanity, das selbst ein Headless CMS verkauft, räumt ein, dass das die Kosten und den Aufwand am Anfang erhöhen kann und dass die Abhängigkeit von Entwicklern Änderungen verlangsamen kann. Funktionen, die ein klassisches CMS mitbringt, etwa das Bearbeiten direkt auf der Seite oder Layouts aus Bausteinen, musst du neu bauen; Dries Buytaert warnt, dass das zeitaufwendig und teuer sein kann.
Bei Cloud-Diensten ist die API-Nutzung je nach Tarif begrenzt. Contentful legt Aufrufe pro Sekunde und Space fest: in den bezahlten Tarifen 78 für die Delivery API und 10 für die Management API. Hygraph behauptet, die Abhängigkeit vom Anbieter sei geringer, weil die Inhalte in einem per API ausgelieferten Format vorliegen; das ist eine Aussage des Anbieters.
Von allein löst ein Headless CMS kein SEO-Problem. Title, Meta-Description, Canonical, hreflang und Sitemap müssen als Felder im Modell stehen, und das Frontend muss sie ins HTML schreiben. Google empfiehlt serverseitiges Rendering oder Pre-Rendering, weil es die Website für Nutzer und Crawler schneller macht und nicht jeder Bot JavaScript ausführt. Wie wir das mit einem Headless CMS und Astro gelöst haben, steht in unserem Artikel zu Headless CMS und SEO.
Dieser Eintrag entstand im November 2026 mit Unterstützung von KI. Die Angaben stammen aus der Dokumentation und den Seiten der Anbieter, den Release Notes von WordPress und Drupal, dem Blog von Dries Buytaert, der Dokumentation von Astro, Next.js und Google sowie dem Wörterbuch Merriam-Webster. Er wurde vor der Veröffentlichung geprüft und enthält keine Kundendaten.
Eine technische Prüfung sieht sich das und alles Weitere in einem Durchgang an.
Audit anfragen„Kopflos“. Der Kopf ist die Schicht, die die Inhalte darstellt; ein Headless CMS speichert sie nur und liefert sie aus.
Unter anderem Contentful, Directus, Hygraph, Payload, Sanity, Storyblok und Strapi. WordPress, Drupal und Ghost sind klassische CMS, die auch im Headless-Betrieb laufen können.
Ein Decoupled CMS bringt eine optionale Darstellungsschicht mit und liefert zusätzlich per API aus; ein Headless CMS hat keine Darstellungsschicht. Contentful und Sanity weisen beide darauf hin, dass die Begriffe vermischt werden.
Du musst das Frontend bauen und warten, die Vorschau einrichten und Bearbeitungsfunktionen nachbauen, die ein klassisches CMS mitbringt. Bei Cloud-Diensten ist die API-Nutzung je nach Tarif begrenzt.
Ja. Seit Version 4.7 vom Dezember 2016 liefert WordPress Beiträge, Seiten und weitere Daten als JSON über seine REST API aus, und ein anderes System erzeugt die öffentlichen Seiten.