Headless Commerce mit Next.js.
Wann es lohnt — und wie.

1. Wann Headless wirklich lohnt

Vorab und ehrlich: Headless lohnt sich für die meisten Shopware-Shops nicht. Ein gut sanierter klassischer Twig-Storefront ist wirtschaftlicher, schneller live und einfacher zu warten. Headless verdoppelt die Codebase und damit die Wartungslast — das muss durch Wirkung gedeckt sein, sonst zahlt man laufend für eine Komplexität, die nichts bringt.

Headless lohnt sich konkret, wenn mindestens zwei dieser drei Bedingungen erfüllt sind:

1. Sie wollen ein eigenes Markenerlebnis mit komplexer UI, das das Standard-Theme nicht hergibt — z.B. produkt-konfigurator-getriebene Storefronts, Marken-Storytelling über mehrere Seiten, oder integrative Erlebnisse mit Video/3D.
2. Performance Mobile ist Geschäfts-KPI und Sie haben einen starken Mobile-Traffic-Anteil (>60 %). Headless mit Next.js 15 bringt typische Lighthouse-Mobile-Werte von 88–95, klassische Storefronts kommen sauber konfiguriert auf 75–88.
3. Storefront-Team will unabhängig vom Shop-Backend deployen. Bei Headless können Frontend-Releases jederzeit live gehen, ohne Shopware-Updates oder Backend-Deployments. Das ist bei großen Teams ein operativer Hebel.

2. Architektur-Optionen

Drei Hauptpatterns, in der Praxis. Jedes hat eigene Trade-offs.

Für die meisten Mittelstand-Shops ist Option A die wirtschaftlichste — sie liefert die Mobile-Performance-Gewinne und Brand-Wirkung, ohne den Checkout-Komplexitäts-Berg zu kaufen.

3. Tech-Stack: Next.js 15 + Shopware 6

Empfohlener Stack für 2026, in Mandaten erprobt:

• Next.js 15 App Router mit React Server Components — Default für alle Listings, Produktdetails und statische Seiten
• Server Actions für Cart-Mutations und Checkout-Schritte — vermeidet eigene API-Routes für Trivialfälle
• TypeScript strict mit generierten Types aus der Shopware-API (via openapi-typescript)
• Tailwind CSS für Design-System mit Tokens, optional shadcn/ui als Komponenten-Basis
• Vercel oder Cloudflare Pages als Hosting — automatisches CDN, ISR-Support, Edge-Funktionen für Geo-Logik
• Shopware 6.5+ als Headless-Backend mit Store-API und Sync-API

Was ich bewusst nicht nutze: GraphQL als BFF-Pattern (overkill für Standard-Shops), Redux/Zustand für globalen State (Server-State über Server-Actions reicht), Microservices-Architektur (außer bei wirklich großen Teams).

4. Datenfluss: Catalog, Cart, Checkout

Die drei Daten-Achsen, die ein Headless-Shopware-Shop bedienen muss, jeweils mit dem üblichen Pattern:

Catalog (Produkte, Kategorien, Filter)

Read-heavy, cache-freundlich. Über die Store API geladen, mit ISR cached (60–300 s revalidate). Bei Preis- oder Bestands-Änderungen On-Demand-Revalidation per Webhook aus Shopware. Bei Listings > 50.000 Produkten Elasticsearch als zusätzliche Schicht für Suche und Filter.

Cart (Warenkorb)

Write-heavy, user-spezifisch, nicht cache-fähig. Cart wird in Shopware als Session-State gehalten (Context-Token via Cookie). Server Actions in Next.js spielen Mutations gegen die Store API. Client-seitige UI updated optimistisch, syncht mit Server-Response. Bei Bugs wird der echte Server-State als Source of Truth genutzt.

Checkout

Hier ist die strategische Entscheidung am wichtigsten. Bei Hybrid-Architektur (Option A oben) übergibt Next.js den Cart per Context-Token an die Shopware-Storefront und überlässt ihr den finalen Checkout — inklusive aller Validierungen, Zahlungsanbindung und DSGVO-Texte. Bei Voll-Headless wird der komplette Checkout in Next.js gebaut, das ist aufwendig, weil Sie Zahlungs-Provider-Integrationen, AGB-Texte, Bestellbestätigung und Edge-Cases (Adress-Validierung, Lieferzonen) selbst orchestrieren.

5. Performance-Patterns

Headless ist nicht automatisch schneller — falsch gebaut ist es genauso langsam wie ein schlecht konfiguriertes klassisches Theme. Was wirklich performante Headless-Shopware-Shops auszeichnet:

• Server Components für alles Daten-Loading — Catalog-Daten landen direkt im HTML, Client bekommt fertig gerenderten Code
• Suspense + Streaming für Above-the-Fold-Priority: kritische Inhalte zuerst, weniger kritische nachträumend
• ISR mit revalidate auf Kategorie- und Produktdetail-Pages — meist 60–300 Sekunden
• next/image für alle Produktbilder mit responsiven srcsets und AVIF-Auslieferung
• Edge Caching für statische Inhalte über Vercel oder Cloudflare — kein Origin-Hit für Returning Visitors

In einem dokumentierten Mandat wurde durch Headless-Refactor die Lighthouse Performance Mobile von 44 auf 92 gehoben, Mobile-Conversion stieg von 1,1 % auf 2,4 %. Details: /werk/performance-headless-textil/.

6. CMS und redaktioneller Content

Shopware bringt redaktionelle Inhalte über sein eigenes CMS (Shopping Experiences) mit. Bei Headless wird das in der Praxis selten genutzt — entweder weil das eigene Redaktions-Team mehr Freiheit braucht oder weil das Erlebnis zu sehr Shop-getrieben aussieht. Drei übliche Alternativen:

• Payload CMS selbst gehostet — open-source, TypeScript-first, sehr gut für deutsche Datenschutz-Anforderungen weil DSGVO-konform on-premise betreibbar
• Sanity als SaaS — schöne Editor-UI, sehr flexibles Schema, aber US-Hosting (DSGVO-AVV nötig)
• Shopware CMS via Store API — wenn Sie ein Shop-natives Erlebnis wollen und das Team mit Shopware-Editor zurechtkommt

Persönliche Präferenz für Mandate aus dem deutschsprachigen Raum: Payload CMS, weil es sich selbst hosten lässt und die Editor-Experience für Redakteure besser ist als das Shopware-CMS.

7. SEO bei Headless

SEO ist bei Headless-Migrationen der häufigste Stolperstein. Wer es falsch macht, verliert Rankings — manchmal massiv. Die kritischen Punkte:

• Server-Side-Rendered HTML — alle Inhalte müssen ohne JavaScript-Ausführung im Source-View sichtbar sein. Mit Next.js Server Components ist das der Default.
• generateMetadata() pro Page für korrekte title/description/canonical/OG-Tags. Bei Produktseiten dynamisch aus dem Catalog generiert.
• JSON-LD strukturierte Daten inline gerendert — Product, Offer, BreadcrumbList, Organization. Nie clientseitig nachladen.
• sitemap.xml dynamisch aus dem Shopware-Catalog gebaut, mit korrekten lastmod-Daten und Image-Entries.
• 301-Redirects für alle alten URLs in next.config.ts oder Edge-Middleware. Bei Migrationen kritisch — sonst verlieren Sie alte Backlinks.
• hreflang für mehrsprachige Shops per generateMetadata() pro Sprach-Slug.

Bonus: KI-Suche und Antwort-Optimierung für KI-Modelle funktionieren bei sauber gebauten Headless-Shops oft besser als bei klassischen, weil die HTML-Struktur sauberer ist und strukturierte Daten konsequenter eingesetzt werden.

8. Migrations-Reihenfolge

Eine Headless-Migration ist nichts, was man am Wochenende durchzieht. Aus Erfahrung die wirtschaftlichste Reihenfolge:

1. Audit + Architektur-Entscheidung (5 Werktage, 990 €). Welche Option (A/B/C)? Welche Bereiche zuerst? Verbindliches Angebot für die Implementierung.
2. Tech-Spike auf einer Page (2–3 Wochen). Produktdetail-Page in Next.js bauen, an Shopware anbinden, Daten-Mapping validieren, Performance messen. Bei Hybrid-Pattern: Cart-Pre-Step gleich mit.
3. Catalog-Migration (4–6 Wochen). Alle Catalog-Pages in Next.js: Kategorien, Produktdetails, Suche, Filter. Inklusive ISR-Setup und Bild-Pipeline.
4. Brand-Content + redaktionelle Pages (2–4 Wochen). CMS-Setup, redaktionelle Pages, Brand-Landing-Pages.
5. SEO-Sicherheits-Pass (1–2 Wochen). Metadata, JSON-LD, sitemap.xml, 301-Redirects. Crawl-Vergleich vorher/nachher.
6. Soft-Launch (1 Woche). 10 % Traffic über DNS-Split, Monitoring, Bugs raus.
7. Full-Launch mit Rollback-Plan, alte Storefront bleibt 4 Wochen warm für Notfälle.

Gesamtdauer für einen mittelgroßen Shopware-Shop mit Hybrid-Pattern: 12–20 Wochen, 25.000–50.000 € Festpreis. Vollständig Voll-Headless mit Custom-Checkout: 20–30 Wochen, 40.000–80.000 €.

9. Häufige Fragen