Praxis & Entscheidungen · Shopware Hub

Headless und Composable Commerce – was steckt dahinter?

Auch: Headless Shop · API-first · Composable Commerce

Kurzantwort

Headless trennt das Frontend vom Shopsystem: Shopware liefert Daten und Logik per API, die Oberfläche baut ein eigenständiges Frontend – Composable treibt das Prinzip weiter und setzt den ganzen Stack aus spezialisierten Diensten zusammen. Shopware 6 ist dafür gebaut (API-first) und bietet mit dem offiziellen Frontend-Baukasten einen gangbaren Headless-Pfad. Die ehrliche Einordnung: Für die große Mehrheit der Shops ist die mitgelieferte Storefront die bessere Wahl – Headless kauft Freiheit gegen deutlich mehr Verantwortung, Budget und SEO-Sorgfalt.

Was man gewinnt, was man übernimmt – und die ehrlichen Einsatzfälle

Der Gewinn ist reale Freiheit: Ein entkoppeltes Frontend (typisch auf Basis moderner JavaScript-Frameworks, im Shopware-Umfeld etwa über das offizielle, Vue-basierte Frontend-Toolkit) kann Nutzererlebnisse bauen, die ein Template-System nicht hergibt, mehrere Ausspielkanäle aus einer Logik bedienen – Web, App, Kiosk, Konfiguratoren – und Teams entkoppeln: Frontend-Entwickler arbeiten ohne PHP-Berührung, Releases beider Welten laufen unabhängig. Composable erweitert den Gedanken auf den Gesamtstack: Suche, Content, Payment, PIM als austauschbare Spezialdienste, verklebt über APIs – maximale Wahlfreiheit für Organisationen, die je Baustein das Beste wollen. Die Übernahme-Seite ist die unbequeme Hälfte: Alles, was die Storefront gratis mitliefert, wird zur Eigenleistung – Rendering samt Caching, Barrierefreiheit, das komplette SEO-Kapitel (serverseitiges Rendering ist Pflicht, sonst sieht Google eine leere Hülle; Canonicals, hreflang und strukturierte Daten baut man selbst nach, was die Storefront längst kann), dazu doppelte Infrastruktur und ein Team, das zwei Welten pflegt. Faustregel aus der Projektpraxis: Headless verdoppelt bis verdreifacht Initial- und Pflegeaufwand gegenüber der Storefront – Geld, das erst einmal durch messbar bessere Erlebnisse zurückverdient werden will. Die ehrlichen Einsatzfälle sind deshalb klar umrissen: Mehrkanal-Strategien mit App oder Touchpoints jenseits des Browsers, außergewöhnliche Frontend-Anforderungen (Konfiguratoren, Erlebnis-Commerce), große Organisationen mit getrennten Teams – und Content-Commerce-Hybride, die ihr Frontend ohnehin im Content-System denken. Für alle anderen gilt die unglamouröse Wahrheit: Die Shopware-Storefront ist schnell, SEO-fertig, erweiterbar und wird vom Hersteller mitgepflegt – „Headless, weil modern“ ist ein Architekturmotiv, kein Geschäftsgrund; die Editionen-Frage kennt das Muster: gekauft wird, was konkrete Arbeit oder konkretes Erlebnis ersetzt.

Kurz-Fakten

Begriffe: Headless = Frontend entkoppelt, Daten per API · Composable = ganzer Stack aus Spezialdiensten komponiert.
Shopware-Basis: API-first-Architektur ab Werk – offizielles Vue-basiertes Frontend-Toolkit als Headless-Pfad.
Gewinne: freie Nutzererlebnisse, Mehrkanal aus einer Logik, entkoppelte Teams und Releases.
Übernahmen: SSR/SEO, Caching, Barrierefreiheit, doppelte Infrastruktur – Faustregel 2–3× Aufwand vs. Storefront.
SEO-Warnung: ohne serverseitiges Rendering und nachgebaute Canonicals/hreflang/Schema wird Headless zum Sichtbarkeits-Risiko.
Ehrliche Einsatzfälle: App/Mehrkanal, Sonder-Frontends, Großorganisationen, Content-Commerce – sonst: Storefront.

Einordnung

Headless ist die Architektur-Antwort auf eine Frage, die man erst stellen sollte, wenn das Geschäft sie aufwirft: Wer Kanäle, Teams oder Erlebnisse hat, die eine Storefront sprengt, findet in Shopwares API-first-Fundament den richtigen Unterbau. Alle anderen kaufen mit dem Buzzword vor allem Verantwortung – und die mitgelieferte Storefront bleibt der leise Beweis, dass „integriert“ kein Schimpfwort ist.

Headless und Composable Commerce – was steckt dahinter?

Was man gewinnt, was man übernimmt – und die ehrlichen Einsatzfälle

Kurz-Fakten

Einordnung

Verwandte Fragen