„Wenn der Underdog plötzlich Marktführer wird… ." Glaubt man dem Werbesprech, dann hat Headless CMS diesen Moment erreicht. Anbieternahe Erhebungen sprechen inzwischen von rund drei Vierteln der Unternehmen mit einem Headless-Setup (die Zahlen liest man mit der üblichen Vorsicht, die werden von Firmen lanciert, die Headless verkaufen). Dazu die verdächtig glatt klingenden Marketing-Zahlen, auf die alle schielen: "50 Prozent schnellere Ladezeiten, 30 Prozent weniger Bounce auf Mobilgeräten, 20 Prozent mehr Conversion, obendrauf unbegrenzte Skalierbarkeit und volle Flexibilität". Aber zumindest ist Headless raus aus der Frühphase und im Pro-Business-Umfeld (und nur da) so langsam die neue Normalität.
Was sich wirklich verschoben hat, ist nicht (nur) der Marktanteil, sondern wer damit arbeiten kann. Headless war jahrelang die Spielwiese der Entwickler – und die Hölle für jede Redaktion, die statt eines Layouts ein nacktes JSON-Schema vorgesetzt bekam. Genau das ist gekippt. Storyblok, Strapi und Contentful haben im letzten Jahr massiv in die Editorial-UX investiert: visuelle Editoren mit Live-Preview, komponentenbasierte Content-Blöcke, kollaborative Workflows. Die Redaktion korrigiert Texte jetzt direkt im Layout, nicht mehr im Datenmodell.
Bei so viel Headless-Euphorie vergisst man leicht, dass unser Web nach wie vor CMS-getrieben ist. WordPress bleibt mit 43 Prozent Marktanteil so souverän auf Kurs, dass die ganze Entkopplungs-Debatte daneben fast albern wirkt. Aber auch hier gibts Entwicklung: Die gereifte REST-API hat ein eigenes Ökosystem hervorgebracht, „Headless WordPress" – vertrautes Backend, ein Next.js-Frontend davor, verheiratet über Frameworks wie Faust.js. "Das Beste aus zwei Welten" – oder der komplizierteste Stack von allen? Man betreibt damit nicht mehr ein System, sondern zwei – das alte PHP-Backend und das JavaScript-Frontend davor. Wer sich das antut, sollte einen echten Grund haben (keinen Trend).
Damit steht die eigentliche Frage im Raum: Braucht man das überhaupt? Reines Headless – komplett entkoppelte Frontends, die nur noch über APIs sprechen – braucht es in ganz wenigen Pro-Edge-Cases (wenn wirklich mehrere Ausspielkanäle bedient werden). Denn jeder dieser Punkte zahlt nur ein, wenn man ihn braucht. In allen anderen Fällen ist reines Headless eine weltfremde und benutzerunfreundliche Komplexitätsfalle.
Und genau das verschweigen die Trend-Artikel gern: den Preis im Betrieb: Headless heißt zwei Systeme statt einem, zwei Administrationen, zwei Deploy-Wege, zwei Angriffsflächen, zwei Dinge, die synchron bleiben müssen. Nüchtern betrachtet ist Headless kein Wundermittel. Aber für die entsprechenden Anwendungsfälle und sauber implementiert ist es eine Architekturentscheidung, die sich langfristig auszahlt.
Genau da setzt an, was 2026 alle „Hybrid CMS" nennen. Klassisches Page-Rendering bleibt, API-Endpunkte stehen parallel bereit für App, Smart-Speaker, Digital Signage (und jedes weitere IoT-Buzzword). Für die klassische Website-plus-vielleicht-App-Kundschaft ist das eine vernünftige Wahl – gewohntes Rendering, API nur da, wo sie gebraucht wird.
Und für die einzelne Website mit Redaktion ist „ein Inhalt, viele Kanäle" schlicht wertlos, „freie Frontend-Wahl" bezahlt man mit einem zweiten System, und die verlockende Performance bekäme man mit gutem Caching auch aus dem CMS. Hier ist und bleibt das klassische CMS die beste Lösung.
