Headless-Architektur: Wann lohnt sie sich wirklich

Headless klingt modern, flexibel und performant. Doch nicht jedes Web-Projekt profitiert davon. Dieser Artikel zeigt auf, für welche Anforderungen sich ein Headless-Architekturansatz wirklich eignet und wo er unnötig komplex wird.

Ein Gastbeitrag von Karin Christen, Co-Founder der Agentur, required.

Soll jedes Web-Projekt Headless sein?

Headless, Progressive Web-Apps (PWA) – das sind Buzzwords, die uns als Agentur bestens vertraut sind. Mal tauchen sie im Trendradar auf, mal ganz konkret in Briefings und Feature-Requests potenzieller Kund:innen. Das erinnert fast ein wenig an die Zeit von damals, als plötzlich alle nach «HTML5» fragten – egal, ob man wusste, was das genau war.

In letzter Zeit begegnet uns der Begriff «Headless» immer häufiger, oft als Entscheidungskriterium in Kundenanforderungen.

Wir haben erlebt, dass Projekte an andere Agenturen vergeben wurden, weil dort offensiv mit «Headless CMS» geworben wurde, unabhängig davon, ob der Architekturansatz im konkreten Fall sinnvoll war.

Der Hype ist nicht nur ein Kundenthema. Auch wir als Agentur sind manchmal in Versuchung, ein Projekt «technisch spannend» zu gestalten, obwohl es das gar nicht braucht.

Es macht halt mehr Spass «fancy» Technologien einzusetzen, als ein solides, einfach wartbares klassisches Web-Projekt zu bauen. Aber: Gute Technik ist nicht, was cool ist, sondern was dem Projekt dient.

Das gilt für Agenturen ebenso wie für Freelancer:innen: Wer selbst entscheidet, welche Technologien zum Einsatz kommen, trägt auch die Verantwortung dafür, realistisch zu bleiben.

Solche Situationen machen deutlich, wie wichtig es ist, Kunden fundiert zu beraten. Denn:

Headless ist kein CMS – sondern eine Architekturstrategie.

Jedes moderne CMS mit REST– oder GraphQL-API kann «headless» verwendet werden. Die Frage ist also nicht «Ist das CMS Headless?», sondern «Wann ergibt es überhaupt Sinn, ein Projekt als Headless-Lösung umzusetzen und wann nicht?»

In diesem Artikel zeige ich auf:

• Welche Faktoren bei dieser Entscheidung wirklich zählen
• Wann sich der Headless-Architekturansatz lohnt
• Und warum diese Entscheidung nicht allein von der Kundenseite kommen sollte, sondern durch fundierte Beratung durch Agenturen und Entwickler:innen getragen werden muss

Das alles anhand eines realen Headless Kundenprojektes.

Was bedeutet Headless überhaupt?

Bevor man beurteilen kann, ob Headless «sinnvoll» ist, muss man zuerst verstehen, was damit überhaupt gemeint ist und was oft fälschlicherweise hineininterpretiert wird.

Headless vs. Klassisch

Eine Headless-Architektur trennt das Backend (z. B. CMS, Datenbank, Admin-Interface) vom Frontend (also der Darstellung im Browser oder in einer App). Die Inhalte werden via Schnittstelle (API) ausgeliefert, meistens REST oder GraphQL, und vom Frontend dynamisch dargestellt.

Wichtig: Headless bedeutet nicht automatisch schneller, besser oder moderner – es bedeutet: flexibler, unabhängiger, aber auch: technisch anspruchsvoller.

Benutzt man einen Headless-Ansatz zusammen mit einer Progressive-Web-App (PWA) bedeutet dies einen modularen Aufbau. Sodass einzelne Teile der Applikation unabhängig voneinander entwickelt, gewartet und erweitert werden können, z. B. Log-in, Suchfunktion, Navigation, Inhalt. Das macht die Plattform langfristig besser wartbar und erweiterbar, vor allem, wenn verschiedene Teams oder Partner involviert sind.

Somit ist die App skalierbar, nicht nur für die technische Performance (mehr User, mehr Daten), sondern vor allem: funktionale Skalierung. Also die Fähigkeit, neue Funktionen, Module oder sogar neue Instanzen (z. B. für weitere Mandanten) ohne Redesign oder Architekturumbau zu integrieren.

An einem konkreten Kundenprojekt – dem Berufswahlportal des Kantons Zürich – zeigen wir, wie sich ein Headless-Architekturansatz in der Praxis bewährt hat und wo die Herausforderungen lagen. Die Plattform wurde mit unserem Team als Headless Web-App realisiert und so konzipiert, dass sie kantonsübergreifend eingesetzt werden kann, mit modularen Funktionen, die gemeinsam weiterentwickelt und genutzt werden. Dabei war die Wahl des Headless-Architekturansatzes kein Selbstzweck, sondern eine strategische Entscheidung.

Was uns zur nächsten Frage bringt:

Wann ist Headless sinnvoll und wann nicht?

Headless bringt dann ihre Stärken ins Spiel, wenn bestimmte Rahmenbedingungen erfüllt sind. Sie ist kein Allheilmittel, aber in komplexeren Projekten mit mehreren Zielgruppen, langfristiger Weiterentwicklung und Anforderungen an Flexibilität lohnt sich der Aufwand.

Schauen wir auf das Berufswahlportal des Kantons Zürich, um tiefer ins Detail zu gehen:

berufswahl.zh.ch

Ausgangslage: Von der Mobile-App zur geräteübergreifenden Plattform

Die Anforderung des Kunden war zunächst erstaunlich simpel:

«Können wir unsere bestehende Mobile-App so erweitern, dass Jugendliche und Lehrpersonen im Berufswahlunterricht dieselben Inhalte auch am Desktop nutzen können?»

Im ersten Moment hätte man denken können: Das lässt sich mit ein paar Anpassungen am Frontend (Stichwort: Responsive Design) erledigen. Doch in der Analyse wurde schnell klar: Es ging nicht um eine Website mit responsivem Layout, sondern um eine grundsätzliche Weiterentwicklung der Plattform.

Gemeinsam mit dem Kunden sind wir zentrale Fragen durchgegangen, die letztlich zur Entscheidung für einen Headless-Architekturansatz geführt haben:

Entscheidungskriterien im Projekt

• Offline-Funktion: Gibt es im Klassenzimmer zuverlässiges WLAN? Soll der Unterricht auch dann möglich sein, wenn die Verbindung mal wegbricht? Headless + PWA erlaubt eine gezielte Offline-Erfahrung. Wichtig dabei ist, Offlinefähigkeit ist kein Automatismus. Sie muss gezielt umgesetzt werden, etwa durch den Einsatz von Service Workern, Caching-Strategien und der Auswahl geeigneter Datenstrukturen.
• Lokale Zwischenspeicherung (LocalStorage): Wie lange dauern die Aufgaben im Unterricht? Sollen Fortschritte lokal gespeichert werden, um eine unterbrechungsfreie Nutzung zu garantieren?
• Benachrichtigungen: Wie wichtig sind Push-Notifications im Alltag der Jugendlichen? Welche Rolle spielen Erinnerungen und Hinweise in der Nutzerführung?
• Orientierung & User Experience (UX): Wie schaffen wir Übersicht in einer Plattform mit sehr vielen Inhalten, Funktionen und möglichen Einstiegen, ohne die Jugendlichen zu überfordern?
• Personalisierung: Wie kann die Plattform individuell unterstützen, z. B. mit Fortschritt, eigenen Favoriten oder angeleiteten Aufgaben?

All diese Fragen führten zu einer gemeinsamen Erkenntnis:

Die bestehende Struktur war zu starr. Es brauchte eine flexible, modulare Plattform, die inhaltlich wie technisch weiterwachsen kann und dabei sowohl App-Funktionalität als auch klassische Website-Nutzung erlaubt.

Das entscheidende Argument für die Trennung von Backend und Frontend war jedoch ein anderes:

Die Plattform sollte künftig auch anderen Kantonen zur Verfügung stehen können, mit jeweils eigenem Design, eigenem Auftritt (CI/CD), aber gemeinsam genutzten Funktionen und weiter entwickelbaren Modulen.

Architekturaufbau Berufswahl-Portal

Architekturaufbau Berufswahl-Portal

Eine entkoppelte Architektur schafft genau diese Voraussetzung:

• Die Inhalte und Funktionen können zentral gepflegt und weiterentwickelt werden
• Gleichzeitig kann jede Instanz ihr eigenes Look & Feel und spezifische Anpassungen erhalten
• Neue Kantone können sukzessive andocken, ohne das gesamte System umzubauen

Modularität, Mandantenfähigkeit und technologische Offenheit waren am Ende ausschlaggebend.

Typische Stolperfallen und Herausforderungen bei Headless Web-Projekten

Headless klingt im Pitch oft wie die perfekte Lösung: flexibel, performant, modern. In der Realität bringt dieser Ansatz aber neue Verantwortlichkeiten und Herausforderungen mit sich, sowohl technisch als auch organisatorisch.

Mehr Architektur = mehr Initialaufwand

Bei klassischen CMS-Websites kann man oft auf bestehende Themes, oder in unserem Fall, Custom Boilerplates zurückgreifen. Im Headless-Setup muss alles noch mehr durchdacht und sauber entwickelt werden:

• Wie sind Inhalte strukturiert?
• Wie sprechen Frontend und Backend über die API miteinander?
• Welche Komponenten können wiederverwendet werden?

Das ist anspruchsvoller und kostet in der Konzeptions- und Setup-Phase deutlich mehr Zeit.

In unserem Projekt, dem Berufswahl-Portal, war das genau so: Wir haben länger gebraucht als ursprünglich geschätzt – nicht weil das Projekt schlecht lief, sondern weil das saubere Setup einfach mehr Denkarbeit verlangt und natürlich auch entsprechend etwas Know-how-Aufbau erforderte.

Erfahrene Entwickler:innen sind Pflicht

Headless Web-Projekte verlangen fundierte Kenntnisse in mehreren Bereichen:

• API-Design (REST oder GraphQL)
• JavaScript-Frameworks (React, Vue, etc.)
• Deployment-Prozesse und Hosting
• Content-Modelling und Redaktionsprozesse

Einfach ein CMS installieren und «losklicken» ist hier keine Option. Es braucht ein Team, das Frontend und Backend entkoppelt denken und trotzdem eng verzahnt arbeitet.

Redaktionsfreundlichkeit muss bewusst mitgedacht werden

Ein oft unterschätzter Aspekt ist die Redaktionssicht:

Headless bedeutet, dass das CMS keine direkte Vorschau oder visuelle Kontrolle mehr bietet (da entkoppelt vom Frontend). Redakteur:innen arbeiten in einem abstrahierten Interface – Navigation, Layout oder Verlinkungen sind keine Standard-Funktionen wie in einem klassischen CMS. Das WYSIWYG-Prinzip (What You See Is What You Get) – also direkt sehen, wie eine Seite später aussieht – entfällt meist vollständig.

Gerade für Redakteur:innen ohne technische Kenntnisse ist das ein echter Nachteil. Ohne Zusatzentwicklung können sie Änderungen nicht visuell prüfen oder Inhalte im Kontext sehen.

Das bedeutet konkret:

• Eine enge Zusammenarbeit mit Redaktion & UX ist nötig
• Vorschau-Funktionen müssen oft manuell implementiert werden
• Es braucht mehr redaktionelle Schulung und Support
• Und: Erwartungen müssen frühzeitig geklärt werden, sonst droht Frust nach dem Launch

Maintenance-Aufwand nicht unterschätzen

Im Gegensatz zu einem klassischen CMS, bei welchem man sich mit Core- und Plugin-Updates auseinandersetzt, erfordert eine Headless Web-App zusätzlich auch nach dem Launch erweiterten Aufwand in Pflege und Weiterentwicklung:

• API-Kompatibilität sichern
• Nicht nur Backend-CMS, sondern auch Frontend-Frameworks aktuell halten
• Security, Hosting, Performance aktiv betreuen
• Redaktion unterstützen, wenn sich Anforderungen ändern

Bei uns sind nicht nur die Initialkosten, sondern auch das Maintenance-Budget für Headless-Webprojekte entsprechend höher als bei klassischen Websites, weil die Verantwortung auch technischer ist.

Für welche Projekte lohnt sich Headless und für welche nicht?

Der Architekturansatz entfaltet den Mehrwert nicht in jedem Projekt, sondern dort, wo bestimmte Voraussetzungen erfüllt sind, sei es funktional, organisatorisch oder strategisch.

Hier ein paar Leitfragen und Szenarien, die sich aus unserer Erfahrung bewährt haben:

✅ Headless lohnt sich, wenn …

• Die Plattform mittelfristig wachsen soll
  Neue Funktionen, neue Zielgruppen oder zusätzliche Mandanten (z. B. in unserem Fall, mehrere Kantone) sind absehbar? Dann bringt ein Headless-Ansatz langfristige Flexibilität.
• Frontend-Logik komplex ist oder stark individualisiert werden muss
  Wenn die Darstellung nicht mit einem einfachen Theme gelöst werden kann (z. B. in unserem Fall, interaktive Anwendungen, personalisierte Dashboards, Inhalt und Funktionen über 5 verschiedene Schnittstellen).
• Die Applikation auch als PWA oder auf mehreren Geräten genutzt werden soll
  Mobile Nutzung mit Offline-Funktion, installierbare Web-Apps, Push-Nachrichten: All das lässt sich mit einem API-basierten Frontend gezielt realisieren.
• Mehrere Teams oder Dienstleister an verschiedenen Teilen arbeiten
  Durch die Trennung von Backend und Frontend können Design, Inhalt und Funktion parallel entwickelt und gewartet werden, oft ein entscheidender Effizienzfaktor für grosse Projekte und Teams.
• Der Kunde oder das Produkt eine langfristige Digitalstrategie verfolgt
  Headless zahlt sich nicht sofort aus, aber sehr wohl über mehrere Jahre hinweg, gerade bei Plattformen mit hoher Relevanz und kontinuierlicher Weiterentwicklung.

❌ Headless lohnt sich nicht, wenn …

• Das Projekt ein einmaliger Webauftritt mit wenigen Inhalten ist
  Eine klassische CMS-Website ist schneller realisiert, einfacher zu pflegen und günstiger in der Wartung.
• Der Fokus auf visueller Kontrolle und Redaktionskomfort liegt
  Wenn Kund:innen direkt im Backend Seiten gestalten und Vorschauen sehen wollen, ist ein klassisches CMS oft sinnvoller, zumindest kurzfristig.
• Das Budget oder die Zeit zu knapp ist
  Headless braucht sauberes Konzept, gutes Setup, erfahrene Leute und genau die Zeit, all das gibt ordentlich zu tun. Für Schnellschüsse ist es der falsche Weg.
• Die Redaktionstechnologie bereits gesetzt ist , aber Headless als «Muss» gefordert wird
  Ein Warnsignal: Wenn die technische Strategie von der Kundenseite kommt, ohne dass klar ist, was sie lösen soll.

Unser Fazit

Headless ist dann eine gute Wahl, wenn sie das Projekt technisch und organisatorisch besser tragfähig macht, nicht nur, weil sie als «modern» gelten.

Deshalb ist es umso wichtiger, dass Agenturen und Entwickler:innen hier beratend auftreten und nicht nur Buzzwords erfüllen. Denn nur mit einem klaren Verständnis der Anforderungen und Ziele kann die passende Architekturstrategie entschieden werden.

Wie wir Headless Web-Projekte umsetzen

In Headless Web-Projekten zählt nicht nur die Architektur, sondern auch das Zusammenspiel zwischen User Experience, Redaktion, Entwicklung und Betrieb. Ein gutes Setup vereinfacht langfristig den Alltag für uns als Agentur und für unsere Kund:innen.

Hier ein Einblick, wie wir typischerweise arbeiten:

Unser technisches Setup

Wir setzen auf ein schlankes, bewährtes Setup mit Fokus auf Performance, Wartbarkeit und Erweiterbarkeit:

Backend:

• Ein Headless-fähiges CMS, das Inhalte, Navigation und Userrollen via API bereitstellt (z. B. Strapi oder in unserem Fall WordPress, wichtig ist Offenheit & API-Kompatibilität).

Frontend:

• React + React Router 7 (JavaScript-Bibliothek zum Erstellen von Benutzeroberflächen)
• Vite als Build-Tool
• State-Management je nach Projekt (z. B. Context API)

Deployment & DevOps:

• Lokale Entwicklung mit Docker
• GitHub Actions für automatisiertes Deployment
• Hosting je nach Setup: klassisch beim Kunden oder auf Hosting-Plattformen, wie in unserem Fall als Single Page Application auf cyon.

Redaktion & Content-Management

Ein oft unterschätzter Teil in Headless-Projekten ist der redaktionelle Workflow. Wir achten darauf, dass die Inhalte so strukturiert sind, dass sie für Redakteur:innen verständlich und effizient bearbeitbar sind. Und zwar mit:

• Bearbeitbare Navigation (z. B. Menüs, Seitenstruktur)
• Rollen- und Rechteverwaltung für unterschiedliche Nutzergruppen
• Editor-Vorschau (mit Custom Endpoints) und vereinfachte Admin-Interfaces

Unser Ziel ist immer: maximale Flexibilität im Frontend, ohne dass die Redakteur:innen dabei auf der Strecke bleiben. In unserem Setup hat sich WordPress als Content-Hub bewährt, weil wir damit den Block-Editor anbieten können: ein vertrautes, visuelles Interface, das eine angenehme Content-Writing-Experience ermöglicht. So arbeitet die Redaktion nicht nur mit abstrakten Formularfeldern, wie es bei reinen Headless-CMS wie Strapi & Co. oft der Fall ist, sondern mit einem übersichtlichen Editor, der Nähe zum späteren Layout schafft und die Pflege von Inhalten deutlich erleichtert.

Modularer Code = bessere Wartbarkeit

Wir entwickeln wiederverwendbare Frontend-Komponenten, die wie Bausteine zusammengesetzt werden. Das macht Erweiterungen einfacher, z. B. wenn ein neuer Kanton hinzukommt oder eine Funktion verändert werden soll.

Das bedeutet aber auch: Gute Dokumentation, Versionskontrolle und ein durchdachter Komponentenkatalog (z. B. mit Storybook) sind Pflicht.

Headless ist kein Hype, sondern ein bewusst gewählter Architekturansatz für bestimmte Anforderungen.

Headless Web-Projekte sind nicht automatisch besser, aber sie bieten echte Vorteile, wenn sie strategisch eingesetzt werden. Für uns als Agentur ist es kein allgemeiner Technologiewechsel, sondern nur für geeignete Projekte ein bewusster Schritt:

Mehr Kontrolle über die Architektur, bessere Skalierbarkeit für komplexe Plattformen und ein hoher Qualitätsanspruch im Frontend.

Die Einstiegshürde ist jedoch höher. Die Verantwortung grösser. Die Kund:innen müssen richtig beraten werden und die eigene Infrastruktur sollte so aufgestellt sein, dass sich diese Freiheit auch wirklich ausspielen lässt.

Wir haben die Erfahrung gemacht, dass sich Headless lohnt, wenn man die richtigen Projekte auswählt.

Weiterführende Links

Wenn dich interessiert, wie wir das Berufswahlportal für verschiedene Kantone konkret umgesetzt haben – welche zielgruppenspezifischen Funktionen wir dank des Headless-Ansatzes realisieren konnten und wie wir UX und Personalisierung auf einer modularen Plattform gedacht haben – dann findest du hier den ausführlichen Beitrag auf unserem Agenturblog:

Headless, aber nicht kopflos: zur modularen Web App (required.com)

Oder lehne dich zurück und schau dir den Talk «How to Keep Your Head While Going Headless with WordPress» an, den ich im Juni 2025 an der European WordPress Conference gehalten habe.

Deine Meinung?

Hast du ähnliche Erfahrungen gemacht? Oder stehst du gerade vor einem Headless-Projekt? Ich freue mich über Austausch und Diskussion, gerne hier in den Kommentaren

Titelbild: A.C. / Unsplash