Der Kopf bleibt dran.

VonThomas Körting

Neulich kam die Frage, die gerade viele stellen: „Sag mal, was sind eigentlich diese Headless CMS – und ist das was für mich?“

Kurz erklärt: Ein Headless CMS trennt, was ein klassisches WordPress zusammenhält. Das CMS wird zur reinen Datenbank mit Redaktionsoberfläche und gibt seine Inhalte nur noch über eine Schnittstelle heraus. Wie die Seite aussieht, entscheidet ein separat gebautes Frontend – meist React, Next.js oder Astro. Der „Kopf“ wird vom Körper abgeschnitten. Daher der Name. Klingt modern, entkoppelt, zukunftssicher – und rollt gerade durch jede Tech-Timeline.

Ich habe die ehrliche Antwort für mich gesucht, nicht die Hype-Antwort. Und weil meine Seite in 0,13 Sekunden ausliefert, war sie am Ende einfacher, als der Trend vermuten lässt.

Wo Headless wirklich glänzt

Fangen wir fair an. Es gibt Fälle, in denen Headless echte Arbeit spart.

Intercom meldet nach der Umstellung auf Contentful 13-fach schnellere Deployments und eine 5-fach schnellere Markteinführung. APT Travel Group nennt +175 % Online-Umsatz. Eine Storyblok-Umfrage zählt 99 % zufriedene Umsteiger. Beeindruckend – bis man den Kontext liest, den die Landingpages weglassen: Das sind Konzerne mit eigenen Entwicklerteams und vielen Ausspielkanälen, Web, App, Newsletter, In-Product. Für sie ist ein zentrales Content-Backend, das jeden Kanal gleichzeitig bespielt, ein echter Hebel. Die Storyblok-Zahlen stammen zudem aus einer Umfrage von Storyblok unter Headless-Nutzern. Man fragt Leute, die sich für Headless entschieden haben, ob es gut war – die Antwort überrascht niemanden.

Und das ist keine halbe Anerkennung. Für ein Unternehmen, das seine Inhalte gleichzeitig über fünf Kanäle ausspielt, ist Headless nicht Mode, sondern die einzig vernünftige Architektur. Sogar Automattic, die Firma hinter WordPress, schreibt in den eigenen Leitfaden: Headless lohnt bei echtem Multi-Channel, mehreren Frontends und großen Teams. Ohne diese Fälle sei eine gut optimierte klassische Seite „schneller live, günstiger im Betrieb und leichter zu warten“.

Damit ist die eigentliche Frage gestellt. Sie lautet nie „Headless – ja oder nein?“, sondern: Auf welcher Seite der Linie stehst du? Der Rest dieses Textes beantwortet sie für meinen Fall.

Der Performance-Mythos

Das Verkaufsargument Nummer eins heißt: schneller. Eine Agentur dokumentiert eine WordPress-zu-Headless-Migration mit 50 % kürzeren Ladezeiten – bis man die Ausgangslage liest: PageSpeed 35 mobil, Core Web Vitals durchgängig rot. Das war keine Website, das war ein Pflegefall. Wer eine ungetunte, plugin-überladene Installation gegen ein frisches Next.js stellt, gewinnt natürlich. Das beweist nicht Headless, sondern nur, dass vorher niemand optimiert hat.

Meine Seite liegt bei 0,13 Sekunden. Ein ehrlicher Vergleich – aus einem Pro-Headless-Artikel – nennt für ein gecachtes WordPress-Theme 180 bis 250 Millisekunden, für Next.js mit ISR 50 bis 120. Ja, Next.js könnte meine 130 theoretisch auf 60 oder 80 drücken. Nur spürt diesen Unterschied kein Mensch, der eine Seite liest. Ladezeit wird jenseits einer halben Sekunde zum Problem, nicht ein paar Dutzend Millisekunden darunter. Und es kann kippen: Derselbe Artikel gibt zu, dass Headless durch aufgeblähte React-Bundles langsamer werden kann als vorher. Allein das Next.js-Grundgerüst liefert je nach Setup gut 200 KB JavaScript aus – meine Datenstücke haben null. Man kann sich mit Headless schneller machen. Man kann sich genauso gut langsamer machen und dabei ein Vielfaches an Komplexität einkaufen.

Was der Trend verschweigt: die Rechnung

Headless klingt nach „moderner“, nicht nach „teurer“. Ist es aber oft. CrafterCMS – kein WordPress-Fanclub – schlüsselt die versteckten Posten auf: separates Frontend-Hosting (20 bis über 2.000 Dollar im Monat), eigene Such-Infrastruktur, Neubau der Vorschau. Und der teuerste Posten steht in keiner Rechnung: Jedes Formular, jedes Template, jede Layout-Änderung braucht jetzt einen Entwickler. Die Redaktion, die vorher selbst eine Seite baute, ist plötzlich abhängig.

Genau da liegt der wunde Punkt, den ausgerechnet WordPress VIP offen benennt: das Preview-Problem. Der Redakteur kann nicht mehr einfach auf „Vorschau“ klicken – diese Funktion muss custom gebaut werden, oder sie fehlt. Dazu zwei Codebasen statt einer und das komplette Plugin-Ökosystem weg: kein Yoast für die SEO, kein Plugin für den Cookie-Consent. Alles, was es fertig gibt, wird zum Eigenbau. WPBeginner, die größte Community-Seite der WordPress-Welt, fasst es unfein zusammen: Die überwiegende Mehrheit der Blogger, Kleinunternehmen und Shops braucht kein Headless.

„Aber KI ändert doch alles“

Der berechtigte Einwand, den ich mir selbst gestellt habe: Das stärkste Argument gegen Headless war immer die Entwickler-Abhängigkeit. Aber ich baue meine Datenstücke mit einer KI, ohne eine Zeile React zu schreiben. Fällt das Argument damit nicht?

Teilweise ja – die Hürde „du brauchst ein React-Team“ ist so niedrig wie nie. Nur senkt KI die Kosten auf beiden Seiten: Dasselbe Werkzeug pflegt ein getuntes WordPress genauso leicht, aus einer Codebasis statt aus zweien. Der Abstand bleibt, er rutscht nur nach unten. Und von den anderen Posten berührt KI keinen: Das zweite Hosting kostet weiter, Contentful wird trotzdem verkauft, Gatsby ist trotzdem tot, und die selbstgebauten Ersatzteile für Yoast und Consent muss jemand am Leben halten, wenn das nächste Update das Schema ändert. Mehr generierter Code heißt mehr, das synchron bleiben muss, nicht weniger.

KI macht Headless machbarer, nicht sinnvoller. Sie senkt den Preis der Antwort, ohne die Frage zu beantworten – und meine lautet weiter: wozu? Das Warum schlägt das Was, auch hier.

Das beste Gegenargument: Sicherheit

Der stärkste Einwand, den ich gegen mich selbst fand. WordPress ist das meistangegriffene CMS der Welt – wegen seiner Verbreitung und der Plugin-Flut. Ein statisches Frontend hat kein öffentliches wp-admin, kein PHP, keine Plugin-Lücke zum Durchprobieren. Die Angriffsfläche schrumpft auf nahezu null. Das ist real, auch für kleine Seiten.

Zwei Dinge relativieren es für meinen Fall. Erstens verlagert Headless die Angriffsfläche, es eliminiert sie nicht: Das WordPress-Backend läuft weiter, erreichbar für die Schnittstelle, nur nicht mehr öffentlich verlinkt – und Sicherheit, die bloß darauf beruht, dass der Angreifer die Tür nicht sieht, ist die schwächste. Zweitens der Preis: Eine gehärtete Installation mit Wordfence, Auto-Updates und einem Cache, der ohnehin statisches HTML ausliefert, hält das Restrisiko klein – für einen Bruchteil dessen, was zwei Codebasen kosten. Ich zahle nicht die doppelte Infrastruktur, um ein Risiko auf null zu drücken, das schon nahe null liegt.

Wem gehört dein CMS in drei Jahren?

Die Marktdaten widersprechen dem Hype direkt. WordPress läuft 2026 auf rund 41,9 % aller Websites, knapp 59 % der Seiten mit erkennbarem CMS (W3Techs). Kein Headless-Anbieter taucht darin mit auch nur einem Prozent auf. Fairerweise ist das ein schiefer Vergleich – Contentful zielt auf Enterprise, 4.800 Markenkunden statt Millionen Hobby-Blogs, und eine Domain-Zählung, die jede Bäckerei mitwiegt, lässt es kleiner wirken, als es wirtschaftlich ist. Der Punkt hält trotzdem: Headless ist eine bewusst kleine, hochpreisige Nische, die lauter klingt, als sie groß ist. Und sie wächst nicht mal verlässlich – im „State of Enterprise WordPress“-Report ist der Anteil der Unternehmen, die WordPress headless betreiben, binnen eines Jahres von 28 % auf 16 % gefallen.

In der Nische wird gerade konsolidiert. Am 1. Juni 2026 hat Salesforce die Übernahme von Contentful unterschrieben, dem größten unabhängigen Anbieter – kolportierter Preis 1 bis 1,5 Milliarden Dollar, ein deutlicher Abschlag gegenüber der 3-Milliarden-Bewertung von 2021. Der Marktführer verschwindet als eigenständige Firma und wandert in Salesforce Customer 360. Wer ihn nutzt und kein Salesforce-Großkunde ist, darf sich fragen, wohin Roadmap und Preise ziehen. Kein Einzelfall: Gatsby, jahrelang das Aushängeschild des JAMstack, ist seit Ende 2024 im „limited maintenance mode“, Gatsby Cloud abgeschaltet. Wer darauf gebaut hatte, musste erneut migrieren.

Bei Software, die ich in jedem Editor öffnen kann, stellt sich die Frage nicht. Und WordPress? Dessen Governance ist auch kein Ponyhof – Matt Mullenwegs Machtfülle und der Streit mit WP Engine 2024 haben gezeigt, dass hinter dem freien Projekt handfeste Einzelinteressen stehen. Der Unterschied bleibt fundamental: Der Core ist quelloffen, läuft auf meinem Server, und keine Übernahme kann ihn abschalten oder über Nacht verteuern. Ein VC-finanziertes SaaS gehört seinen Investoren – bis es jemand kauft. Meine Installation gehört mir.

Der Kronzeuge heißt Gatsby

Die schönste Pointe liefert Gatsby selbst – und diesmal geht es um etwas anderes. Das JAMstack-Flaggschiff hat für den eigenen Blog WordPress als Redaktions-Backend zurückgeholt. Vorher lief er über Markdown und Git: einen Tippfehler korrigieren hieß Seite lokal bauen, formatieren, Pull Request, Tests – für einen Buchstaben konnten Stunden draufgehen, und Nicht-Entwickler kamen mit der Kommandozeile nicht klar. Also kam die WordPress-Oberfläche zurück.

Die Lektion ist nicht „Headless ist schlecht“, sondern subtiler: Die Redaktions-Erfahrung bricht zuerst. Wer den entwicklerfreundlichsten Stack der Welt baut, baut oft den redaktionsfeindlichsten. Und irgendwann fragt jemand, der nur schreiben will, warum ein Absatz ein Deployment auslösen muss.

Warum ich trotzdem längst headless denke

Und jetzt die Wendung, die mich selbst nicht aus der Schusslinie nimmt: Ich lebe schon headless, nur dort, wo es sich rechnet. Meine Datenstücke sind statische, handgebaute HTML-Seiten außerhalb von WordPress – genau das Ergebnis, das ein Headless-Stack produziert: ein entkoppeltes Frontend, schnell und niemandem gehörend. Nur ohne Build-Pipeline, ohne zweites Hosting, ohne Framework-Wette. Eine HTML-Datei reicht, habe ich dazu mal geschrieben. Und wo ich Inhalte maschinell brauche, gehe ich über dieselbe REST-Schnittstelle, die jedes Headless-Setup nutzt. WordPress kann headless – es zwingt mich nur nicht dazu. Ich nehme das Muster, wo es nützt, und lasse die Religion weg.

Das ist der Punkt. Headless ist kein Fehler, sondern die Antwort auf eine Frage, die ich nicht habe. Ich habe keine App, kein zweites Frontend, keine Redaktion mit zwanzig Leuten, keinen Kanal außer dieser Seite. Ich habe einen Cache, der die Performance-Frage längst beantwortet hat, und eine Oberfläche, in der ich einfach schreiben kann. Ich stehe schlicht auf der anderen Seite der Linie – und ich weiß, auf welcher. Das ist der ganze Trick.

Der Trend sagt: Trenn den Kopf ab. Meine Zahlen sagen: Wozu? Der Körper ist gesund, der Kopf denkt schnell genug, und beide zusammen kosten weniger als ihre Trennung.

Der Kopf bleibt dran. Zumindest bei mir und meinem Mini-Blog. Sollte ich irgendwann in die Verlegenheit kommen zu expandieren, sodass sich die Frage neu stellt – unvorstellbar, aber ich wollte es mal erwähnt haben –, dann denke ich nochmal darüber nach. Oder ich habe Langeweile, dann natürlich auch. Schauen wir mal, was zuerst eintritt.

Quellen

Ähnliche Beiträge