Jeder Guide zu Headless CMS erklärt dieselbe Sache: Content wird von der Darstellung getrennt, eine …
Die Nachteile von Headless CMS zeigen sich erst nach dem Go-live
Jeder Guide zu Headless CMS erklärt dieselbe Sache: Content wird von der Darstellung getrennt, eine API liefert Inhalte an beliebige Kanäle, Redaktion und Entwicklung arbeiten sich nicht mehr gegenseitig im Weg. Das stimmt alles. Es ist nur die halbe Rechnung.
Die andere Hälfte kommt nach dem Go-live. Sie steht in keinem Vendor-Guide, weil sie nicht in der Zuständigkeit des CMS-Anbieters liegt, aber sie landet trotzdem auf eurem Tisch.
Was ein Headless CMS liefert, und was nicht
Ein Headless CMS liefert drei Dinge: ein Content-Modell, einen Editor und eine API. Damit ist der Job des Systems erledigt. Es rendert nichts. Es weiß nichts über Produktdaten, Preise, Verfügbarkeiten oder Warenkorb. Und es kennt die Seite nicht, auf der der Inhalt am Ende landet.
Das ist keine Schwäche, sondern die Definition der Kategorie. Problematisch wird es erst, wenn ein Projekt so geplant wird, als wäre mit der CMS-Entscheidung die Frontend-Frage mitentschieden. Das ist sie nie.
Rechnung 1: Das Frontend wird zum zweiten Produkt
Sobald der Content entkoppelt ist, braucht ihr eine Anwendung, die ihn ausspielt. In der Regel Next.js oder Nuxt, dazu Hosting, Build-Pipeline, Caching, Monitoring, Bildoptimierung, Preview-Umgebung.
Der Bau dieser Anwendung ist das kleinere Problem, er ist budgetiert und hat ein Enddatum. Der Betrieb hat keins. Framework-Major-Versionen, Dependency-Updates, Core Web Vitals nach jedem Feature, neue Anforderungen aus dem Marketing: Das Frontend ist ab Tag eins ein Produkt mit eigenem Backlog. Teams, die ein Headless CMS eingeführt haben, um schneller zu werden, sitzen zwölf Monate später oft in genau der Warteschlange, aus der sie raus wollten. Nur heißt das Ticket jetzt „Landingpage-Komponente" statt „Template-Anpassung".
Rechnung 2: Die Redaktion verliert den Kontext
Im Monolithen hat die Redaktion die Seite gesehen, an der sie gearbeitet hat. Im Headless-Setup füllt sie Felder in einem Formular und hofft, dass das Ergebnis passt.
Preview-Funktionen mildern das ab, lösen es aber selten. Die meisten Vorschauen nähern das Layout an, statt das echte Rendering zu zeigen, besonders dann, wenn Commerce-Daten, Personalisierung oder A/B-Varianten im Spiel sind. Jede Layout-Änderung, jedes Umsortieren einer Kampagnenseite, jede neue Modul-Kombination geht dann doch wieder über die Entwicklung.
Das ist der teuerste Nachteil, weil er sich nicht in einer Rechnung zeigt, sondern in Durchlaufzeit. Eine Kampagne, die drei Wochen statt drei Tagen braucht, kostet mehr als jede Lizenz.
Rechnung 3: Das Schema bindet euch länger als gedacht
Ein natives Headless CMS gibt euch ein frei modellierbares Content-Schema. Das ist die größte Stärke der Kategorie und gleichzeitig die Stelle, an der die meisten Projekte Zeit verlieren.
Content Modeling passiert am Anfang, also genau zu dem Zeitpunkt, an dem ihr am wenigsten über die tatsächliche Nutzung wisst. Was dann entsteht, bleibt. Nicht weil es gut ist, sondern weil Migrationen von Content-Strukturen teuer sind. Wer nach 18 Monaten feststellt, dass die Modellierung an der Realität vorbeigeht, rechnet nicht mit einem Refactoring, sondern mit einem Projekt.
Wann ein dediziertes Headless CMS trotzdem die richtige Wahl ist
Es gibt klare Fälle, in denen sich der Aufwand rechnet:
- Redaktionelle Tiefe. Große Content-Bestände, komplexe Beziehungen zwischen Inhalten, Versionierung, mehrstufige Freigaben.
- Viele Sprachen und Märkte mit unterschiedlichen Content-Verantwortlichkeiten pro Region.
- Content als Produkt. Verlage, Medienhäuser, Wissensplattformen, überall dort, wo Inhalt nicht die Storefront begleitet, sondern das Geschäftsmodell ist.
- Ein Team, das das System besitzt. Content-Ops als Rolle, nicht als Nebentätigkeit.
Storyblok, Contentful, Hygraph und Sanity sind in diesen Szenarien starke Systeme mit einem Reifegrad, den man nicht nachbaut. Wenn einer dieser Fälle auf euch zutrifft, ist die Antwort einfach.
Wenn keiner dieser Fälle zutrifft
Der Großteil der Händler und Marken, mit denen wir sprechen, braucht etwas anderes: Inhalte zentral pflegen, sie über eine API an mehrere Kanäle ausliefern, Bilder und Videos weltweit schnell bereitstellen. Klassische Anwendungsfälle, keine Schema-Freiheit für jeden denkbaren Fall.
Dafür ein zusätzliches System einzuführen, heißt: ein weiteres Tool im Stack, eine weitere Vertragsbeziehung, eine Schema-Design-Phase vor dem ersten sichtbaren Ergebnis. Und das Frontend-Problem aus Rechnung 1 bleibt trotzdem ungelöst.
Deshalb behandeln wir Headless-Content-Auslieferung bei Laioutr als Funktion der Plattform, nicht als eigenes Produkt. Über die Delivery-API lassen sich Text, strukturierte Inhalte, Bild und Video an jedes Frontend ausliefern, über die Management-API pflegen externe Systeme Inhalte direkt ein. Beides läuft über dasselbe globale CDN wie die Laioutr-Frontends. Kein separates Projekt, keine Schema-Phase, kein zusätzliches System.
Und wenn ihr bereits ein Headless CMS betreibt, bleibt es genau da, wo es ist: Laioutr setzt als Frontend-Ebene davor und rendert die Inhalte. Für Storyblok, Contentful und Hygraph gibt es dafür fertige Kombinationen.
Die Entscheidung, die wirklich ansteht
Die Frage ist selten „welches Headless CMS". Sie lautet: Wie viel Content-Komplexität habt ihr wirklich, und wer baut und betreibt das Frontend, das den Content am Ende ausspielt?
Wer diese zweite Frage erst nach der CMS-Auswahl stellt, beantwortet sie unter Zeitdruck. Meistens mit einem Custom-Frontend, das genau die Wartungslast erzeugt, die Composable Commerce eigentlich abschaffen sollte.
Nächster Schritt: Zeig uns deinen Stack und deine Anforderungen an Content-Verteilung, wir sagen dir, ob ihr ein dediziertes Headless CMS braucht oder nicht. Demo buchen
Weitere Themen aus der Laioutr-Plattform
- Headless CMS bei Laioutr: Content-Management als Funktion der Plattform
- Composable Headless Frontend: die Frontend-Ebene für jedes Backend
- AI Content Management: Content-Agent, Page-Composition, Multi-Locale-Sync
FAQ
Was sind die größten Nachteile eines Headless CMS?
Ein Headless CMS liefert kein Frontend. Ihr braucht zusätzlich eine eigene Anwendung, die den Content ausspielt, und müsst sie dauerhaft betreiben. Dazu kommt der Kontextverlust in der Redaktion, Inhalte werden in Formularfeldern gepflegt statt auf der Seite, und ein Content-Schema, das früh festgelegt wird und später teuer zu ändern ist.
Braucht der Mittelstand ein dediziertes Headless CMS?
Selten. Der volle Funktionsumfang lohnt sich bei großen Content-Beständen, vielen Märkten oder wenn Content das Geschäftsmodell ist. Für klassische Anwendungsfälle wie zentrale Pflege, API-Auslieferung an mehrere Kanäle und Medien über CDN reicht eine Content-Funktion innerhalb der bestehenden Plattform.
Löst ein Headless CMS das Frontend-Problem?
Nein. Es verschiebt es. Die Entkopplung macht das Frontend zu einem eigenständigen Produkt mit eigenem Backlog. Ohne eine Frontend-Ebene, die Redaktion und Marketing selbst bedienen können, landet jede Layout-Änderung wieder in der Entwicklung.
Müssen wir unser bestehendes CMS ersetzen, um Laioutr zu nutzen?
Nein. Euer CMS bleibt die Content-Quelle. Laioutr übernimmt die Frontend-Ebene und rendert die Inhalte über die jeweilige Content-API.