Headless-CMS aus der Sicht einer Entwicklerin

Dies ist kein Headless-Gebashe. Dies ist meine persönliche Meinung, die auf meinem Fachwissen (Ja, ich hab mal Informatik studiert und weiß, wie man programmiert) und meinen persönlichen Erfahrungen (ich arbeite auch für Kunden in Headless Systemen) basiert. Also lies es dir durch, wenn du das Thema durch die Lisa-Brille lesen willst. Ganz ehrlich und fundiert.

Es gibt gerade einen ziemlich seltsamen Trend im Web.

Sobald eine Website nicht aus:

ist sie plötzlich altmodisch und schlecht.

Und ganz ehrlich?

Viele Unternehmen lassen sich davon brutal beeindrucken.

Denn natürlich klingt das alles erstmal wahnsinnig modern:

Das Problem beginnt schon im Pitch

Viele Headless-Pitches hören sich erstmal genial an.

Schneller. Moderner. Flexibler. Skalierbarer. Zukunftssicher.

Und ja: Technisch gesehen kann Headless absolut sinnvoll sein. Aber genauso kopflos wie dieses Content Management System ist, wird auch manchmal entschieden.

Denn Headless heißt auch:

Und das wird im Pitch quasi nie thematisiert.

Denn die Architektur sieht auf PowerPoint halt sexy aus.

Der Alltag damit oft weniger.

Okay das war ein Witz. Also das mit PowerPoint. Die coolen Agenturen nutzen natürlich Miro, Keynote, Prezi und wie sie alle heißen.

Was ein Headless CMS überhaupt ist

Vereinfacht gesagt trennt ein Headless CMS das Backend vom Frontend.

Also:
Das CMS verwaltet nur noch Inhalte.
Die eigentliche Website wird separat gebaut – meistens mit modernen Frontend-Frameworks wie React, Next.js oder ähnlichem JavaScript-Gedöns. Sidenote: Ich hab früher mit Angular Web-Apps entwickelt. Und ich habs geliebt. Das ist wirklich ne großartige Technologie. Aber halt nicht für Websites.

Aber zurück zum eigentlichen Thema:

Das CMS liefert dann Inhalte über APIs aus.
Die Website holt sich diese Inhalte und baut daraus die Darstellung.

Klingt erstmal ziemlich fancy. Aber APIs sind keine Raketenwissenschaft. APIs gibts überall. Sogar WordPress nutzt APIs. APIs sind Schnittstellen (application programming interface). Und ich würde behaupten, dass ich ganz tief drinnen war im API-Game. Denn ich hab in meiner Ausbildung SOAP gemacht und musste eine WSDL von Hand schreiben. Und ich liebe REST-APIs. Die sind so einfach. So toll. Und werden überall eingesetzt. Wie gesagt, auch bei WordPress. Also warum muss man API’s als etwas ganz besonders darstellen, wenn sie doch überall verwendet werden? Das wäre, als würde ich die Schrauben in meinem Schreibtisch als heiligen Gral betrachten.

Früher war vieles einfach(er):
CMS, Inhalte und Frontend lebten zusammen.

Heute hast du plötzlich:

• ein CMS
• ein Frontend
• APIs
• Build-Prozesse
• Deployments
• Hosting
• eventuell zusätzliche Services

Und genau da wird aus der „modernen Website“ ziemlich schnell:
„Warum brauchen wir für eine Textänderung plötzlich drei Entwickler?“ 😄

Funfact: Ich wollte mal für einen Kunden im Headless CMS eine kaputte Verlinkung im Header rausmachen. Mit WordPress wäre das easy gegangen. Beim headless konnte ich das nicht selber machen, obwohl ich wusste was ich im Code tun musste. Stattdessen musste ich ein Ticket schreiben und 2 Wochen warten, bis der Link wieder ging, weil die Agentur noch andere Dinge zu tun hatte und jemand im Urlaub war.

Der kopflose Aufbau

Okay, das war jetzt vielleicht etwas zu frech von mir. Denn eigentlich ist die Intention hinter Headless nicht kopflos. Die Trennung zwischen Backend und Frontend hat seine absolute Berechtigung. Wir sprechen hier von Software-Pattern wie MVVM oder MVC. Das ist genial. Das hat die Softwareentwicklung so viel besser gemacht. Aber wer sagt, dass bei einem CMS wie WordPress, Joomla oder Typo nicht auch die Logik sauber von den Styles und vom Benutzer getrennt sind? Kein Nutzer muss da coden können. Ich finde CMS Systeme erfüllen absolut denselben Anspruch.

Der Unterschied ist nur: CMS Systeme bringen schon sehr viel mit: Elemente, Typen, Funktionen. Das Headless System ist nackt: Man baut sich nur das, was man auch braucht. Und das find ich auch sexy. Man trägt keinen Ballast mit sich und hat keine Overhead. Das ist schnell. Und man kanns so machen, wie man es haben möchte.

Und es ist teuer.

Die versteckten Kosten sieht am Anfang niemand

Am Anfang sieht Headless oft wahnsinnig effizient aus.

Bis die Realität kommt.

Denn plötzlich braucht man:

• Frontend-Entwicklung
• API-Wartung
• Hosting-Know-how
• Build-Pipelines
• Deployment-Prozesse
• Framework-Updates
• Monitoring
• Fehlerhandling
• Schnittstellenpflege

Und dann kommt irgendwann dieser Satz:

„Für diese kleine Änderung brauchen wir leider ein neues Deployment.“

Autsch.

„Future-ready“ klingt toll — bis die Rechnung kommt

Ich liebe dieses Wort inzwischen fast 😄. Wenn ich jedes Mal, wenn dieses Wording irgendwo auftaucht, einen Kilt produzieren würde, dann könnte ich Bühnenausstatterin für Outlander werden. Und zwar auf dem Schlachtfeld.

„Future-ready.“

Richtig fancy.

Die Frage ist nur:
Future-ready für WAS?

Für:

Oder eher für die nächste Entwicklerkonferenz?

Doch was ist, wenn irgendwann:

Und dann wird’s plötzlich sehr un-future-ready.

Wer pflegt das eigentlich später?

Diese Frage wird viel zu selten gestellt. Und wenn doch, dann heißt das „Pflegen? Könnt ihr später easy selber!“

Ich sag jetzt mal wie easy das ist. Bei 2 Kunden arbeite ich mit Storyblok, bei einem Kunden mit Pimcore. Natürlich hängt es auch immer von der Agentur ab, die das Headless aufgezogen hat. Da gibt’s im selben System oft Unterschiede.

Also nicht alles, was du jetzt hier liest, ist automatisch bei allen Headless Systemen so. Ich zähl jetzt nur mal ein paar Dinge auf bei denen ich dachte „Mit WordPress wäre das easy gewesen – warum hier nicht?“. Also ja, möglich ist alles. Aber wieso hab ichs dann nicht, wenns möglich ist? Weils extra Geld kostet.

Redirects

Sind super wichtig für den Nutzer. Und für SEO. Niemand will im Nirwana landen. Doch leider muss ein ordentliches Redirection System immer erst teuer entwickelt werden. Das ist kein Standard. Und meist gibt es noch genug andere offene Tasks oder kein Budget mehr. Bei einem Projekt muss ich auf Redirects verzichten (mein Herz blutet jedes Mal), beim anderen System muss ich sie total umständlich eintragen und kann nicht mal suchen. Bei WordPress wäre es ein kostenloses Plugin gewesen – bzw. mein SEO-Plugin bringt es schon mit sich. Oder ich machs bequem über die .htaccess.

Eine Überschrift anders aussehen lassen

Bei WordPress mit dem Standardeditor ist gleich die Farbe oder Größe einer Überschrift verändert, ohne die Hierarchie ändern zu müssen. Beim Headless-CMS muss erst ne neue Variante angelegt werden. Also bleibt man bei den Möglichkeiten, die man hat.

Ich will nicht nach Amerika telefonieren!

Storyblok ist zum Beispiel so cool, dass sie Dateien über ein CDN ausliefern. Standardmäßig. Ist mega schnell. Aber komisch für den Kunden, wenn die Vertragsdokumente nicht auf deiner URL liegen, sondern auf einer Storyblok URL. Sieht ein bisschen aus wie Scam. Lässt sich aber ändern. Gegen Geld.

Und ich könnte die Liste noch ewig weiter machen. Denn alles muss extra gebaut werden:

Eine Website ist kein Showcase. Sie ist ein Arbeitswerkzeug.

Und Arbeitswerkzeuge sollten nicht unnötig kompliziert sein.

Wann Headless wirklich sinnvoll ist

Und bevor jetzt wieder jemand denkt:
„Okay, Headless ist also schlecht.“ oder „Die ist ja sehr eingefahren auf ihrer WordPress-Wiese.“

Nein.

Natürlich gibt es absolut sinnvolle Headless-Szenarien.

Zum Beispiel wenn:

Dann kann Headless richtig stark sein.

Aber das ist halt etwas anderes als: „Wir haben eine Unternehmenswebsite mit Blog und Leistungsseiten.“

Nicht jede Firmenwebsite braucht Silicon-Valley-Architektur. Und nicht jedes Unternehmen kann sich das auch leisten.

Was kostet Headless eigentlich?

Über Kosten wird bei Headless erstaunlich ungern gesprochen 😄

Denn im Pitch klingt erstmal alles: modern, flexibel, skalierbar.

Bis die Rechnungen kommen. Oder die Nachberechnungen. Weil doch mehr Aufwand. Man kennt’s.

Nehmen wir mal Storyblok als Beispiel.

Technisch echt cool. Ich arbeite fast täglich darin.

Aber: Storyblok kostet je nach Setup schnell mehrere hundert Euro im Monat.
Und zwar bevor überhaupt entwickelt wurde.

Dazu kommen oft:

Und plötzlich kostet die „moderne Unternehmenswebsite“ nicht mehr ein bisschen Hosting und Wartung (bei WordPress oft 50-150€ pro Monat), sondern 3-4 stellig im Monat.

Nur für die Infrastruktur.

Hier die Preise von Storyblok von Mai 2026:

Für 349€ im Monat bekomme ich also 15 Benutzer (aber höchstens 20), SEO-Meta-Tags und den Website-Space. Dinge, die bei WordPress kostenlos sind. Wieso muss man sowas überhaupt als Vorteil aufzählen? Das ist selbstverständlich.

Aber der populärste Tarif ist natürlich Custom. Da wird kein Preis auf die Website geschrieben. Denn das spielt keine Rolex.

Und dann kommen noch die Kosten, die beim Pitch und im Angebot nicht auf der Uhr standen:

Das Problem ist nicht Headless selbst.

Das Problem ist: Viele Dinge, die früher Standard waren, werden plötzlich zu Entwicklungsaufgaben. Und Entwicklungsaufgaben kosten Geld.

Lisa’s Senf dazu

Ich glaube, viele Unternehmen kaufen gerade Headless, weil sie Angst haben, technisch „alt“ zu wirken. Und genau das nutzen manche Agenturen brutal gut aus.

Denn am Ende muss eine Unternehmenswebsite nicht Entwickler beeindrucken.

Sie muss:

• gepflegt werden,
• funktionieren,
• gefunden werden
• und langfristig bezahlbar bleiben.

Und ganz ehrlich?

Ich habe inzwischen genug Headless-Projekte gesehen, bei denen aus „maximal flexibel“ ziemlich schnell „maximal abhängig“ wurde.

Nicht weil Headless schlecht ist.

Sondern weil viele Unternehmen sich gerade Komplexität einkaufen, die sie eigentlich nie gebraucht hätten.