Ein Headless-CMS ist ein Redaktionssystem ohne eigene Darstellung. Redakteure pflegen Inhalte in einer Weboberfläche, das System stellt sie über eine Schnittstelle bereit, und ein separates Frontend erzeugt daraus die Website.
Das löst ein konkretes Problem: Statische Builds sind schnell und sicher, aber ohne Redaktionsoberfläche. Klassische CMS haben die Oberfläche, sind aber langsamer und wartungsintensiver. Ein Headless-System kombiniert beides, zum Preis von zwei Systemen statt einem.
Wie es zusammenspielt
- Redakteure pflegen Inhalte im Headless-CMS, mit definierten Inhaltstypen und Feldern
- Beim Speichern löst das System einen Build im Frontend aus
- Der Build ruft die Inhalte über die Schnittstelle ab und erzeugt statisches HTML
- Das Ergebnis wird veröffentlicht
Die Verzögerung zwischen Speichern und Sichtbarkeit liegt je nach Umfang bei Sekunden bis wenigen Minuten. Für Inhalte, die sofort live sein müssen, ist das ein echter Nachteil; für alles andere ist es unerheblich.
Was es gut macht
Strukturierte Inhalte. Inhaltstypen mit definierten Feldern statt einem freien Textfeld. Ein Produkt hat Felder für Name, Preis, Maße, Bilder. Das macht Inhalte wiederverwendbar und maschinell auswertbar.
Mehrere Ausspielkanäle. Dieselben Inhalte für Website, App, Newsletter oder Partnerschnittstelle. Das ist der ursprüngliche Grund für den Ansatz.
Trennung von Inhalt und Darstellung. Ein Redesign berührt die Inhalte nicht. Ein Wechsel des Frontend-Werkzeugs ebenfalls nicht.
Komfortable Redaktion bei statischer Geschwindigkeit. Der eigentliche Gewinn für inhaltsgetriebene Projekte.
Rollen und Freigaben. Entwürfe, Vorschau, Freigabeprozesse, wie man es von einem klassischen CMS erwartet.
Was es teuer macht
Zwei Systeme. Zwei Verträge, zwei Aktualisierungspfade, zwei Fehlerquellen. Wenn ein Build fehlschlägt, muss jemand wissen, wo er nachsieht.
Vorschau ist Arbeit. Eine echte Vorschau des fertigen Layouts verlangt eine eigene Einrichtung. Ohne sie sehen Redakteure ihre Änderung erst nach dem Build.
Kosten skalieren mit Nutzung. Gehostete Headless-Systeme rechnen nach Nutzern, Abrufen oder Inhaltsmenge ab. Die Spanne reicht von kostenlos bis dreistellig monatlich.
Fachkräfte. Weniger verfügbar als für WordPress. Wenn die aufsetzende Person geht, ist die Nachfolge schwerer zu finden.
Kein Ökosystem für Standardaufgaben. Was bei WordPress ein Plugin ist, muss hier gebaut werden.
Vergleich mit den Alternativen
| Kriterium | Klassisches CMS | Statisch pur | Headless plus statisch |
|---|---|---|---|
| Redaktion ohne Technik | ja | nein | ja |
| Ladezeit | mit Arbeit gut | sehr gut | sehr gut |
| Wartungsaufwand | monatlich | kaum | gering, zwei Systeme |
| Sofort live | ja | nein | nach Build |
| Systeme zu betreuen | eines | eines | zwei |
| Sinnvoll ab | 10 Seiten | 5 Seiten | 50 Seiten |
| Einarbeitung | gering | mittel | mittel bis hoch |
Wann es die richtige Wahl ist
Passend:
- Fachportal mit über fünfzig Seiten und mehreren Redakteuren
- Verzeichnis oder Katalog mit stark strukturierten Einträgen
- Projekt, das Inhalte in mehreren Kanälen ausspielt
- Bestand, der über Jahre wachsen soll und dabei schnell bleiben muss
- Team, in dem Redaktion und Entwicklung getrennt arbeiten
Nicht passend:
- Firmenwebsite mit zehn Seiten. Zwei Systeme für zehn Seiten ist Selbstzweck
- Eine Person, die alles macht und technischen Zugang hat. Dann genügt ein statischer Build
- Inhalte, die sofort live sein müssen
- Projekte ohne Budget für laufende Betreuung
Der pragmatische Zwischenweg
Für Projekte, bei denen der Wunsch nach Geschwindigkeit besteht, die Redaktion aber WordPress kennt: WordPress als reines Redaktionssystem betreiben und das Frontend statisch bauen. Das behält die bekannte Oberfläche und die vorhandenen Inhalte.
Der Preis: Der WordPress-Teil braucht weiterhin Updates, auch wenn er nicht öffentlich erreichbar ist. Und die Vorschau funktioniert nicht ohne zusätzliche Einrichtung.
Wer diesen Weg erwägt, sollte vorher prüfen, ob nicht ein schlankes Theme mit dem Block-Editor dasselbe Geschwindigkeitsproblem billiger löst. Siehe WordPress-Performance.