Shopware Headless 2026: Die Frontend-Entscheidung hinter dem Buzzword

"Shopware headless" taucht in Ausschreibungen und Agentur-Angeboten auf, als wäre es ein Schalter: an oder aus. In der Praxis ist es keine einzelne Entscheidung, sondern eine Reihe kleinerer. Welche API spricht dein Frontend, was passiert mit der Twig-Storefront, welche Shopware-Funktionen bleiben server-seitig, und welche musst du selbst neu bauen? Dieser Beitrag klärt genau das, bevor du irgendein Frontend-Projekt startest.

Was "Shopware headless" technisch bedeutet

Shopware 6 liefert zwei relevante Schnittstellen aus: die Store-API (REST/JSON) für Produktdaten, Preise, Warenkorb und Checkout, und die Admin-API für Konfiguration, Custom Fields und Backend-Objekte. Headless heißt: dein Frontend spricht mit diesen APIs, statt dass Shopware die Seite über Twig-Templates und das Storefront-Theme selbst rendert.

Das ist der eigentliche Kern der Query. Nicht "haben wir eine App gebaut", sondern: wer rendert die Seite, und über welche Schnittstelle bezieht dieses Rendering seine Daten? Solange die Antwort "Twig-Theme im selben Prozess wie Shopware" lautet, ist der Shop nicht headless, egal wie modern das Theme aussieht.

Was mit der Twig-Storefront passiert

Die Standard-Storefront (Bootstrap-Theme, Twig-Templating, Theme-Inheritance-System) bleibt bei Shopware installiert, unabhängig davon, ob du headless gehst. Die Frage ist, welche Rolle sie danach noch spielt:

• Weg | Was bleibt bei Shopware | Was du neu baust
• Teil-Decoupling | Twig-Storefront läuft weiter für Rechtsseiten, Checkout-Restfälle oder wenig besuchte Bereiche | Nur die konversionsrelevanten Seitentypen (PDP, PLP, Kategorie, Startseite) werden über die Store-API neu gerendert
• Vollständiges Decoupling | Nur noch Backend-Funktionen (Produktverwaltung, Preislogik, Bestellabwicklung) | Die komplette Storefront, inklusive Checkout-UI, läuft gegen die Store-API
• Shopware-eigener PWA-Stack | Backend unverändert | Vue-Storefront-/Alokai-basierter PWA-Layer, offizielle Empfehlung, aber mit begrenzter Adoption im DACH-Bestand

Der dritte Weg ist wichtig zu kennen, weil Shopware ihn selbst empfiehlt. In der Praxis bleibt die Adoption niedrig, weil der PWA-Stack ein eigenes Projekt mit eigenem Frontend-Team voraussetzt, nicht anders als ein komplett selbst gebauter Headless-Layer.

Was du aufgibst, was du behältst

Behältst du in jedem Fall: Produktkatalog, Preisbücher, Kundengruppen-Logik, Flow Builder für Automatisierungen, und die Checkout-Kernlogik (Zahlungs- und Versandintegrationen laufen weiter über Shopware-Prozesse, auch wenn die Checkout-Oberfläche im entkoppelten Frontend liegt).

Musst du neu bauen oder ersetzen: Jedes Theme-Plugin, das direkt ins Twig-Template rendert. Bei einem typischen Shopware-Shop mit 20 bis 50 Plugins ist das der größte unterschätzte Aufwand, denn nicht jedes Plugin hat ein API-Äquivalent. Auch SEO-Snippet-Anpassungen, die bisher im Theme gepflegt wurden, wandern in die Frontend-Schicht.

Wann Headless auf Shopware die falsche Entscheidung ist

Kein Beitrag über Headless ist ehrlich, wenn er nicht auch sagt, wann es sich nicht lohnt.

• Standard-Sortiment, Twig-Theme performant genug. Wenn dein Mobile-LCP bereits unter der 2,5-Sekunden-Marke liegt und dein Team keine Marketing-Geschwindigkeit vermisst, ist ein Decoupling-Projekt reiner Aufwand ohne messbaren Gewinn.
• Kein Frontend-Team, kein Budget für einen Managed-Layer. Ein selbst betriebener Headless-Stack ohne dediziertes Frontend-Team führt regelmäßig zu genau dem Vue-Storefront-Szenario, das Shopware-Teams am häufigsten aufgeben: aufgesetzt, halb gepflegt, irgendwann technische Schuld.
• Starke Plugin-Abhängigkeit im Storefront-Bereich. Wenn ein Großteil deiner 20 bis 50 Plugins direkt ins Theme eingreift, multipliziert sich der Migrationsaufwand mit jedem Plugin ohne API-Pendant.
• Parallel läuft bereits eine Shopware-5-zu-6-Migration. Zwei große Frontend-Baustellen gleichzeitig sind selten die richtige Reihenfolge. Details zur Entkopplungs-Strategie für diesen Fall stehen im Beitrag Shopware-6-Upgrade-Pfad und Frontend-Strategie.

Wenn keiner dieser Punkte zutrifft, aber Multi-Brand-Skalierung, BFSG-Konformität oder Marketing-Geschwindigkeit zum echten Engpass werden, ist Headless der richtige nächste Schritt, nur eben bewusst gewählt statt aus Buzzword-Druck.

Entscheidungsraster

Vier Fragen, die vor der Architektur-Entscheidung beantwortet sein sollten:

1. Welche Seitentypen sollen entkoppelt werden, alle oder nur die konversionskritischen?
2. Bleibt der Checkout in Shopware oder wandert die UI ins neue Frontend?
3. Wie viele deiner Storefront-Plugins haben ein Store-API-Äquivalent, und wie viele nicht?
4. Betreibst du das Frontend selbst, oder brauchst du einen Managed-Layer?

Details zur Storefront-Modernisierung im Allgemeinen, unabhängig von der Backend-Frage, stehen im Beitrag Shopware-Storefront und Frontend-Modernisierung, und die Frage Agentur vs. Managed-Plattform ist im Beitrag Shopware-Agentur oder FMP separat behandelt.

Wo Laioutr reinpasst

Laioutr setzt sich direkt auf die Shopware Store-API und übernimmt das Rendering vollständig, ohne dass du Produktkatalog, Preislogik oder Bestellabwicklung anfassen musst. Damit entspricht das dem vollständigen Decoupling-Pfad, aber ohne dass du einen eigenen PWA-Stack aufbauen und betreiben musst. Als Agentic Frontend Management Platform liegt Layout, Kampagnen-Aufbau und A/B-Testing im Editor, nicht im Entwickler-Backlog. Für Shopware-Kunden mit mehreren Marken oder Ländern zahlt sich das besonders aus, Multi-Brand-Setups laufen über eine Codebasis statt über n Theme-Forks. Wer den technischen Connector im Detail sehen will, findet ihn im Beitrag Shopware-Laioutr-Connector als Open Source.

FAQ

Muss ich die komplette Storefront ersetzen, um "headless" zu sein? Nein. Teil-Decoupling, bei dem nur konversionsrelevante Seitentypen entkoppelt werden, ist eine valide Zwischenstufe, kein Kompromiss.

Funktioniert Headless auch, wenn ich noch auf Shopware 5 bin? Die Store-API existiert auch in Shopware 5. Frontend zuerst entkoppeln und beim späteren Wechsel auf Shopware 6 nur den Connector austauschen, ist ein gängiger Weg, das Frontend-Risiko aus der Backend-Migration herauszuhalten.

Nächste Schritte

Wenn du gerade zwischen Twig-Theme-Pflege, Shopware-eigenem PWA-Stack und einem vollständigen Decoupling entscheidest: Headless Frontend für Shopware ansehen zeigt, wie der Store-API-Connector konkret aufgesetzt wird.

Weitere Themen aus der Laioutr-Plattform

• Headless Frontend für Shopware
• Agentic Frontend Management Platform
• Multi-Brand · Multi-Market

Über den Autor: Marcel Thiesies ist Co-Founder von Laioutr und verantwortet Produkt und Architektur der Frontend Management Platform.