Headless: Die letzte monolithische Verbindung
Wer ein fertiges Theme kauft, kauft Durchschnitt. Was Headless-Commerce technisch ermöglicht, was Studien belegen – und was die Rechnung wirklich ergibt.
Öffnen Sie zehn Online-Shops aus derselben Branche. Wetten Sie auf zehn unterschiedliche Produktsortimente — und auf dieselbe Storefront. Gleiche Produktkacheln, gleiche Filter-Leiste links, gleicher "In den Warenkorb"-Button rechts unten. Nur das Logo oben links verrät noch, ob Sie gerade Gartengeräte, Industriechemikalien oder Babynahrung kaufen.
Das ist kein Zufall. Es ist das Ergebnis eines Einkaufsprozesses, der beim Template endet.
Markenidentität als Wettbewerbsvorteil — und was Templates davon kosten
Das Problem liegt nicht darin, dass Templates schlecht gebaut sind. Es liegt darin, was passiert, wenn ein Sortiment, das erklärungsbedürftige Produkte verkauft, dieselbe Oberfläche bekommt wie ein Fast-Fashion-Shop: Die Kaufentscheidung verlagert sich auf den Preis.
Wenn Produktbeschreibungen generisch sind, Bilder nach denselben Formatvorgaben skaliert werden und Calls to Action auf denselben Formulierungen basieren, entsteht ein Erlebnis, das funktional ist — aber keinen Grund liefert, dieser Marke gegenüber einer anderen den Vorzug zu geben. Kunden kaufen, aber erinnern sich nicht, wo sie gekauft haben. Repeat-Purchase-Rate, Word of Mouth, Markenbindung — alles leidet darunter. Das Ergebnis ist erhöhter Druck auf bezahlte Akquise: Wer Bestandskunden nicht zurückbringt, muss laufend neu akquirieren. Was wie eine sichere, risikoarme Entscheidung aussieht — "Theme kaufen, fertig" — erzeugt auf mittlere Sicht strukturell höhere Marketingkosten.
Dazu kommt eine technische Dimension: Ein Theme setzt die Grenzen der möglichen User Experience. Ein Spezialhändler für komplexe Industriekomponenten hat andere Navigations-, Filter- und Produktdarstellungsanforderungen als ein Konsumgütershop — aber wenn beide dasselbe Theme kaufen, bekommen beide dieselbe Oberfläche. Die Beratungsleistung, die das Produkt auf der Seite erfordert, bleibt ungebaut.
Was Headless technisch anders macht
Headless Commerce trennt die Präsentationsschicht — was der Kunde sieht — vom Backend mit Produktdaten, Bestelllogik und Kundenverwaltung. Das Backend liefert Daten per API. Das Frontend ist eine eigenständige Anwendung, die mit dieser API kommuniziert: eine Next.js-App, ausgeliefert von globalen CDN-Edge-Knoten.
Was das technisch bedeutet, lässt sich an den Ladezeiten ablesen. Ein Standard-Server führt bei jeder Anfrage Datenbankabfragen aus — bei 500 Millisekunden Serverentfernung eine spürbare Latenz. Ein Headless-Frontend generiert Produkt- und Kategorieseiten zum Build-Zeitpunkt und liefert sie als fertige HTML-Dateien von Edge-Knoten, die typischerweise 50 Millisekunden entfernt sind. 89 Prozent der Teams, die mit Next.js arbeiten, erfüllten Googles Core Web Vitals-Schwellenwerte beim ersten Deployment — verglichen mit 52 Prozent bei anderen Frameworks. Jede 0,1-Sekunde schnellere Ladezeit korreliert mit rund 8 Prozent mehr Conversions.
Jenseits der Geschwindigkeit liegt der entscheidende Vorteil in der Unabhängigkeit der Deployments. Frontend-Änderungen werden live gebracht, ohne das Backend zu berühren. Laut dem Salesforce State of Commerce Report, für den über 4.000 Commerce-Verantwortliche befragt wurden, berichten 77 Prozent der Unternehmen mit Headless-Architektur, dass Storefront-Änderungen, die zuvor Tage oder Wochen dauerten, heute in Stunden umsetzbar sind. Eine neue Kampagnen-Landingpage, ein geänderter Checkout-Flow, ein produktspezifischer Konfigurationsdialog — das sind keine koordinierten Releases mehr. Und weil die Oberfläche keine Theme-Grenzen kennt, können Sortimente die Darstellung bekommen, die ihre Produkte brauchen — nicht die, die das Template erlaubt.
Drei dokumentierte Migrationen, drei Ergebnisse
Die Datenlage für ein Architekturthema ist ungewöhnlich konkret. LARQ, ein Hersteller hochwertiger Wasserflaschen, migrierte zu Headless und verzeichnete innerhalb von drei Monaten eine 80-prozentige Steigerung der Conversion Rate sowie ein 400-prozentiges Umsatzwachstum auf Jahresbasis. Der primäre Hebel war nicht allein die Ladezeit, sondern eine Product Experience, die nicht mehr durch Template-Grenzen eingeschränkt war.
Der Möbelhändler Burrow erzielte nach der Migration 30 Prozent höhere Conversion Rates bei gleichzeitig 50 Prozent schnelleren Ladezeiten. Bezogen auf den Ausgangsumsatz von rund 50 Millionen Dollar entspricht das rund 15 Millionen Dollar zusätzlichem Jahresumsatz — genug, um die Migrationskosten in unter zwölf Monaten zu decken.
Besonders anschaulich ist das Beispiel K2 Sports: Der Outdoor-Ausrüster rollte mit Headless-Architektur acht Marken über 16 Sites in unter neun Monaten aus. In einem monolithischen Theme-Setup hätte dasselbe Vorhaben laut eigenem Bericht 18 bis 24 Monate benötigt — das entspricht der Zeitdifferenz zwischen zwei vollständigen Produktsaisonzyklen im Sporthandel. Die eingesparte Zeit bedeutete konkret: saisonale Nachfrage, die sonst verloren gegangen wäre.
Über Einzelfälle hinaus: Die durchschnittliche Conversion-Rate-Verbesserung über Standard-Headless-Implementierungen liegt laut Branchenauswertungen zwischen 25 und 42 Prozent, Implementierungen mit konsequenter Personalisierung erreichen den oberen Wert.
Die Kostenrechnung — vollständig aufgestellt
Die initiale Investition in ein Headless-Frontend ist höher als in ein Theme. Das ist nicht zu bestreiten. Die relevante Frage ist, was danach passiert.
Die offizielle Shopware-Dokumentation hält fest: Major-Releases, die ungefähr jährlich erscheinen, bringen Breaking Changes mit sich, die Themes und Extensions auf Kompatibilität prüfen und anpassen lassen müssen. Bei deutschen Agenturstundensätzen von 100 bis 180 Euro und realistischen Update-Aufwänden von vier bis acht Stunden pro Zyklus entstehen allein daraus jährlich 400 bis über 1.400 Euro Wartungskosten — ohne dass eine neue Funktion entstanden ist. Wer mehrere Plugins oder tiefere Theme-Anpassungen betreibt, liegt deutlich darüber.
Auf drei Jahre gerechnet, unter Einbeziehung von Funktionsanpassungen, die an Theme-Grenzen stoßen, liegt der TCO-Vorteil von Headless gegenüber monolithischen Architekturen laut aktuellen Marktvergleichen zwischen 20 und 30 Prozent. Der Break-even liegt für die meisten Implementierungen bei 12 bis 18 Monaten, getrieben durch die unmittelbaren Conversion-Gewinne der ersten sechs Monate. Zum Vergleich: Laut einer Befragung von commercetools unter 300 globalen Entscheidern brauchen 68 Prozent der traditionell aufgestellten Shops drei Monate oder länger, um neue Commerce-Funktionen auf den Markt zu bringen. Headless-Teams messen denselben Zyklus in Tagen.
Shopware 6 ist bereits headless-fähig
Ein verbreitetes Missverständnis: Headless erfordert keinen Backend-Wechsel. Shopware 6 liefert eine vollständige Store API seit Version 6.0. Das Backend bleibt unverändert — Produktdaten, Bestelllogik, Zahlungsabwicklung, Versandprozesse alles an seinem Platz. Was ersetzt wird, ist ausschließlich die Präsentationsschicht.
Das reduziert die Migration auf einen klar begrenzten Scope: Frontend entwickeln, auf die Shopware Store API anschließen, deployen. Keine Datenmigration, kein Plattformwechsel, kein Risiko für laufende Bestellprozesse. Gartner hat in seinem Magic Quadrant for Digital Commerce prognostiziert, dass die IT-Betriebskosten durch composable Architekturen auf Dauer halbiert werden — ein Effekt, der nicht an der Unternehmensgröße hängt, sondern an der Frage, wie viel der laufenden Entwicklungskapazität in Wartung des Status quo fließt statt in neue Features.
Zehn Shops, ein Template. Oder zehn Shops, zehn Storefronts — die zeigen, was das jeweilige Sortiment wirklich ist. Der Unterschied liegt nicht im Logo oben links.