Was ist ein Headless CMS? Definition, Vorteile und wann es sich lohnt

Der Name kommt vom fehlenden „Kopf": Ein klassisches CMS bringt Verwaltung und Ausgabe in einem Paket mit — Datenbank, Redaktion, Templates, Themes, Plugins, alles im selben System. Ein Headless CMS behält nur den Rumpf: Datenbank, Redaktionsoberfläche, Rechte, Versionierung. Was aus den Inhalten wird, entscheidet ein davon unabhängiges Frontend, das sie über eine API abholt.

Wie ein Headless CMS aufgebaut ist

Drei Teile, die man einzeln austauschen kann.

Die Redaktion

Dort arbeitet das Team: Beiträge anlegen, Felder befüllen, Bilder hochladen, Freigaben erteilen. Für die Redakteurin ändert sich gegenüber einem klassischen System wenig — außer dass es keine Theme-Einstellungen und keine Layout-Optionen mehr gibt, weil das Aussehen woanders entschieden wird.

Die API

Die Inhalte werden strukturiert ausgeliefert, meist als JSON über REST oder GraphQL. Ein Beitrag ist dort kein fertiges HTML-Dokument, sondern ein Satz benannter Felder: Titel, Text, Autor, Datum, Bild. Genau diese Trennung macht Mehrfachverwendung möglich — dieselbe Produktbeschreibung kann auf der Website, in einer App und in einem Katalog-PDF landen.

Das Frontend

Ein eigenes Projekt, meist mit einem Framework wie Next.js, Nuxt oder Astro. Es holt die Inhalte, baut daraus Seiten und liefert sie aus — vorgeneriert zum Build-Zeitpunkt, serverseitig gerendert pro Anfrage oder gemischt. Diese Entscheidung ist die wichtigste im ganzen Aufbau; web.dev empfiehlt seit Jahren serverseitiges oder statisches Rendering gegenüber einem vollständigen Rehydration-Ansatz im Browser.

Klassisches CMS und Headless CMS im Vergleich

	Klassisches CMS	Headless CMS
Ausgabe	Theme im selben System	eigenes Frontend über API
Kanäle	eine Website	Website, App, weitere Ausgaben
Design ändern	Theme tauschen	Frontend anpassen
Vorschau	eingebaut	muss gebaut werden
Betrieb	ein System	zwei Systeme, zwei Deployments
Erweiterungen	Plugin-Ökosystem	eigener Code
Einstiegskosten	niedrig	höher

Die Tabelle sagt schon das Wesentliche: Ein Headless-Aufbau kauft Flexibilität und Tempo mit Aufwand. Die Frage ist nie „besser oder schlechter", sondern ob dieser Tausch sich für ein konkretes Projekt rechnet.

Was Headless für die Sichtbarkeit ändert

Hier liegt der Punkt, an dem Headless-Projekte gewonnen oder verloren werden. Google verarbeitet eine Seite in drei Phasen — Crawling, Rendering, Indexierung — und JavaScript wird dabei mit einer aktuellen Chromium-Version ausgeführt. Das funktioniert, ist aber eine zusätzliche Warteschlange: Der Googlebot stellt Seiten sowohl zum Crawlen als auch zum Rendern in die Warteschlange, und wann welche Seite dran ist, ist von außen nicht sichtbar.

Ein Frontend, das seine Inhalte erst im Browser aus der API nachlädt, liefert dem Crawler in der ersten Phase also ein leeres Gerüst. Ein Frontend, das dieselben Inhalte zum Build-Zeitpunkt oder auf dem Server in HTML gießt, liefert die fertige Seite sofort. Technisch ist beides „headless"; für die Auffindbarkeit sind es zwei völlig verschiedene Projekte.

Der zweite Effekt ist Geschwindigkeit. Vorgerendertes HTML von einem CDN kommt schneller an als eine Seite, die erst eine Datenbank fragt und Templates zusammensetzt — und Google misst die technische Nutzererfahrung über die Core Web Vitals. Automatisch schnell ist ein Headless-Aufbau aber nicht: Ein überladenes JavaScript-Bundle macht jeden Vorsprung zunichte.

Wann sich ein Headless CMS lohnt

Es lohnt sich, wenn mindestens einer dieser Punkte zutrifft:

• Die Inhalte müssen an mehr als einer Stelle erscheinen — Website plus App, plus Shop, plus Filialdisplay.
• Die Website ist mehrsprachig und strukturiert, mit Inhaltstypen, die sich wiederholen.
• Performance ist ein erklärtes Ziel und nicht nur ein Wunsch.
• Das Frontend soll sich weiterentwickeln, ohne dass die Redaktion jedes Mal stillsteht.

Es lohnt sich nicht, wenn eine Firma eine siebenseitige Website betreibt, zweimal im Jahr etwas ändert und niemanden hat, der ein zweites System betreut. Dann ist ein gut gepflegtes klassisches CMS die ehrlichere Antwort — inklusive Vorschau, die man sonst selbst bauen muss.

So macht es Xerx

Wir bauen mehrsprachige Marketing-Seiten mit Headless CMS, sauberen Sitemaps, JSON-LD-Schema und Core Web Vitals im grünen Bereich. Der häufigste Aufbau in unseren Projekten ist WordPress als Content-Backend für ein Next.js-Frontend: vertraute Redaktion für das Team, moderne Performance für die Besucher. Was dabei zum Projekt passt, entscheiden wir vorher und nicht nach Geschmack — mehr dazu unter Web und Web-Apps.

Diese Seite hier ist selbst so gebaut. Das Frontend läuft auf Next.js und TypeScript, deployed auf Vercel; die Blogbeiträge kommen über die Headless-API von Structura, unserem eigenen Content-Produkt. Wir empfehlen also nichts, was wir nicht selbst betreiben — inklusive der unangenehmen Teile wie Vorschau, Cache-Invalidierung und Redirects.

Ehrlich zur Abgrenzung: Wir setzen Headless nicht als Standard durch. Wenn ein Team eine vertraute Redaktion braucht und das Projekt keinen zweiten Kanal hat, bauen wir ein klassisches WordPress-Setup — das CMS soll zum Team passen, nicht umgekehrt. Und wir übergeben in beiden Fällen mit Dokumentation, ohne Vendor-Lock-in. Das Website-Komplettpaket startet bei €4.500 als Festpreis, der vor Projektstart schriftlich feststeht.

FAQ