Wann lohnt sich ein Headless-CMS – und wann nicht?

„Headless“ steht inzwischen auf fast jeder Architektur-Folie. Was dort selten steht: was Sie dafür dauerhaft selbst übernehmen. Dieser Artikel beantwortet die Frage an vier Kriterien, die Sie im eigenen Unternehmen nachzählen können.

Kurz beantwortet: Ein Headless-CMS lohnt sich, wenn drei Bedingungen gleichzeitig zutreffen: Sie spielen dieselben Inhalte über mehrere ernsthafte Ausgabekanäle aus, Ihre Darstellungsanforderungen übersteigen das Vorlagensystem, und Sie haben dauerhaft Entwicklungskapazität für ein eigenes Frontend – intern oder vertraglich gesichert. Fehlt eine davon, ist ein klassisches oder hybrides System in aller Regel die schnellere und günstigere Wahl.

Zwei Begriffe vorab, weil sie in Gesprächen regelmässig durcheinandergeraten. Ein CMS (Content-Management-System) ist die Software, in der Ihre Redaktion Inhalte pflegt; im klassischen Aufbau speichert es den Inhalt und baut daraus die fertige Seite. „Headless“ bedeutet, dass dieser zweite Teil fehlt: Das System verwaltet Inhalte und gibt sie über eine Programmierschnittstelle (API) heraus. Wie daraus eine Seite, eine App oder ein Bildschirm im Ausstellungsraum wird, ist Ihre Sache. Sie kaufen also keine zusätzliche Funktion, Sie geben eine ab – und übernehmen die Verantwortung, sie über Jahre selbst zu betreiben.

Warum klassisch nicht „veraltet“ bedeutet

Die verbreitetste Fehlannahme lautet, ein klassisches System könne Inhalte nicht maschinenlesbar herausgeben. Das war einmal richtig und ist seit Jahren falsch.

Drupal, eines der Systeme, mit denen wir arbeiten, führt JSON:API seit Version 8.7 vom 1. Mai 2019 als stabiles Kernmodul – und bis zur heute aktuellen Version 11 ist es fester Bestandteil des Kerns geblieben. Jede Standard-Installation kann Inhalte über eine saubere Schnittstelle ausliefern und gleichzeitig ihre eigenen Seiten rendern. Wer eine Schnittstelle braucht, um eine App oder ein Händlerportal zu versorgen, muss dafür nichts abtrennen. Der häufigste Denkfehler in dieser Diskussion – „wir brauchen eine Schnittstelle, also brauchen wir Headless“ – ist damit erledigt.

Die vermeintliche Entweder-oder-Frage zerfällt in drei Optionen:

• Klassisch (gekoppelt): ein System, ein Frontend. „Frontend“ ist die Schicht, die Ihre Besucherinnen und Besucher sehen, „Backend“ die Verwaltungsschicht dahinter.
• Hybrid (teilweise entkoppelt): Das CMS liefert die Website weiterhin selbst aus und stellt Inhalte zusätzlich über die Schnittstelle für andere Kanäle oder einzelne, eigens gebaute Bausteine bereit.
• Voll entkoppelt (Headless): Das CMS rendert nichts mehr. Jede Oberfläche ist ein eigenes Entwicklungsprojekt.

Nach unserer Erfahrung aus Schweizer Projekten ist der mittlere Weg der häufigste und in der Diskussion der am schlechtesten vertretene.

Die vier Fragen, an denen die Entscheidung hängt

1. Wie viele Ausspielkanäle bedienen Sie wirklich?

Zählen Sie nur Kanäle, die dieselben Inhalte brauchen und die es heute gibt oder für die ein finanziertes Projekt existiert: Website, App, Onlineshop, Händlerportal, Bildschirm in der Filiale, Print-Katalog aus derselben Quelle.

Unsere Faustregel: Ab dem dritten echten Kanal beginnt sich die Trennung zu rechnen, weil Sie sonst dieselbe Inhaltspflege mehrfach organisieren. Bei einem oder zwei Kanälen zahlen Sie für eine Flexibilität, die Sie nicht abrufen. Ein geplanter Kanal ohne Budget zählt nicht mit – das ist der häufigste Rechenfehler in dieser Zeile.

2. Wie oft ändern sich Ihre Inhalte, und wer ändert sie?

Zählen Sie die Veröffentlichungen der letzten drei Monate und die Zahl der Personen, die dabei tatsächlich im System gearbeitet haben.

Zwei Redakteurinnen und Redakteure mit zwei Änderungen pro Monat merken kaum, wenn eine Vorschau umständlich ist. Zwölf Personen, die wöchentlich Kampagnenseiten bauen, merken es täglich – und aus einer Komforteinbusse wird ein Produktivitätsproblem. Dieses Kriterium wird in Architekturgesprächen am häufigsten unterschlagen, weil am Tisch selten jemand sitzt, der das System später acht Stunden am Tag bedient.

3. Wie viel Darstellungsfreiheit brauchen Sie wirklich?

Nicht, wie viel wünschenswert wäre, sondern: Welche konkrete Anforderung scheitert heute an Ihrem Vorlagensystem?

Können Sie diese Frage nicht mit einem Beispiel beantworten, das seit Monaten liegen bleibt, brauchen Sie die Freiheit nicht. Können Sie drei Beispiele nennen, ist das ein ernstzunehmendes Argument – unabhängig von der Kanalzahl.

4. Wer betreut Ihr Frontend in drei Jahren?

Das ist die entscheidende Frage. Ein selbst gebautes Frontend ist kein Projekt, das endet, sondern ein System, das jemand pflegen muss: Abhängigkeiten aktualisieren, Sicherheitslücken schliessen, Browser-Änderungen nachziehen.

In der Schweiz ist genau diese Kapazität die knappste Ressource. ICT-Berufsbildung Schweiz beziffert den zusätzlichen Bedarf bis 2033 auf 128'600 ICT-Fachkräfte, von denen 54'400 zusätzlich ausgebildet werden müssen. Ein Frontend, für das Sie 2029 niemanden finden, ist kein Fortschritt, sondern ein Betriebsrisiko.

Für ein mittelgrosses Unternehmen ohne eigenes Entwicklungsteam heisst das: Die Frage ist nicht, ob Sie den Aufbau bezahlen können, sondern ob Sie den Betrieb über einen Wartungsvertrag verbindlich absichern. Können Sie das nicht, ist die Antwort bereits gefallen.

Was Sie im Headless-Setup selbst bauen und pflegen

Dieser Teil kommt in Anbietermaterial selten vor. Dries Buytaert, der Gründer des Drupal-Projekts, hielt bereits 2016 fest, der Verlust der mitgelieferten Layout- und Darstellungsverwaltung „kann teuer werden, erhöht Ihre Abhängigkeit von einem Entwicklungsteam und beeinträchtigt die durchgängige Content-Erstellung, die Ihr Marketingteam erwartet“.

Die Aussage ist zehn Jahre alt, und die Entwicklung stand seither nicht still. Drupal Canvas, bis September 2026 unter dem Arbeitstitel „Experience Builder“ geführt und seit dem 8. September 2026 stabil verfügbar, adressiert genau diese Lücke: Inhalte sollen laut Projektbeschreibung „across headless and coupled contexts“ aus einem System verwaltet und Seiten „without relying on developers“ zusammengesetzt werden. Wie tragfähig das produktiv ist, lässt sich von aussen nicht beurteilen. Der Zielkonflikt wird damit kleiner, aufgehoben ist er nicht.

Konkret verlagert sich auf Ihr Entwicklungsbudget:

• Die Vorschau. Sehen, wie ein Beitrag aussieht, bevor er live geht.
• Das Bearbeiten im Kontext. Einen Text dort ändern, wo er steht, statt in einem Formularfeld daneben.
• Die Seitenkomposition. Bausteine anordnen, ohne Entwicklungsressourcen zu binden.
• Mehrsprachigkeit. Der Drupal-Kern bringt dafür vier Module mit. Ein Unternehmen, das Deutsch, Französisch und Englisch ausspielt, verwaltet drei parallel gepflegte Sprachstände inklusive Übersetzungsstatus pro Feld.
• Das Kleingedruckte. Weiterleitungen nach einem Relaunch (einer Neuauflage mit geänderten Adressen), Formulare mit Validierung, die Sitemap als maschinenlesbares Seitenverzeichnis für Suchmaschinen, Suchfunktion, Zugriffsrechte pro Bereich.

Moderne Headless-Systeme haben hier aufgeholt. Storyblok, mit dem wir ebenfalls arbeiten, bietet einen visuellen Editor mit Live-Vorschau. Das ist jedoch keine Funktion, die man einschaltet: Laut offizieller Dokumentation setzt sie eine hinterlegte Vorschau-Adresse, ein eingebundenes Verbindungsskript und entsprechend ausgezeichnete Bausteine im Frontend-Code voraus. Die Vorschau ist also nicht verschwunden, sie ist zu einer Entwicklungsaufgabe geworden. Wird sie beim nächsten Frontend-Umbau nicht mitgezogen, verliert Ihre Redaktion sie.

Der Mittelweg, den viele übersehen

Die tragfähigste Antwort lautet oft: nicht die ganze Website entkoppeln, sondern den einen Baustein, der es braucht.

Ein Beispiel aus unserem Portfolio: Für Stromer haben wir die Website auf Drupal umgesetzt. Der Bike-Konfigurator entstand dagegen als eigenständige Web-Applikation.

Unsere Lesart dieses Zuschnitts: Die redaktionellen Seiten behalten die Bequemlichkeit des klassischen Systems, und die Entwicklungskapazität fliesst dorthin, wo sie einen sichtbaren Unterschied macht. Genau das meint „hybrid“. Wie eine solche Web- und Commerce-Plattform an Ihre bestehenden Systeme andockt, ist am Ende eine Frage der Systemintegration, nicht der CMS-Wahl.

Wann ein Headless-CMS die klar richtige Wahl ist

• Mehrere Marken oder Märkte aus einer Redaktion. Landen dieselben Produktinhalte in fünf Länderauftritten und einer App, sparen Sie ab dem ersten Tag Pflegeaufwand.
• Ein bestehendes Frontend-Team. Betreiben Ihre Entwicklerinnen und Entwickler ohnehin ein Frontend auf Basis von React oder Vue (verbreitete Baukästen für eigens programmierte Oberflächen), ist ein klassisches Vorlagensystem eine Bremse.
• Eine Oberfläche, die keine Website ist. Produktkonfiguratoren, Selbstbedienungsbildschirme, Anzeigen im Fahrzeug, Produktdaten in Marktplätzen.
• Getrennte Release-Zyklen. Wird Ihr Frontend wöchentlich ausgeliefert, das Backend aber quartalsweise, blockieren sich beide bereits heute.

Ein Schweizer Zusatzpunkt, der in Architekturdiskussionen selten vorkommt und in Beschaffungsprozessen regelmässig: Wo liegen die Inhalte? Bei gehosteten Headless-Diensten entscheidet das der Anbieter. Storyblok nennt in seiner offiziellen FAQ Europa, die USA, Kanada und Australien als Hosting-Regionen, wobei die Wahl der Region den Premium- und Elite-Plänen vorbehalten ist. Eine Schweizer Region steht nicht auf dieser Liste. Ob das für Ihre Inhalte zulässig ist, gehört vor die Architekturentscheidung, nicht danach.

Das Entscheidungsraster: acht Fragen

Gehen Sie die Liste durch und zählen Sie die Ja-Antworten.

1. Bedienen Sie heute drei oder mehr Kanäle mit denselben Inhalten?
2. Existiert für jeden dieser Kanäle bereits Budget oder Betrieb, nicht nur eine Absicht?
3. Können Sie drei konkrete Darstellungsanforderungen nennen, die Ihr heutiges Vorlagensystem nicht hergibt?
4. Haben Sie ein Frontend-Entwicklungsteam, intern oder über einen laufenden Wartungsvertrag gesichert?
5. Ist dessen Kapazität auch für 2029 verbindlich zugesagt, nicht nur für die Projektphase?
6. Blockieren sich Frontend und Backend heute durch unterschiedliche Release-Zyklen?
7. Ist Ihre Redaktion bereit, die Vorschau in ihrer heutigen Form aufzugeben oder neu bauen zu lassen?
8. Ist geklärt, in welchem Land Ihre Inhalte künftig liegen dürfen?

Sechs oder mehr Ja: Headless ist eine tragfähige Option. Prüfen Sie sie ernsthaft.

Drei bis fünf Ja: Der hybride Weg passt vermutlich besser. Klären Sie zuerst die Nein-Antworten, bevor Sie über Systeme sprechen.

Zwei oder weniger Ja: Bleiben Sie beim klassischen System. Sie würden Bequemlichkeit gegen eine Freiheit tauschen, die Sie nicht abrufen.

Die Fragen 4 und 5 wiegen dabei schwerer als alle anderen zusammen: Wer dort zögert, kommt mit keiner Systemauswahl weiter.

Fazit

Am Ende steht eine Frontend-Entscheidung, keine CMS-Entscheidung. Sie gewinnen Darstellungsfreiheit und Kanalunabhängigkeit und übernehmen dafür den dauerhaften Bau und Betrieb Ihrer Ausgabeschicht. Das lohnt sich, wenn Sie diese Verantwortung ohnehin tragen oder bewusst tragen wollen.

Prüfen Sie deshalb zuerst die vier Kriterien – Kanalzahl, Änderungsfrequenz und Redaktionsgrösse, konkrete Darstellungsanforderungen, gesicherte Entwicklungskapazität – und erst danach Systeme. Und rechnen Sie den Mittelweg mit: Seit Drupal 8.7 liefern klassische Systeme Inhalte zusätzlich über eine Schnittstelle aus, ohne dass Sie Ihre Ausgabeschicht aufgeben müssen. Für viele mittelgrosse Schweizer Unternehmen ist das die passende Antwort.

Häufige Fragen zum Headless-CMS

Was ist der Unterschied zwischen Headless und hybrid?

Ein voll entkoppeltes System rendert keine Seiten mehr. Ein hybrides System liefert die Website weiterhin selbst aus und stellt Inhalte zusätzlich über eine Schnittstelle für andere Kanäle bereit.

Braucht man ein Headless-CMS, um eine Schnittstelle zu haben?

Nein. Drupal enthält JSON:API seit Version 8.7 vom 1. Mai 2019 als stabiles Kernmodul und kann Inhalte über eine Schnittstelle ausliefern, während es die Website weiterhin selbst rendert.

Ab wie vielen Kanälen lohnt sich Headless?

Nach unserer Faustregel ab dem dritten Kanal, der dieselben Inhalte braucht und für den Budget und Betrieb bereits stehen. Geplante Kanäle ohne Finanzierung zählen nicht mit.

Was verliert die Redaktion bei einem Umstieg auf Headless?

Vor allem Layout- und Darstellungsverwaltung, das Bearbeiten im Kontext sowie Teile der Oberflächen-Lokalisierung. Moderne Headless-Systeme bieten Ersatz an, dieser muss aber im Frontend implementiert und gepflegt werden. Seit September 2026 verfolgt Drupal Canvas den Ansatz, diese Lücke auch für entkoppelte Aufbauten zu schliessen; wie weit das in der Praxis trägt, ist projektabhängig.

Welche Rolle spielt der Fachkräftemangel?

Eine grosse. ICT-Berufsbildung Schweiz beziffert den zusätzlichen Bedarf bis 2033 auf 128'600 ICT-Fachkräfte, davon 54'400 zusätzlich auszubildende. Wer ein eigenes Frontend betreibt, braucht diese Kapazität dauerhaft, nicht nur im Projekt.

Wo liegen die Inhalte bei einem gehosteten Headless-CMS?

Das bestimmt der Anbieter. Storyblok nennt Europa, die USA, Kanada und Australien als Hosting-Regionen, wobei die Wahl der Region den Premium- und Elite-Plänen vorbehalten ist. Klären Sie diesen Punkt vor der Architekturentscheidung.

Steht bei Ihnen eine CMS-Entscheidung an?

Arcmedia begleitet Unternehmen seit 1995 bei Digital-Commerce-Projekten – von der Analyse über die Implementierung bis zum laufenden Betrieb. Unsere Expertinnen und Experten beraten Sie gerne zu Ihrem Vorhaben.

Kontaktieren Sie uns

Immer up-to-date mit den neuesten Trends und Tipps – abonnieren Sie unseren Newsletter.

Quellen

• Drupal.org, „Drupal 8.7.0 is available“, 1. Mai 2019 – belegt das Datum, seit dem JSON:API im Kern steht
• Drupal.org, „JSON:API lands in Drupal core“, Dries Buytaert, 21. März 2019
• Drupal.org, Modul-Dokumentation JSON:API – belegt, dass das Modul bis Drupal 11 Bestandteil des Kerns ist, abgerufen 10. September 2026
• Drupal.org, „How should you decouple Drupal?“, Dries Buytaert, 22. März 2016 – Stand von 2016, im Text ausdrücklich als solcher eingeordnet
• Drupal.org, Projektseite Drupal Canvas (vormals „Experience Builder“), stabile Version 1.11.0 vom 8. September 2026, abgerufen 10. September 2026
• Drupal.org, Multilingual Guide, „Choosing and installing multilingual modules“
• ICT-Berufsbildung Schweiz, Bedarfsprognose 2033, erstellt von BSS Volkswirtschaftliche Beratung AG, 18. September 2025
• Storyblok, offizielle FAQ „Where are your servers (or AWS sites) located?“
• Storyblok, offizielle Dokumentation „Visual Editor“
• Arcmedia, Projektseite Stromer sowie Technologieseiten Drupal und Storyblok