Headless, Composable oder klassisches CMS?

Jetzt beraten lassen!

Kaum eine Diskussion wird in Digitalprojekten so ideologisch geführt wie die um die CMS-Architektur. Headless galt lange als Synonym für Modernität, klassische Systeme als Auslaufmodell - und Composable als das nächste große Ding. 2026 zeigt sich in vielen Projekten ein nüchterneres Bild: Die Architekturfrage ist keine Glaubensfrage, sondern eine Anforderungsfrage. Wer sie falsch beantwortet, zahlt in beide Richtungen - entweder mit einer Plattform, die beim ersten neuen Kanal an ihre Grenzen stößt, oder mit einer Architektur, deren Komplexität niemand im Unternehmen braucht.

Dieser Beitrag ist bewusst kein Plädoyer für ein Modell. Er liefert die Kriterien, mit denen IT-Leiter, CTOs und Digital-Verantwortliche die Entscheidung für ihre Enterprise-Website fundiert treffen können - unabhängig davon, ob am Ende Umbraco, Sitecore, Storyblok oder eine hybride Lösung steht.

Inhaltsverzeichnis

• TLDR
• Drei Architekturmodelle im Überblick
• Warum sich die Architekturfrage 2026 anders stellt
• Wann Headless und Composable echte Vorteile bringen
• Wann Headless Overkill ist
• Sechs Kriterien für die Entscheidung
• Hybrid: der pragmatische Weg für viele Enterprise‑Websites
• Wie Cyber‑Solutions Unternehmen bei der Architekturentscheidung unterstützt
• Fazit: Architektur folgt Anforderungen, nicht Trends

TLDR

• Die Wahl zwischen klassischem, Headless‑ und Composable‑Ansatz ist 2026 keine Technologie‑, sondern eine Anforderungsfrage – und keine Frage von „modern oder veraltet".
• Headless und Composable lohnen sich vor allem bei mehreren Ausspielkanälen, mehreren Frontends und einer tiefen Integrationslandschaft (PIM, DAM, ERP, CRM).
• Für eine einzelne Website mit kleinem Redaktionsteam ist Headless häufig Overkill: höhere Betriebskomplexität, mehr Infrastruktur, spürbare Reibung im Redaktionsalltag.
• Moderne Plattformen wie Umbraco, Sitecore XM Cloud, Xperience by Kentico oder Storyblok sind hybridfähig – gekoppelt starten und headless ausspielen, wo es Nutzen bringt, ist ein realistischer Weg.
• Sechs Kriterien tragen die Entscheidung: Kanäle, Redaktionsrealität, Team und Betrieb, Integrationen, TCO über den Lebenszyklus, Migrationsfähigkeit.

Drei Architekturmodelle im Überblick

Beim klassischen, gekoppelten CMS liegen Content‑Verwaltung und Auslieferung in einem System: Das CMS rendert die Website selbst, Redakteurinnen und Redakteure arbeiten mit direkter Vorschau und veröffentlichen ohne Umwege. Ein System, ein Deployment, ein Betriebsmodell – das ist die große Stärke dieses Ansatzes und der Grund, warum er für viele Unternehmenswebsites nach wie vor gut funktioniert.

Headless trennt diese Ebenen: Das CMS verwaltet Inhalte und stellt sie über APIs bereit, das Frontend – etwa eine React‑ oder Next.js‑Anwendung – wird separat entwickelt, deployt und betrieben. Inhalte lassen sich damit an beliebig viele Kanäle ausliefern: Website, App, Self‑Service‑Portal, Digital Signage oder auch KI‑gestützte Assistenten.

Composable geht noch einen Schritt weiter. Statt einer Plattform, die alles kann, werden spezialisierte Bausteine – CMS, PIM, DAM, Search, Commerce – über APIs zu einer Gesamtarchitektur orchestriert. Das Prinzip dahinter ist als MACH‑Architektur (Microservices, API‑first, Cloud‑native, Headless) bekannt geworden und verspricht maximale Flexibilität bei der Auswahl der besten Einzelkomponenten.

Wichtig für 2026: Die Grenzen zwischen diesen Modellen verschwimmen. Umbraco liefert Inhalte über die Content Delivery API headless aus, ohne das gekoppelte Rendering aufzugeben. Sitecore positioniert XM Cloud als hybride Plattform. Storyblok ist API‑first konzipiert, bietet Redaktionen mit dem Visual Editor aber ein Arbeitsgefühl, das man sonst nur von gekoppelten Systemen kennt. Die Architekturentscheidung ist damit keine Produktentscheidung mehr – fast jede relevante Plattform kann mehrere Modelle bedienen.

Warum sich die Architekturfrage 2026 anders stellt

Vor einigen Jahren wurde die Headless‑Frage oft als Richtungsentscheidung zwischen Zukunft und Vergangenheit inszeniert. Diese Phase ist vorbei. In vielen Organisationen ist inzwischen praktische Erfahrung mit entkoppelten Architekturen vorhanden – und damit auch ein realistischeres Bild der Kosten: eigene Frontend‑Codebasis, eigene Build‑ und Deployment‑Pipelines, Preview‑Infrastruktur, zusätzliche Abstimmung zwischen Teams. Der Hype ist einer Konsolidierung gewichen, in der Unternehmen genauer hinschauen, welcher Zuschnitt zu ihren Anforderungen passt.

Gleichzeitig sind neue Anforderungen dazugekommen, die für strukturierte, API‑fähige Inhalte sprechen: KI‑gestützte Workflows im Content‑Bereich, die Ausspielung von Inhalten an Assistenzsysteme und die wachsende Zahl digitaler Touchpoints machen es attraktiv, Content als sauber modellierte Daten zu behandeln statt als Seiten. Entscheidend ist dabei aber weniger das Rendering‑Modell als die Qualität des Content‑Modells – präsentationsunabhängig strukturierte Inhalte lassen sich auch aus einem gekoppelt betriebenen CMS über APIs bereitstellen.

Die Architekturfrage 2026 lautet deshalb nicht mehr „Headless: ja oder nein?", sondern: Welche Kanäle bedienen wir heute und realistisch in drei Jahren, wer arbeitet täglich mit dem System, und welche Systeme in unserer Landschaft müssen Inhalte konsumieren?

Wann Headless und Composable echte Vorteile bringen

Entkoppelte Architekturen spielen ihre Stärken dort aus, wo Inhalte tatsächlich mehr als einen Abnehmer haben. Wer neben der Website eine App, ein Kundenportal, Messe‑Displays oder mehrere Länder‑ und Markenauftritte aus einem gemeinsamen Content‑Hub bespielt, profitiert unmittelbar von der API‑first‑Bereitstellung: Inhalte werden einmal gepflegt und mehrfach verwendet, ohne Copy‑and‑paste zwischen Systemen.

Auch die Organisation des Entwicklungsteams ist ein valides Argument. Wenn Frontend‑ und Backend‑Teams getrennt arbeiten, unterschiedliche Release‑Zyklen haben oder mehrere Dienstleister parallel liefern, reduziert die Entkopplung Abhängigkeiten: Das Frontend kann unabhängig deployt werden, Technologieentscheidungen im Frontend sind nicht an das CMS gebunden, und einzelne Teile der Plattform lassen sich austauschen, ohne das Gesamtsystem anzufassen.

Der dritte typische Treiber ist die Integrationslandschaft. In Unternehmen, in denen Produktdaten aus dem PIM, Assets aus dem DAM und Transaktionsdaten aus dem ERP in digitale Erlebnisse einfließen, ist eine composable gedachte Architektur oft ohnehin die realistische Beschreibung des Ist‑Zustands. Hier schafft ein API‑orientiertes Setup Ordnung: klare Verantwortlichkeiten pro System, definierte Schnittstellen und die Möglichkeit, einzelne Bausteine weiterzuentwickeln, ohne einen Big Bang zu riskieren. In Summe übersetzen sich diese Vorteile in kürzere Time‑to‑Market bei parallelen Arbeitsströmen, bessere Wiederverwendbarkeit und eine Architektur, die mit neuen Kanälen mitwächst.

Wann Headless Overkill ist

Die Gegenrechnung wird seltener aufgemacht – und genau hier entstehen viele teure Fehlentscheidungen. Wer eine einzelne Unternehmenswebsite mit einem überschaubaren Redaktionsteam betreibt, kauft sich mit Headless eine zweite Systemwelt ein: ein separates Frontend mit eigenem Hosting, eigenen Builds und eigenem Monitoring, dazu häufig eine Preview‑Lösung, die das nachbildet, was gekoppelte Systeme von Haus aus können. Jede dieser Schichten will betrieben, abgesichert und gewartet werden – über den gesamten Lebenszyklus der Plattform.

Spürbar wird das vor allem im Redaktionsalltag. Marketing‑Teams, die Landingpages eigenständig bauen, Inhalte visuell anordnen und vor der Freigabe verlässlich sehen wollen, wie eine Seite aussieht, stoßen in schlecht zugeschnittenen Headless‑Setups schnell auf Reibung: Für Layout‑Änderungen braucht es Entwickler‑Tickets, die Vorschau ist unvollständig, und die versprochene Freiheit landet ausschließlich beim Entwicklungsteam. In vielen Projekten zeigt sich, dass genau diese redaktionelle Autonomie über die Zufriedenheit mit der Plattform entscheidet – nicht die Eleganz der Architektur.

Auch wirtschaftlich verschiebt sich das Bild. Die Total Cost of Ownership einer entkoppelten Lösung umfasst neben Lizenz‑ oder Subscription‑Kosten die initiale Frontend‑Entwicklung, den laufenden Betrieb zweier Systeme und den Koordinationsaufwand zwischen mehr Beteiligten. Steht dem kein Mehrkanal‑Nutzen gegenüber, finanziert das Unternehmen Komplexität ohne Gegenwert.

Sechs Kriterien für die Entscheidung

asdfasdf

• Kanäle und Ausspielung: Welche Touchpoints bedienen Sie heute – und welche sind in den nächsten drei Jahren realistisch geplant? Eine Roadmap mit App, Portal oder mehreren Marken spricht für Entkopplung; eine einzelne Website nicht.
• Redaktionsrealität: Wer pflegt Inhalte, wie häufig, mit welcher Autonomie? Je stärker Marketing eigenständig gestalten soll, desto wichtiger sind visuelles Editing und verlässliche Vorschau – nativ oder als bewusst eingeplanter Baustein.
• Team und Betrieb: Gibt es interne Frontend‑Kompetenz und DevOps‑Reife für den Betrieb zusätzlicher Systeme? Eine entkoppelte Architektur ohne das passende Betriebsmodell wird schnell zur Dauerbaustelle.
• Integrationslandschaft: Wie viele Systeme liefern Inhalte zu oder konsumieren sie – PIM, DAM, ERP, CRM, Suche? Je mehr Beteiligte, desto wertvoller sind klare API‑Schnittstellen.
• TCO über den Lebenszyklus: Rechnen Sie Lizenzen, Implementierung, Betrieb und Weiterentwicklung über mehrere Jahre – nicht nur das Implementierungsbudget. Zwei Systemwelten kosten dauerhaft mehr als eine.
• Migrationsfähigkeit: Kann die Architektur mitwachsen, wenn sich Anforderungen ändern? Ein sauberes, präsentationsunabhängiges Content‑Modell ist hier die beste Versicherung – unabhängig vom gewählten Modell.

Wer diese sechs Fragen ehrlich beantwortet, hat die Architekturentscheidung meist schon getroffen – und kann sie intern nachvollziehbar begründen.

Hybrid: der pragmatische Weg für viele Enterprise‑Websites

Zwischen „alles gekoppelt" und „alles entkoppelt" liegt der Weg, den viele Enterprise‑Projekte 2026 tatsächlich gehen: hybride Architekturen. Die Corporate Website wird klassisch gerendert – mit voller redaktioneller Autonomie, Vorschau und schnellen Publishing‑Workflows –, während dieselben Inhalte über eine Delivery API zusätzlich an App, Portal oder Partner‑Systeme ausgeliefert werden. Plattformen wie Umbraco oder Xperience by Kentico unterstützen genau dieses Muster, ohne dass sich das Unternehmen am ersten Tag festlegen muss.

Der strategische Vorteil liegt im Investitionsschutz: Die Architektur folgt dem tatsächlichen Bedarf statt einer Zukunftswette. Kommt ein neuer Kanal dazu, ist die API‑Grundlage vorhanden; bleibt es bei der Website, wurde keine unnötige Komplexität aufgebaut. Voraussetzung ist ein Content‑Modell, das von Beginn an strukturiert und präsentationsunabhängig gedacht ist – hier entscheidet sich, ob die Plattform später flexibel bleibt oder nicht.

Hybrid ist damit keine Kompromisslösung, sondern für viele Unternehmen die architektonisch ehrlichste Antwort: so viel Entkopplung wie nötig, so wenig Betriebskomplexität wie möglich.

Wie Cyber‑Solutions Unternehmen bei der Architekturentscheidung unterstützt

Als Implementierungspartner für Umbraco (Platinum Partner), Sitecore (Silver Partner), Storyblok (Certified Partner) und Kentico (Bronze Partner) haben wir kein Interesse daran, ein bestimmtes Architekturmodell zu verkaufen – wir setzen alle um. Genau das macht eine neutrale Bewertung möglich: In Architektur‑Workshops analysieren wir gemeinsam mit IT und Marketing die sechs Entscheidungskriterien, bewerten realistische Zielbilder inklusive TCO‑Betrachtung und sprechen eine begründete Empfehlung aus – ob gekoppelt, headless, composable oder hybrid.

Mit über 15 Jahren Erfahrung in Enterprise‑Webprojekten auf .NET‑ und Azure‑Basis sowie Integrationen von ERP‑, PIM‑ und DAM‑Systemen begleiten wir die Entscheidung bis in die Umsetzung – und sorgen dafür, dass das Content‑Modell von Anfang an so aufgebaut ist, dass die Architektur später mitwachsen kann.

Fazit: Architektur folgt Anforderungen, nicht Trends

Weder ist Headless per se modern, noch ist ein klassisches CMS per se veraltet. Die tragfähige Entscheidung entsteht aus einer ehrlichen Analyse von Kanälen, Redaktionsrealität, Team, Integrationen und Kosten – und aus einer Plattformwahl, die hybride Wege offenhält. Wer Architektur als Anforderungsfrage behandelt statt als Glaubensfrage, baut 2026 Plattformen, die im Alltag funktionieren und trotzdem zukunftsfähig bleiben.

Sie stehen vor einer Relaunch‑ oder Architekturentscheidung für Ihre Enterprise‑Website?

Jetzt beraten lassen