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

„Headless" ist seit Jahren ein Buzzword im E-Commerce. Bei Shopware 6 ist das Setup so ausgereift, dass es als ernsthafte Option dasteht. Aber: Headless ist nicht für jeden Shop die richtige Wahl. Ein nüchterner Blick — wann es Sinn macht und wann nicht.

Was Headless eigentlich heißt

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

Sie bekommen damit eine klare Trennung: Backend kümmert sich um Produkte, Bestellungen, Kunden, Preise. Frontend kümmert sich um 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 werden direkt im Frontend angebunden. Komplexere Bezahlflows können weiter über Shopware laufen — Hybrid-Setups sind explizit erlaubt.

Wann Headless wirklich Sinn macht

• Performance ist kritisch: Hochfrequente Shops, mobile Käufer, Märkte mit langsamerer Infrastruktur — eine statisch generierte Frontseite mit ISR schlägt jedes klassische Storefront.
• Mehrere Frontends teilen sich ein Backend: Web-Shop, App, Marktplatz-Anbindungen, In-Store-Terminals. Hier zahlt sich die API-First-Architektur direkt aus.
• Komplexe UX-Anforderungen: Konfigurator-Logik, AR-Produkt-Previews, sehr individuelle Storytelling-Seiten. Was im Storefront-Theme aufwendig wird, ist in React natürlich.
• Eigenes Design-System ist Pflicht: Wenn Sie bereits ein Component-System (Storybook, Figma-Tokens) haben, ist Next.js der natürliche Partner.

Wann das klassische Storefront besser ist

• Standard-Shops bis ~10k Bestellungen/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 gedacht 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. Dafür sind Performance, Time-to-Market neuer Frontend-Features und die Skalierbarkeit deutlich besser.

Mein Rat

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

Bevor Sie sich entscheiden: einmal mit einem erfahrenen Entwickler über die konkreten Anforderungen sprechen. Die Antwort fällt häufig anders aus, als erwartet — in beide Richtungen.