Headless ist im Kontext von CMS- und E-Commerce-Systemen ein Architekturkonzept, bei dem Frontend und Backend voneinander entkoppelt sind.
Wenn wir von einem „Headless CMS“ oder einer „Headless-Commerce-Plattform“ sprechen, meinen wir im Grunde ein Backend-System, das Daten über eine API bereitstellt und die Entscheidung über das Frontend dem Entwicklungsteam überlässt.
In einem klassischen System steuert das Backend in der Regel nicht nur Daten, Geschäftslogik und Administration, sondern auch die Art und Weise, wie die Website gerendert wird. In einem Headless-System sagt das Backend: „Hier sind die Daten, hier sind die APIs – jetzt baut die Customer Experience so, wie das Unternehmen sie braucht.“
Das ist eine völlig andere Denkweise als bei klassischen Systemen wie Magento 2 als E-Commerce-Plattform oder WordPress als CMS. Dort ist das Frontend meist eng an das Kernsystem gekoppelt. In den meisten Fällen findet das Rendering serverseitig statt und der Client erhält fertiges HTML.
Selbst wenn wir Performance und Serververbrauch für einen Moment ignorieren, bleibt ein System, in dessen Ökosystem man gezwungen ist zu bleiben.
1. Entwicklungsgeschwindigkeit
Natürlich kann man sagen: „Wenn ich Magento 2 oder WooCommerce installiere, läuft der Shop in 15 Minuten.“
Das stimmt.
Aber niemand bleibt dauerhaft nur bei der Kernfunktionalität.
Jeder reale Shop möchte die eigene Marke abbilden, eine gute User Experience schaffen, individuelle Abläufe hinzufügen, die Conversion optimieren, externe Systeme anbinden, den Checkout verbessern, Landingpages ergänzen, Produktseiten anpassen, Konfiguratoren bauen und vieles mehr.
In einem Headless-System ist die API der Vertrag zwischen Server und Client. Wenn die API bereits die benötigten Daten liefert, muss das Backend nicht verändert werden. Man passt nur den Storefront an, testet ihn und deployt ihn.
Dadurch werden Frontend-Änderungen schneller, sicherer und günstiger.
Man muss nicht gegen ein großes serverseitiges Rendering-System kämpfen, nur um die Customer Experience zu verändern.
2. Robustheit
Da Backend und Storefront voneinander entkoppelt sind, können sie unabhängig voneinander geändert und deployed werden.
Wenn eine Änderung an der API nötig ist, wird sie serverseitig umgesetzt, gebaut und deployed, sobald sie fertig ist. Der Storefront bleibt unverändert. Der Kunde merkt davon nichts.
Sobald der Storefront bereit ist, die neuen API-Endpunkte zu verwenden, wird er separat deployed. Das Backend ist dann bereits vorbereitet.
Das sorgt für einen deutlich sichereren Deployment-Prozess. Änderungen können schrittweise ausgerollt werden, anstatt ein großes riskantes Update für das gesamte System auszuliefern.
Auch das Testen wird einfacher. Backend-Logik kann separat getestet werden. Frontend-Logik kann separat getestet werden. Der API-Vertrag bildet eine klare Grenze zwischen beiden.
3. Flexibilität
Der Storefront wird nahezu plattformunabhängig.
Man kann bauen, was das Unternehmen tatsächlich braucht, anstatt zu fragen, was das alte System überhaupt zulässt.
Extrem schnelle Produktdetailseiten? Dann kann der Storefront mit Astro oder einem anderen performanceorientierten Framework gebaut werden.
Hohe Interaktivität und gute Developer Experience? Dann eignen sich Next.js, Nuxt, Vue oder React.
Eine iOS- oder Android-App, ohne dafür ein komplett separates Backend aufzubauen? React Native oder ein anderes Mobile-Framework kann mit derselben Commerce-API verbunden werden.
Ein spezielles B2B-Portal, Marketplace, landingpage-getriebener Shop oder individueller Checkout-Flow? Man wird nicht vom Theme-System eines Monolithen blockiert.
Genau darin liegt der eigentliche Wert: Das Unternehmen kann sich schneller bewegen, weil die Technologie nicht ständig „nein“ sagt.
4. Performance
In einem klassischen System muss der Server oft bei jeder Anfrage die komplette Seite rendern und zurückgeben. Natürlich hilft Caching, aber die Architektur bleibt von Grund auf schwergewichtig.
In einer Headless-Architektur kann der Storefront über ein CDN ausgeliefert werden. Das Frontend entscheidet, welche Daten es benötigt, und lädt diese über die API.
Das bedeutet in der Regel kleinere Datenmengen, eine schnellere User Experience und geringere Serverlast. Das Commerce-Backend muss nicht jede Seite für jeden Besucher rendern. Es kann sich auf die Geschäftslogik konzentrieren: Produkte, Warenkörbe, Checkout, Bestellungen, Kunden, Zahlungen und Lagerbestand.
Bei hohem Traffic wird der Ressourcenverbrauch dadurch besser beherrschbar und planbarer.
Das bedeutet nicht, dass Performance automatisch entsteht. Auch einen Headless-Shop kann man langsam bauen. Mit der richtigen Architektur ist es aber wesentlich einfacher, das Frontend schnell zu machen und nur die Backend-Bereiche zu skalieren, die es wirklich brauchen.
5. Modularität
Nehmen wir an, im Shop soll auch ein Blog verwaltet werden.
In einem monolithischen E-Commerce-System muss man meist das verwenden, was das System selbst anbietet, oder eine Erweiterung installieren, die versucht, aus einer E-Commerce-Plattform gleichzeitig ein CMS zu machen.
In einem Headless-System ist man darauf nicht beschränkt.
MedusaJS versucht zum Beispiel gar nicht, ein CMS zu sein. Und das ist gut so. Man kann das CMS anbinden, das man bevorzugt: Strapi, Contentful, Directus, Sanity, Storyblok oder sogar WordPress im Headless-Modus.
Der Endkunde sieht weiterhin eine einheitliche Website. Intern übernimmt aber jedes System genau die Aufgabe, für die es gut geeignet ist.
Commerce kümmert sich um Commerce. Das CMS um Inhalte. Die Suche um Suche. E-Mail-Tools um E-Mails. Analytics-Tools um Analytics.
Das ist eine wesentlich gesündere Architektur, als ein großes System zu zwingen, alles gleichzeitig zu erledigen.
6. Skalierbarkeit
Das ist der Teil, den ich persönlich am meisten mag.
Weil das gesamte System modular ist, können wir nur die Teile skalieren, die tatsächlich zum Engpass werden.
Wenn das System gerade erst wächst und nur wenige Bestellungen hat, warum sollte man sofort für teure Server-Infrastruktur bezahlen? Klein anfangen. Die Kosten vernünftig halten.
Sobald das Geschäft wächst, werden genau die Bereiche skaliert, die es brauchen: API, Datenbank, Suche, Cache, Checkout, Queue Worker, Bildauslieferung, CDN oder was auch immer zum realen Engpass wird.
Eine korrekt entwickelte Headless-Architektur hat Skalierbarkeit bereits im Design eingebaut.
Aber Headless ist keine Magie
Es wäre nicht ehrlich, die Nachteile einer Headless-Architektur einfach zu verschweigen.
Sie existieren.
Mit dem richtigen Team sind sie jedoch gut beherrschbar.
1. Mehr architektonische Verantwortung
In einem monolithischen System sind viele Entscheidungen bereits für einen getroffen. Man installiert das System, wählt ein Theme, installiert Plugins und folgt den bestehenden Regeln.
Mit Headless hat das Team mehr Freiheit – und mehr Verantwortung.
Man muss entscheiden, wie der Storefront mit der API kommuniziert, wie Authentifizierung funktioniert, wie Content-Preview umgesetzt wird, wie Caching funktioniert, wie Fehler behandelt werden, wie Deployments organisiert sind und wie verschiedene Services miteinander kommunizieren.
Ohne erfahrene technische Führung kann das schnell chaotisch werden.
Für uns ist das jedoch kein Nachteil, der uns abschreckt. Genau in solchen Aufgaben liefert ein starkes Engineering-Team echten Mehrwert.
2. Mehr bewegliche Teile
Ein Headless-System besteht in der Regel aus mehr Komponenten: Commerce-Backend, Storefront, CMS, Suche, Zahlungsanbieter, E-Mail-Service, Bildservice, Analytics, möglicherweise Queue Worker und Background Jobs.
Mehr Komponenten bedeuten mehr Integrationen und mehr Monitoring.
Die Alternative ist aber oft schlechter: ein riesiges System, das alles gleichzeitig und nichts davon wirklich gut macht.
Unser Ansatz ist einfach: Wenn das System modular ist, muss es auch beobachtbar sein. Logs, Monitoring, Alerts, Deployment-Prozess und Dokumentation sind keine optionalen Extras. Sie sind Teil der Architektur.
3. Das initiale Setup kann länger dauern
Wenn nur ein sehr einfacher Shop mit Standard-Theme und ohne ernsthafte Individualisierung benötigt wird, kann ein klassisches System schneller live gehen.
Headless bringt den größten Nutzen, wenn ein Unternehmen Flexibilität, Performance, individuelle UX, Integrationen oder zukünftige Skalierbarkeit benötigt.
Ja, das initiale Setup kann deshalb länger dauern. Nach unserer Erfahrung zahlt sich diese Investition später aus, wenn der Kunde wachsen und das System verändern möchte, ohne alles von Grund auf neu bauen zu müssen.
Bei Headless geht es nicht darum, die erste Installation schneller zu machen.
Es geht darum, die nächsten fünf Jahre einfacher zu machen.
Unsere Entscheidung
Für Mediabridge ist die Entscheidung bereits gefallen.
Bei jedem neuen Kunden versuchen wir, von Anfang an von einem modernen Stack zu überzeugen.
Bei bestehenden Kunden planen wir den Übergang Schritt für Schritt.
Wir haben weiterhin viele Kunden mit Magento 2, WooCommerce und Shopify. Shopify ist eine eigene Geschichte, über die ich wahrscheinlich in einem der nächsten Blogposts schreiben werde. Wir pflegen diese Systeme weiter, denn wenn etwas funktioniert, sollte man es nicht nur deshalb kaputtmachen, weil die Technologiewelt gerade einen neuen Trend hat.
Unsere Kunden wissen aber bereits: Der Wechsel zu modernen Technologien kommt.
Nicht, weil alte Systeme schlecht sind.
Sie waren für ihre Zeit gut. Sie haben Unternehmen beim Wachstum geholfen. Sie haben uns geholfen, erfolgreiche Projekte aufzubauen. Wir kennen sie sehr gut und respektieren sie weiterhin.
Aber der Markt verändert sich. Die Erwartungen der Kunden verändern sich. KI verändert die Geschwindigkeit, mit der Unternehmen digitale Produkte bauen, testen und verbessern können. Wettbewerber, die sich schneller bewegen können, werden einen Vorteil haben.
Und alte monolithische Systeme machen Bewegung langsamer.
Deshalb ist Headless für uns nicht nur eine technische Modeerscheinung.
Es ist eine Business-Entscheidung.