Ein Headless CMS verwaltet Eure Inhalte und liefert sie über eine Schnittstelle an beliebige Oberflächen aus, ohne selbst eine Website darzustellen. Das lohnt sich, wenn dieselben Inhalte auf mehreren Kanälen laufen oder Euer Frontend Anforderungen hat, die ein klassisches System bremst. Für die typische Unternehmenswebsite mit einer Redaktion ohne eigene Entwickler bleibt das klassische System meist die günstigere Wahl. Wie oft sich diese Frage stellt, zeigt die Nutzungsstatistik von W3Techs: WordPress läuft auf 40,2 % aller Websites und bei 58,7 % der Websites mit bekanntem CMS (Stand 28. September 2026).
So funktioniert ein Headless CMS
Ein klassisches CMS (Content-Management-System) erledigt zwei Aufgaben in einem System. Es speichert Texte, Bilder und Seitenstruktur, und es erzeugt daraus mit Theme und Templates die fertigen HTML-Seiten. Beim Headless-Ansatz fällt der zweite Teil weg, der sprichwörtliche Kopf. Das CMS hält die Inhalte nur noch als strukturierte Daten vor und gibt sie über eine API aus, meist als JSON über REST oder GraphQL, und die Darstellung übernimmt ein eigenes Frontend, das Entwickler zum Beispiel mit Next.js, Nuxt oder Astro bauen.
Dafür braucht Ihr nicht zwingend ein neues System. WordPress bringt eine REST-API im Kern mit, und das WordPress-Handbuch zur REST API nennt ausdrücklich den Fall, WordPress-Inhalte in völlig getrennte Anwendungen zu holen. Daneben gibt es Systeme, die von Anfang an headless gebaut sind: gehostete Dienste wie Storyblok oder Contentful und quelloffene Lösungen wie Strapi, das sich wahlweise selbst hosten oder als Cloud-Dienst nutzen lässt. Die Systeme unterscheiden sich vor allem in Redaktionsoberfläche und Betrieb. Das Prinzip ist bei allen gleich: Die Inhalte liegen in einem Pool, die Ausgabe entsteht woanders.
Das Schaubild zeigt den Unterschied im Aufbau. Links sind Inhalte und Darstellung fest miteinander verbunden und bedienen genau eine Website. Rechts versorgt ein Content-Pool über die API mehrere Ausgabekanäle gleichzeitig, etwa Website, Smartphone-App, Tablet und einen Bildschirm im Laden.
Was Headless für SEO und Redaktion bedeutet
Für Suchmaschinen zählt, was im ausgelieferten HTML steht. Google verarbeitet JavaScript-Seiten in drei Schritten, nämlich Crawling, Rendering und Indexierung, und laut Googles Leitfaden zu JavaScript-SEO kann eine Seite unterschiedlich lange in der Warteschlange für das Rendering stehen. Baut Euer Frontend die Inhalte erst im Browser zusammen, riskiert Ihr Verzögerungen bei der Indexierung, und nicht jeder Bot führt JavaScript überhaupt aus. Google empfiehlt deshalb serverseitiges Rendering oder Pre-Rendering und bezeichnet das früher verbreitete dynamische Rendering in seiner Dokumentation zum dynamischen Rendering als Behelfslösung.
Die zweite Baustelle ist die Redaktion. Im klassischen WordPress sieht Euer Team per Klick auf „Vorschau“, wie ein Beitrag aussehen wird. Im Headless-Setup muss diese Vorschau eigens programmiert werden, Next.js stellt dafür etwa einen Draft Mode für unveröffentlichte CMS-Inhalte bereit, der zwischengespeicherte Seiten für Redakteure umgeht. Auch Meta-Titel, Canonical-Tags, XML-Sitemap und strukturierte Daten entstehen im Frontend-Code. Was ein SEO-Plugin im klassischen System per Formularfeld erledigt, wird damit zur Aufgabe für die Entwicklung. Plant dafür von Anfang an Zeit ein, denn eine fehlende Vorschau bremst die Redaktion bei jedem einzelnen Beitrag.
Wann sich ein Headless CMS lohnt
Der Mehraufwand rechnet sich, wenn mindestens einer der folgenden Punkte auf Euer Projekt zutrifft. Trifft keiner zu, bezahlt Ihr für Flexibilität, die Ihr nicht nutzt, und für ein zweites System, das gewartet werden will. Neben dem CMS-Tarif, den etwa die Preisübersicht von Storyblok nach Nutzern, API-Abrufen und Datenvolumen staffelt, zahlt Ihr Entwicklung und Hosting des eigenen Frontends. Eine Unternehmenswebsite mit 20 Seiten und einer Redaktion ohne Entwickler erfüllt die Kriterien meist nicht. Prüft die Liste gemeinsam mit Redaktion und Entwicklung, denn beide Seiten tragen die Folgen der Entscheidung:
- Dieselben Inhalte laufen auf mehreren Kanälen, etwa Website, App, Kundenportal oder Bildschirmen im Laden
- Mehrere Websites oder Länderversionen sollen aus einem gemeinsamen Content-Pool gespeist werden
- Das Frontend braucht Funktionen, die ein Theme nur mit großem Aufwand abbildet, zum Beispiel einen stark interaktiven Produktkonfigurator
- Ein internes Entwicklerteam oder eine Agentur betreut Frontend, Vorschau und Hosting dauerhaft
- Eure Sicherheitsanforderungen sprechen dafür, das Redaktionssystem vom öffentlichen Web zu trennen und nur fertige Seiten auszuliefern
So plant Ihr den Umstieg ohne Ranking-Verlust
Ein Wechsel auf Headless ist technisch ein Relaunch, auch wenn die Texte gleich bleiben. HTML, Ladewege und oft auch die URLs ändern sich, und genau an diesen Stellen gehen bei Relaunches Rankings verloren. Diese Punkte gehören vor dem Go-live auf die Checkliste:
- Die Rendering-Strategie festlegen: serverseitig oder statisch vorgerendert, damit jede Seite ohne JavaScript ihren vollständigen Inhalt liefert
- Alle bisherigen URLs erfassen und per 301-Weiterleitung auf die neuen Adressen umleiten, falls sich die Struktur ändert
- Meta-Titel, Meta-Beschreibung, Canonical-Tags, hreflang und Sitemap im Frontend nachbauen und gegen die alte Seite abgleichen
- Die Vorschau für die Redaktion einrichten, bevor der erste Beitrag im neuen System entsteht
- Laufende Kosten für Frontend-Hosting, CMS-Tarif und die Wartung beider Systeme im Budget einplanen
Wer bei WordPress bleibt, spart sich den Systemwechsel und kann später immer noch headless gehen, weil die REST-API schon im Kern steckt. Vorschau, SEO-Plugin und Formulare bleiben dann erhalten, ohne dass jemand sie neu programmieren muss. Entscheidend ist dann die laufende Pflege, die wir im Beitrag zur WordPress-Sicherheit beschreiben. Ob Euer Projekt klassisch oder headless besser läuft, klären wir als WordPress-Agentur Düsseldorf an Eurem konkreten Vorhaben.
FAQs zum Headless CMS
Was ist ein Headless CMS?
Ein Content-Management-System ohne eigene Darstellungsschicht. Es speichert Inhalte als strukturierte Daten und liefert sie über eine API aus, meist per REST oder GraphQL. Wie die Inhalte aussehen, bestimmt ein separat entwickeltes Frontend. Klassische Systeme wie WordPress in der Standardinstallation liefern dagegen Inhalte und fertige Seiten aus einer Hand.
Kann WordPress als Headless CMS dienen?
Ja. WordPress bringt eine REST-API im Kern mit, über die sich Beiträge, Seiten und Medien abrufen lassen. Das Frontend baut Ihr dann getrennt, etwa mit Next.js. Plugins, die ihre Ausgabe über das Theme einbinden, wirken in diesem Aufbau nicht mehr auf die ausgelieferten Seiten. Für Formulare, Suchfunktion oder SEO-Metadaten braucht Ihr dann eigene Lösungen im Frontend.
Ist ein Headless CMS schlecht für SEO?
Nein, wenn das Frontend die Seiten serverseitig oder statisch rendert. Probleme entstehen, wenn Inhalte erst im Browser per JavaScript geladen werden, weil Google solche Seiten erst nach dem Rendering vollständig sieht. Meta-Daten und strukturierte Daten gibt in diesem Aufbau das Frontend aus. Ob Google eine Seite vollständig erfasst, prüft Ihr mit dem URL-Prüftool der Search Console.
Welche Headless-CMS gibt es als Open Source?
Strapi ist eine verbreitete Open-Source-Lösung, die Ihr selbst hosten oder als Cloud-Dienst nutzen könnt. Auch WordPress ist quelloffen und lässt sich über seine REST-API headless betreiben. Bei Open Source zahlt Ihr keine Lizenz, tragt aber Hosting, Updates und Sicherheit selbst. Welche Lösung passt, hängt vor allem davon ab, wer das System nach dem Start betreut.
Was kostet ein Headless CMS?
Die Software gibt es ab 0 €, etwa als Open Source oder im kostenlosen Starter-Tarif von Storyblok. Der Growth-Tarif von Storyblok kostet laut Preisseite 99 US-Dollar im Monat (Stand 28. September 2026). Hinzu kommen Entwicklung und Betrieb des eigenen Frontends, die je nach Projekt gesondert anfallen.
