Headless Commerce mit Shopware 6 und Next.js — wann es sich lohnt

„Headless" begleitet den E-Commerce seit Jahren als Schlagwort. Bei Shopware 6 ist das Setup inzwischen so ausgereift, dass es eine ernsthafte Option ist. Trotzdem passt es nicht zu jedem Shop. Dieser Beitrag ordnet nüchtern ein, wann es sich lohnt und wann nicht.

Was Headless eigentlich heißt

Klassische Shopware-Setups rendern HTML serverseitig (Twig und SCSS, „Storefront"). Bei einem Headless-Setup dient Shopware nur noch als Content- und Logik-Backend. Das Frontend ist eine separate Anwendung, meist Next.js, Nuxt oder SvelteKit, die per Store API mit Shopware kommuniziert.

Daraus ergibt sich eine klare Trennung: Das Backend verantwortet Produkte, Bestellungen, Kunden und Preise, das Frontend UX, Performance und visuelles Erlebnis.

Architektur in der Praxis

Ein typisches Setup sieht so aus:

• Shopware 6 als Headless-Backend, idealerweise auf einer eigenen Domain (z. B. api.shop.de)
• Next.js als Frontend mit App Router, ISR (Incremental Static Regeneration) für Produktseiten
• Store API für Produktabruf, Warenkorb, Checkout, Login
• Webhook-basierte Cache-Invalidierung, wenn Produkte oder Preise sich ändern
• CDN davor (Vercel, Cloudflare) für statische und ISR-Inhalte

Stripe oder PayPal lassen sich direkt im Frontend anbinden. Komplexere Bezahlflows können weiter über Shopware laufen; Hybrid-Setups sind ausdrücklich vorgesehen.

Wann Headless wirklich Sinn macht

• Performance ist kritisch: Bei hochfrequenten Shops, vorwiegend mobilen Käufern oder Märkten mit langsamerer Infrastruktur schlägt eine statisch generierte Frontseite mit ISR jedes klassische Storefront.
• Mehrere Frontends teilen sich ein Backend: Web-Shop, App, Marktplatz-Anbindungen, In-Store-Terminals. Hier zahlt sich die API-First-Architektur unmittelbar aus.
• Komplexe UX-Anforderungen: Konfigurator-Logik, AR-Produkt-Previews oder sehr individuelle Storytelling-Seiten. Was im Storefront-Theme aufwendig wird, ist in React naheliegend.
• Eigenes Design-System ist Pflicht: Wer bereits ein Component-System hat (Storybook, Figma-Tokens), findet in Next.js den natürlichen Partner.

Wann das klassische Storefront besser ist

• Standard-Shops bis etwa 10.000 Bestellungen pro Monat, bei denen das Standard-Theme reicht
• Kleines Team ohne JavaScript-Spezialwissen: Headless verdoppelt den Pflegeaufwand
• Viel Plugin-Logik im Frontend: Plugins, die ins Storefront eingreifen, müssen für Headless oft neu konzipiert werden
• Knappes Budget: Headless verdoppelt den Initial-Aufwand, das muss sich rechnen

Konkrete Zahlen: Was kostet Headless?

Ein Standard-Shopware-Theme kostet als Custom-Entwicklung typischerweise 15.000-40.000 €. Ein Headless-Setup mit Next.js liegt eher bei 35.000-90.000 €, abhängig von Komplexität, Anzahl der Shopkanäle und Integrationen.

Im Betrieb liegt der Mehraufwand bei etwa 20-40 % gegenüber einem klassischen Setup, weil zwei Codebasen gepflegt werden müssen. Im Gegenzug verbessern sich Performance, Time-to-Market neuer Frontend-Features und Skalierbarkeit deutlich.

Einordnung

Headless ist kein Selbstzweck. Es lohnt sich, wenn Performance, Multi-Channel-Strategie oder ein anspruchsvolles UX-Konzept es klar erfordern. Für rund 70 % der KMU-Shops bleibt das klassische Storefront die wirtschaftlichere und wartungsärmere Wahl.

Vor der Entscheidung sollte man die konkreten Anforderungen einmal mit einem erfahrenen Entwickler durchsprechen. Die Antwort fällt häufig anders aus als erwartet, in beide Richtungen.