Headless CMS: Wann sich die Trennung von Inhalt und Website lohnt
Ein Headless CMS verwaltet Inhalte, ohne die Website mitzuliefern. Was das technisch bedeutet, welche Systeme infrage kommen – und in welchen Fällen ein klassisches CMS die bessere Wahl bleibt.
Ein Headless CMS ist ein Redaktionssystem ohne eigene Website. Es verwaltet ausschließlich Inhalte und gibt sie über eine Schnittstelle heraus. Wo diese Inhalte erscheinen – Website, App, Kundenportal, Bildschirm in der Filiale –, entscheidet ein davon getrenntes Frontend. Genau das meint „headless": Der Kopf, also die Darstellung, ist abgetrennt.
Bei einem klassischen CMS wie WordPress oder TYPO3 stecken Verwaltung und Darstellung im selben System. Das ist bequem, solange es genau eine Website gibt. Es wird zum Problem, sobald dieselben Inhalte an mehreren Stellen gebraucht werden – oder die Seite schneller ausgeliefert werden soll, als eine PHP-Anwendung mit Datenbank im Rücken es kann.
Warum das Thema gerade jetzt aufkommt
Fast ein Drittel des Webs läuft ohne klassisches CMS
WordPress liegt laut W3Techs bei 41,2 % aller Websites und hält 59,1 % des CMS-Marktes (Stand: 8. August 2026). Die aufschlussreichere Zahl steht direkt daneben: 30,4 % aller Websites nutzen keines der überwachten Redaktionssysteme. Diese Seiten sind nicht handgeschrieben – sie werden generiert oder an eine Schnittstelle angebunden. Der Anteil ist größer als der aller CMS-Anbieter unterhalb von WordPress zusammen.
Die Angriffsfläche sitzt in den Erweiterungen
Patchstack zählte für das Jahr 2025 11.334 neue Sicherheitslücken im WordPress-Ökosystem – 42 % mehr als im Vorjahr. Davon entfielen 91 % auf Plugins und 9 % auf Themes. Im WordPress-Kern selbst wurden sechs gefunden, alle als geringes Risiko eingestuft.
Zwei weitere Werte aus demselben Bericht erklären, warum Wartung so schwer planbar ist: 46 % der veröffentlichten Lücken hatten zum Zeitpunkt der Meldung noch keinen Patch, und bei den am stärksten angegriffenen lagen im Median fünf Stunden zwischen Veröffentlichung und aktiver Ausnutzung. Ein monatliches Wartungsfenster hilft gegen ein solches Zeitfenster nicht.
Ein Headless-Aufbau lässt diese Zahlen nicht verschwinden. Er verschiebt aber, wo sie wirken: Das Redaktionssystem steht hinter einem Login und ist kein Bestandteil der ausgelieferten Seite. Was Besucher erreichen, ist fertiges HTML – ohne Datenbank dahinter, die sich angreifen ließe.
Drei Bauweisen, drei Kostenprofile
„Headless" ist keine Ja-Nein-Frage, sondern die mittlere von drei Optionen. Der Unterschied zeigt sich weniger am Starttag als in Jahr zwei und drei.
| Bauweise | Wie eine Seite entsteht | Stärke | Schwäche |
|---|---|---|---|
| Monolithisch (WordPress, TYPO3) | Bei jedem Aufruf aus Datenbank und PHP zusammengesetzt | Alles in einem, sofort startklar, riesiges Ökosystem | Laufende Pflege, Angriffsfläche wächst mit jeder Erweiterung |
| Headless + dynamisch | Frontend holt Inhalte zur Laufzeit über die API | Inhalte sind sekundengenau aktuell, mehrere Kanäle möglich | API-Verfügbarkeit wird zum Nadelöhr, Antwortzeit hängt am Anbieter |
| Headless + statisch generiert | Inhalte werden im Build eingebacken, Server liefert fertige Dateien | Schnellste Auslieferung, praktisch keine Angriffsfläche im Frontend | Zwischen Speichern und Sichtbar liegt ein Build von ein bis zwei Minuten |
Für Unternehmensauftritte, deren Inhalte sich nicht im Minutentakt ändern, ist die dritte Variante fast immer die richtige. Sie kombiniert ein komfortables Backend mit einer Seite, an der im Betrieb wenig kaputtgehen kann. Wir bauen genau so – mehr dazu unter Websites.
Welche Systeme infrage kommen
„Das beste Headless CMS" gibt es nicht, weil sich die Systeme weniger im Funktionsumfang als im Betriebsmodell unterscheiden. Die relevante Trennlinie verläuft zwischen gehostet und selbst betrieben.
| System | Betrieb | Lizenz | Typische Stärke |
|---|---|---|---|
| Sanity | Gehostet | Proprietär | Frei modellierbare Inhalte, sehr schnelle Live-Vorschau |
| Storyblok | Gehostet | Proprietär | Visueller Editor, gut für Redaktionen ohne Technikbezug |
| Contentful | Gehostet | Proprietär | Konzernumfeld, ausgereifte Rollen- und Freigabeprozesse |
| Strapi | Selbst oder gehostet | Open Source | Volle Datenhoheit, frei erweiterbar |
| Directus | Selbst oder gehostet | Open Source | Legt sich über eine bestehende Datenbank |
| Payload | Selbst oder gehostet | Open Source | Backend und Frontend in einer Codebasis |
Zwei Fragen entscheiden hier mehr als jedes Funktionsblatt. Erstens: Wo liegen die Daten? Bei gehosteten Anbietern außerhalb der EU braucht es eine belastbare Antwort für die Datenschutzdokumentation – besonders, wenn im Redaktionssystem personenbezogene Daten auftauchen. Zweitens: Wer betreibt es? Ein selbst gehostetes Open-Source-System ist kostenlos in der Lizenz, aber nicht im Betrieb: Updates, Backups und Erreichbarkeit liegen dann bei Ihnen oder Ihrem Dienstleister.
Was sich im Redaktionsalltag tatsächlich ändert
Die Vorschau ist kein Selbstläufer mehr
Im klassischen CMS zeigt die Vorschau die fertige Seite, weil beides dasselbe System ist. Beim Headless-Aufbau muss sie eingerichtet werden. Das ist Standard und keine große Sache – aber es ist Arbeit, die im Angebot stehen sollte. Fehlt die Vorschau, schreiben Redakteure blind.
Zwischen Speichern und Sichtbar liegt ein Build
Bei statischer Generierung wird die Seite nach jeder Änderung neu gebaut. Das läuft automatisch und dauert in der Regel ein bis zwei Minuten. Wer im Minutentakt Eilmeldungen publiziert, merkt das. Wer Leistungstexte und Referenzen pflegt, merkt es nie.
Das Backend zeigt nur noch, was gebraucht wird
Der unterschätzte Vorteil: Inhaltsfelder werden vorab definiert. Es gibt keinen Seiteneditor, in dem versehentlich das Layout verrutscht, und keine 30 Einstellungen, die niemand versteht. Redakteure sehen Überschrift, Text, Bild – und sonst nichts.
Wann ein Headless CMS die falsche Wahl ist
- Die Seite hat fünf Unterseiten und ändert sich zweimal im Jahr. Dann ist jedes CMS Aufwand ohne Gegenwert. Inhalte gehören in diesem Fall direkt ins Projekt.
- Es gibt kein Team und kein Budget für den Betrieb. Ein Headless-Aufbau braucht jemanden, der ihn baut und bei Änderungen an der Struktur begleitet.
- Der Shop soll alles können. Für vollwertigen E-Commerce mit Lager, Versand und Retouren ist eine spezialisierte Shop-Plattform der kürzere Weg.
- Ein gewachsenes Plugin-Ökosystem trägt den Betrieb. Wer Mitgliederbereiche, Buchungslogik und Foren über WordPress-Erweiterungen abbildet, baut das nicht nebenbei nach. Hier ist sauberes Härten sinnvoller als ein Wechsel.
Die Entscheidung in fünf Fragen
- Werden dieselben Inhalte an mehr als einer Stelle gebraucht – etwa Website und App?
- Wie oft ändern sich Inhalte wirklich: täglich, monatlich oder jährlich?
- Wer pflegt die Inhalte, und wie technikaffin ist diese Person?
- Gibt es Anforderungen an den Datenstandort, die einen US-Anbieter ausschließen?
- Was kostet der heutige Betrieb an Zeit und Reparaturen – und was davon fiele weg?
Fällt bei Frage eins ein klares Nein und bei Frage zwei „jährlich", brauchen Sie kein Headless CMS, sondern eine schnelle statische Seite. Bei allem darüber lohnt der Blick. Wir prüfen bestehende Seiten kostenlos und sagen auch dann ab, wenn sich der Wechsel nicht rechnet.
Kurz beantwortet.
Was ist ein Headless CMS?
Ein Headless CMS ist ein Redaktionssystem, das nur Inhalte verwaltet und sie über eine Schnittstelle herausgibt – ohne die Website selbst mitzuliefern. Die Darstellung übernimmt ein getrenntes Frontend, das dieselben Inhalte auf Website, App oder Portal ausspielen kann.
Was ist der Unterschied zwischen Headless CMS und WordPress?
WordPress verwaltet Inhalte und liefert die Website in einem System aus, bei jedem Aufruf über PHP und Datenbank. Ein Headless CMS endet an der Schnittstelle; wie die Seite entsteht, ist davon unabhängig. Das macht die ausgelieferte Seite schneller und deutlich schwerer angreifbar.
Welches Headless CMS ist das beste?
Das hängt vom Betriebsmodell ab, nicht vom Funktionsumfang. Gehostete Systeme wie Sanity oder Storyblok sind schnell startklar; quelloffene wie Strapi oder Directus geben volle Datenhoheit, verlangen aber eigenen Betrieb. Entscheidend sind Datenstandort und die Frage, wer wartet.
Braucht ein Headless CMS zwingend Entwickler?
Für Aufbau und Strukturänderungen ja, für die tägliche Pflege nein. Sind die Inhaltsfelder einmal definiert, arbeiten Redakteure in einer aufgeräumten Maske mit Überschrift, Text und Bild – meist einfacher als in einem gewachsenen WordPress-Backend.
Ist ein Headless CMS DSGVO-konform?
Das System selbst entscheidet das nicht, der Betrieb tut es. Bei gehosteten Anbietern zählt der Serverstandort und der Auftragsverarbeitungsvertrag; bei selbst gehosteten Systemen liegen die Daten dort, wo Sie sie hinlegen. Wer auf EU-Hosting angewiesen ist, sollte das vor der Systemwahl klären.