„Headless" steht in keinem Pflichtenheft, weil es ein Geschäftsproblem löst. Es steht drin, weil es auf einer Konferenzfolie gut aussah. Das ist die unbequeme Wahrheit hinter den meisten Composable-Projekten: Die Architektur wird zuerst entschieden, der Grund dafür wird hinterher gesucht.
Dabei ist die Entscheidung, ob du dein Shopware-Frontend von der Storefront entkoppelst, eine der teuersten im ganzen Shop-Lebenszyklus. Sie betrifft nicht nur, wie deine Produktseite gerendert wird. Sie betrifft, wie viele Entwickler du brauchst, wie schnell du Features ausspielst, welche Plugins du noch nutzen kannst und wie dein SEO-Team die nächsten Jahre arbeitet. Diese Entscheidung trifft man nicht, weil ein Ansatz moderner klingt. Man trifft sie, wenn die Rechnung aufgeht. Wann sie aufgeht, ist die eigentliche Frage.
Was „entkoppelt" bei Shopware konkret heißt
Composable Commerce mit Shopware fängt mit einer simplen Gabelung an: Shopware gibt dir nicht einen, sondern zwei offizielle Wege zum Frontend. Das ist der Punkt, an dem die meisten Diskussionen unscharf werden, also machen wir ihn präzise.
Der klassische Weg ist die Storefront, die Shopware mitliefert: serverseitig gerendert, auf Basis von Symfony und der Template-Sprache Twig. Frontend und Backend leben im selben System, im selben Deployment. Du installierst ein Theme, konfigurierst es, und der Shop läuft. Das gesamte Plugin-Ökosystem im Shopware Store ist auf genau diese Storefront ausgelegt.
Der entkoppelte Weg lässt das mitgelieferte Frontend weg. Das Shopware-Backend wird zur reinen Commerce-Maschine und liefert seine Daten über die Store API aus: Produkte, Preise, Warenkorb, Checkout, alles als strukturierte Schnittstelle. Davor setzt du ein eigenes Frontend, das diese Daten abholt und die Seite baut. Shopware stellt dafür ein eigenes Framework bereit, die Shopware Frontends (früher „Composable Frontends", noch früher „Shopware PWA"). Es basiert auf Vue und Nuxt und ist seit 2025 das, was Shopware neuen Headless-Projekten offiziell empfiehlt. Wer mag, baut sein Frontend stattdessen in React, Next.js oder TanStack. Die Store API ist technologieneutral.
„Composable" bei Shopware heißt also nicht „besser". Es heißt „getrennt". Du tauschst ein fertiges, integriertes Frontend gegen ein selbst gebautes, das du voll kontrollierst. Was du dafür bekommst und was es kostet, entscheidet, ob das eine gute Idee ist.
Die drei Gründe, die ein entkoppeltes Frontend rechtfertigen
Es gibt belastbare Gründe für Headless bei Shopware. Sie sind nur seltener gegeben, als die Folien suggerieren. Im Kern sind es drei.
Erstens: Das Frontend ist dein Wettbewerbsvorteil, nicht nur deine Auslage. Stell dir einen Möbel- oder Maschinenbau-Konfigurator vor, der das Produkt live in 3D zusammensetzt, während der Kunde Optionen durchklickt. Genau dort, wo jeder Klick einen Server-Roundtrip durch Twig auslösen würde, würgt die klassische Storefront das Erlebnis ab. Ein entkoppeltes Frontend mit moderner Reaktivität spielt das flüssig. Wenn deine Oberfläche dagegen eine saubere, schnelle, konventionelle Shop-Erfahrung sein soll, kann die Storefront das genauso gut.
Zweitens: Du bespielst mehr als einen Kanal. Der Klassiker ist der Händler mit Filialen: Die Kasse im Laden und der Webshop sollen denselben Lagerbestand und dieselben Preise sehen, in Echtzeit, ohne nächtlichen Abgleich. Sobald dieselben Commerce-Daten nicht nur eine Website, sondern auch eine native App, ein Kassenterminal oder einen externen Marktplatz versorgen, spielt die Entkopplung ihre eigentliche Stärke aus: ein Backend, eine Datenquelle, beliebig viele Frontends über dieselbe API. Hast du nur einen Webshop, zahlst du für diese Flexibilität, ohne sie zu nutzen.
Drittens: Du hast ein eigenes Frontend-Team mit eigenem Takt. Headless trennt nicht nur Technik, sondern auch Verantwortung. Dein Frontend-Team kann deployen, ohne das Commerce-Backend anzufassen, in seinem eigenen Rhythmus, mit seinem eigenen Stack. Das ist ein echter Organisations-Vorteil, aber nur, wenn dieses Team existiert. Genau hier scheitern die meisten Mittelstands-Setups: Sie bauen Headless und haben am Ende einen einzigen Nuxt-Entwickler, der das Frontend allein trägt. Geht der in Urlaub, steht der wichtigste Vertriebskanal still. Die Architektur setzt ein Team voraus, das im Org-Chart noch gar nicht existiert.
Was es kostet, und zwar nicht nur in Euro
Die Entkopplung ist kein einmaliger Aufpreis. Sie ist eine laufende Verpflichtung, und die unterschätzt fast jeder, der nur auf das Projektbudget schaut.
Du betreibst ab jetzt zwei Systeme statt einem: das Shopware-Backend und dein Frontend, jedes mit eigenem Deployment, eigenem Monitoring, eigenem Update-Zyklus. Veröffentlicht Shopware eine neue API-Version oder ändert Datenstrukturen, musst du dein Frontend nachziehen. Das ist beherrschbar, aber es ist Arbeit, die in der monolithischen Storefront schlicht nicht anfällt.
Härter wiegt der Plugin-Bruch. Ein großer Teil dessen, wofür man Shopware schätzt, sind die fertigen Erweiterungen aus dem Store. Viele davon bringen Storefront-Templates mit, die in einem entkoppelten Frontend nichts mehr ausrichten. Ein Beispiel: Das Bewertungs-Plugin, das in der klassischen Storefront fünf Minuten Installation ist, wird im Headless-Setup zum mehrtägigen Reimplementierungs-Ticket, weil seine Anzeige nun einmal an einem Twig-Template hängt, das du nicht nutzt. Backend-Plugins laufen weiter. Alles, was an der Storefront hängt, baust du selbst nach. Was vorher ein Klick im Plugin-Store war, wird zur Frontend-Aufgabe.
Und dann ist da SEO, die Disziplin, in der Headless-Projekte am häufigsten stolpern. Ein entkoppeltes Frontend muss sauberes Server-Side-Rendering liefern. Tut es das nicht, sieht der Googlebot im schlimmsten Fall einen weißen Bildschirm, der seinen Inhalt erst im Browser per JavaScript nachlädt, und deine Rankings brechen weg, ohne dass im Backend irgendetwas „kaputt" aussieht. Die Shopware Frontends lösen das über Nuxt-SSR. Aber „löst es im Prinzip" und „ist im Projekt korrekt konfiguriert" sind zwei verschiedene Dinge. In der Twig-Storefront ist serverseitiges Rendering der Normalzustand. Im Headless-Setup ist es eine Verantwortung, die du aktiv übernimmst.
Wenn man beide Wege nebeneinander legt, sieht die Abwägung so aus:
| Kriterium | Klassische Storefront | Entkoppeltes Frontend (Headless) |
|---|---|---|
| Frontend-Technologie | Symfony / Twig, mitgeliefert | Frei (Vue/Nuxt, React, Next.js) |
| Plugin-Ökosystem | Voll nutzbar | Backend-Plugins ja, Storefront-Plugins selbst bauen |
| SEO / Rendering | SSR ist Normalzustand | SSR muss aktiv gebaut und gepflegt werden |
| Time-to-Feature | Schnell, ein Deployment | Langsamer am Start, dann eigener Takt |
| Update-Pfad | Ein System | Zwei Systeme, zwei Zyklen |
| Team-Bedarf | Shopware-Entwickler | Zusätzlich dediziertes Frontend-Team |
Kurz gesagt: Headless verschiebt Komplexität von Shopware zu dir. Das kann sich lohnen, wenn du diese Komplexität in einen echten Vorteil verwandelst. Es ist verschwendet, wenn du sie nur trägst.
Wann die klassische Storefront die klügere Entscheidung ist
Für einen großen Teil des Mittelstands ist die ehrliche Empfehlung: bei der Storefront bleiben. Nicht aus Bequemlichkeit, sondern weil sie die bessere Rechnung ist.
Die mitgelieferte Storefront ist alles andere als veraltet. Shopware 6.7, erschienen im Mai 2025, läuft auf Symfony 7 und PHP 8.2+; im Admin haben Vue 3 und Vite (statt Webpack) den Entwickler-Stack modernisiert. Die kundenseitige Storefront selbst bleibt bewusst beim bewährten, server-gerenderten Twig-Ansatz. Du bekommst eine schnelle, SEO-freundliche Oberfläche, das volle Plugin-Ökosystem und einen einzigen Update-Pfad, ohne ein Frontend selbst betreiben zu müssen. Für einen klassischen B2C- oder B2B-Shop, dessen Wettbewerbsvorteil im Sortiment, im Service oder im Preis liegt und nicht in einer außergewöhnlichen Frontend-Mechanik, ist das genau richtig dimensioniert.
Die nüchterne Faustregel: Wenn du Headless willst, um „technologisch vorne zu sein", ist es das falsche Projekt. Wenn du es willst, weil ein konkreter Kanal oder eine konkrete Erfahrung anders nicht umsetzbar ist, lohnt sich das Gespräch. Wer noch unsicher ist, was Headless überhaupt grundsätzlich bedeutet, findet die Basics in unserer Definition von Headless Commerce; dieser Artikel hier setzt eine Ebene höher an, bei der konkreten Shopware-Entscheidung.
Die Roadmap-Frage: zukunftssicher ohne Übersteuern
Ein Argument taucht in jeder Headless-Diskussion auf: „Geht Shopware nicht ohnehin Richtung API-first? Dann sind wir mit Headless auf der sicheren Seite." Die Richtung stimmt. Die Schlussfolgerung nicht unbedingt.
Shopware investiert sichtbar in Composable: Die Store API ist ausgereift, die Shopware Frontends werden aktiv weiterentwickelt, und ein künftiges Major-Release könnte die mitgelieferte Storefront stärker zur Referenz-Implementierung machen. Aber das ist Zukunftsmusik mit offenem Zeitplan. Shopware 6.8 wurde auf 2027 verschoben, ein Major-Release 7 ist nicht angekündigt. Wer heute auf Headless setzt, um einer Architektur-Wende zuvorzukommen, optimiert für ein Szenario, das Jahre entfernt und in seiner konkreten Form ungewiss ist. Die bessere Strategie ist, für die Anforderung der nächsten zwei, drei Jahre zu bauen, nicht für eine Roadmap-Spekulation.
Der Entscheidungsrahmen in einem Satz
Entkoppele dein Shopware-Frontend, wenn mindestens einer dieser drei Punkte hart zutrifft: Dein Frontend ist ein echter Differenziator und sprengt die Möglichkeiten von Twig; du bespielst mehrere Kanäle aus derselben Datenquelle; oder du hast ein dediziertes Frontend-Team mit eigenem Release-Takt. Trifft keiner davon zu, ist die klassische Storefront die richtige Entscheidung und kein Kompromiss: schneller live, günstiger im Betrieb, voll im Ökosystem.
Composable Commerce mit Shopware ist ein starkes Werkzeug für die richtige Aufgabe. Der teuerste Fehler ist nicht, sich dagegen zu entscheiden. Es ist, sich dafür zu entscheiden, ohne die Aufgabe zu haben. Die ehrlichste Frage, die du im nächsten Architektur-Meeting stellen kannst, ist deshalb nicht „Können wir Headless?", sondern „Welches konkrete Problem löst es, das die Storefront nicht löst?". Fällt darauf keine klare Antwort, hast du sie schon.
