Headless mit Shopware und Shopify: Wann es sich lohnt und wann nicht

Kaum ein Begriff wird im E-Commerce so oft verkauft und so selten erklärt wie Headless. Für die einen ist es die Zukunft jedes ernsthaften Onlineshops, für die anderen ein teures Experiment. Beides stimmt, je nachdem, für wen. Dieser Beitrag zeigt, was Headless bei Shopware 6 und Shopify technisch bedeutet, wo die echten Vorteile liegen, was es kostet, woran Projekte in der Praxis scheitern und wie Sie für Ihren Shop eine fundierte Entscheidung treffen.

Eine Vorbemerkung, weil dieser Beitrag früher „Shopware PWA“ hiess: Die Shopware PWA auf Basis von Vue Storefront wurde 2023 eingestellt. Ihr Nachfolger sind die Shopware Frontends, auch Composable Frontends genannt. Wer heute bei Shopware Headless plant, plant damit oder mit einem eigenen Frontend auf Basis der Store API.

Das Wichtigste in Kürze:

• Headless trennt die Oberfläche des Shops vom System dahinter. Das Frontend wird eine eigene Anwendung, die über Schnittstellen mit Shopware oder Shopify spricht.

• Der Gewinn ist Freiheit: bei Design, Technik und Kanälen. Der Preis ist ein zweites Softwareprojekt, das gebaut, betrieben und dauerhaft gepflegt werden muss.

• Die meisten Plugins und Apps funktionieren headless nicht ohne Weiteres. Alles, was sich in die Oberfläche einklinkt, muss ersetzt oder neu gebaut werden.

• Headless macht einen Shop nicht automatisch schneller, nicht besser bei Google und nicht bereiter für KI-Agenten.

• Für die meisten Händler ist ein gut gebautes Standard-Frontend die wirtschaftlich bessere Wahl. Headless lohnt sich, wenn es einen klaren Grund gibt, der das zweite Projekt bezahlt.

Was Headless technisch bedeutet

Ein klassischer Shop ist ein Stück Software, das beides erledigt: Es verwaltet Produkte, Preise, Kunden und Bestellungen, und es baut daraus die Seiten, die der Kunde sieht. In Shopware 6 übernimmt diese zweite Aufgabe die Storefront mit ihren Twig-Templates, in Shopify das Liquid-Theme. Beides läuft auf derselben Plattform, und Erweiterungen können an beiden Stellen eingreifen.

Bei Headless wird dieser Kopf abgeschnitten. Shopware oder Shopify bleiben für Katalog, Warenkorb, Kunden, Preise und Bestellungen zuständig. Die Oberfläche ist eine eigenständige Anwendung, meist auf Basis eines modernen JavaScript-Frameworks, die sich ihre Daten über Schnittstellen holt und die Seiten selbst baut. Sie läuft auf einer eigenen Infrastruktur, hat ein eigenes Deployment und einen eigenen Lebenszyklus.

Daraus folgen zwei Dinge, die Entscheider oft unterschätzen. Erstens gibt es danach zwei Systeme statt einem, mit allen Konsequenzen für Betrieb, Updates und Fehlersuche. Zweitens verliert das Frontend alles, was die Plattform bisher von selbst mitgeliefert hat. Was im Standard-Theme einfach da war, von der Suchmaschinen-Grundausstattung bis zum Cookie-Banner, muss im neuen Frontend bewusst gebaut werden.

Headless mit Shopware 6

Shopware 6 wurde von Anfang an mit Schnittstellen gebaut und eignet sich technisch gut für Headless. Die Basis ist die Store API. Sie liefert Produkte, Kategorien, Suche und Filter, Warenkorb, Checkout und Kundenkonto als strukturierte Daten aus. Daneben gibt es die Admin API für Verwaltung, Integrationen und Automatisierung.

Für das Frontend bietet Shopware die Shopware Frontends. Das ist kein fertiges Theme, sondern ein Baukasten: Pakete für die Anbindung an die Store API, typisierte Schnittstellen, fertige Bausteine für Routing, Suche und Filter, Preisdarstellung und Anmeldung sowie die Einbindung der Erlebniswelten, also der Inhaltsseiten aus dem Shopware-Admin. Darauf baut eine Vorlage auf Vue und Nuxt auf. Wer lieber mit React arbeitet, kann das Frontend auch mit Next.js bauen, denn die Store API ist an kein Framework gebunden. Seit Shopware 6.7 lassen sich zudem viele Store-API-Antworten cachen, was für schnelle Headless-Shops ein wichtiger Baustein ist.

Ein grosser Vorteil bei Shopware: Das Backend bleibt vollständig erhalten. Erlebniswelten, Regeln, Preise, Promotions, B2B-Funktionen und Verkaufskanäle werden weiter im gewohnten Admin gepflegt. Shopware bietet für Headless sogar einen eigenen Verkaufskanal-Typ an. Und der Händler behält die volle Kontrolle über den Checkout, weil auch dieser über die Store API läuft.

Headless mit Shopify

Bei Shopify heisst das Gegenstück Hydrogen. Hydrogen ist ein Framework auf Basis von React Router, das für die Shopify-Schnittstellen vorbereitet ist. Gehostet wird es standardmässig auf Oxygen, der Hosting-Plattform von Shopify, die in den bezahlten Tarifen enthalten ist. Alternativ lässt sich ein Headless-Frontend auch anders betreiben, etwa mit Next.js auf eigener Infrastruktur.

Die Daten kommen aus der Storefront API und der Customer Account API. Der wichtigste Unterschied zu Shopware: Der Checkout bleibt bei Shopify. Ein Headless-Warenkorb liefert eine Checkout-Adresse, und der Kunde wechselt für den Kauf auf den Shopify-Checkout. Anpassen lässt sich dieser nach denselben Regeln wie bei einem normalen Theme, also mit den Möglichkeiten des jeweiligen Tarifs.

Einen Punkt sollten Shopify-Händler kennen, bevor sie entscheiden: Die Schnittstellen erscheinen in neuen Versionen im Quartalsrhythmus, und auch Hydrogen folgt diesem Takt. Ein Headless-Frontend auf Shopify ist deshalb nie fertig, es muss regelmässig auf neue Versionen gebracht werden. Gleichzeitig verliert der Händler den Theme-Editor, mit dem Marketing bisher Inhalte selbst angepasst hat. Diese Freiheit muss über ein CMS oder über Metaobjekte neu geschaffen werden.

Der direkte Vergleich

Das Problem mit Plugins und Apps

Hier scheitern in der Praxis die meisten Headless-Kalkulationen. Ein typischer Shop hat Dutzende Erweiterungen. Ein grosser Teil davon wirkt genau dort, wo Headless ansetzt: an der Oberfläche.

In Shopware bringen viele Plugins eigene Twig-Templates, eigenes JavaScript und eigene Storefront-Logik mit. Bewertungs-Widgets, Produktkonfiguratoren, Cross-Selling-Slider, Wunschlisten, Gutschein-Funktionen, Live-Suche, Chat oder Zahlungsarten mit eigenem Ablauf im Checkout: Alles, was in der Storefront sichtbar wird, existiert in einem Headless-Frontend zunächst nicht. Plugins, die nur im Backend arbeiten, etwa Schnittstellen zur Warenwirtschaft, funktionieren weiter. Plugins, die ihre Daten zusätzlich über die Store API bereitstellen, lassen sich anbinden, müssen aber trotzdem im Frontend neu dargestellt werden.

Bei Shopify ist es ähnlich. Die meisten Apps hängen sich über Theme-Erweiterungen in den Shop ein, also über App-Blöcke und App-Einbettungen im Liquid-Theme. Auf einem Headless-Frontend werden sie nicht angezeigt. Es braucht Apps, die ausdrücklich eigene Frontends unterstützen, oder eine eigene Anbindung über deren Schnittstellen. Was im Checkout passiert, ist bei Shopify die Ausnahme: Weil der Checkout bei Shopify bleibt, funktionieren Checkout-Erweiterungen weiter.

Der praktische Rat ist deshalb einfach und wird trotzdem fast immer übersprungen: Vor jeder Headless-Entscheidung gehört eine vollständige Liste aller Plugins und Apps auf den Tisch, mit drei Spalten. Funktioniert weiter. Muss angebunden werden. Muss ersetzt oder neu gebaut werden. Erst diese Liste macht aus einer Schätzung eine Kalkulation.

Was oft übersehen wird

• Suchmaschinen-Grundausstattung: Seitentitel, Meta-Beschreibungen, Canonicals, hreflang, Weiterleitungen, strukturierte Daten und Sitemap liefert das Standard-Theme mit. Im Headless-Frontend muss all das gebaut werden. Fehlt etwas davon beim Start, verliert der Shop Rankings, die über Jahre gewachsen sind. Zwingend ist ausserdem serverseitiges Rendern, damit der Googlebot vollständige Seiten bekommt und nicht erst JavaScript ausführen muss.

• Tracking und Einwilligung: Consent-Banner, Analytics, Werbe-Pixel und Conversion-Tracking müssen im neuen Frontend vollständig neu eingerichtet werden. Ein guter Moment, gleich auf Server-Side Tracking umzustellen.

• Zahlungsarten: Viele Zahlungsanbieter arbeiten mit Weiterleitungen, eingebetteten Formularen oder eigener Logik im Checkout. Bei Shopware muss jede Zahlungsart im Headless-Checkout geprüft und oft angepasst werden.

• Vorschau und Pflege: Redakteure wollen sehen, wie eine Seite aussieht, bevor sie live geht. Eine verlässliche Vorschau im Headless-Frontend ist eigene Arbeit.

• Fehlersuche: Liegt ein Problem im Frontend, in der Schnittstelle, im Cache oder in Shopware oder Shopify? Bei zwei Systemen dauert die Suche länger, und es braucht Menschen, die beide Seiten verstehen.

Mythen rund um Headless

„Headless ist automatisch schneller.“ Nicht unbedingt. Ein Headless-Frontend kann sehr schnell laden, besonders mit gutem Caching. Bei der Reaktionszeit auf Klicks kann es aber sogar schlechter abschneiden, weil moderne Frameworks im Browser viel JavaScript ausführen, bevor die Seite reagiert. Wie man die Reaktionszeit misst und verbessert, zeigt der Beitrag zu INP. Ein schlankes Standard-Theme schlägt ein schlecht gebautes Headless-Frontend jederzeit.

„Headless ist besser für SEO.“ Für Google zählt, was ankommt: vollständige Inhalte, saubere Technik, gute Nutzererfahrung. Das kann ein Headless-Frontend genauso liefern wie ein Standard-Theme, aber es liefert es nicht von selbst. Mehr zu den Grundlagen unter Shopware SEO und Shopify SEO.

„Mit Headless sind wir bereit für KI-Agenten.“ KI-Agenten kaufen nicht über die Oberfläche ein, sondern über Daten und Schnittstellen. Ob ein Shop für Agenten bereit ist, entscheiden Produktdaten und Protokolle wie UCP, und die hängen am Backend. Shopware bietet die Anbindung über die Erweiterung Agentic Commerce auch für Headless-Verkaufskanäle an, Shopify spielt Produkte unabhängig vom Frontend an KI-Assistenten aus. Mehr dazu im Beitrag zu UCP und Agentic Commerce.

„Headless ist zukunftssicher.“ Es ist flexibler, aber nicht automatisch zukunftssicher. Frameworks veralten schneller als Shopsysteme. Das zeigt die Geschichte dieses Beitrags selbst: Die Shopware PWA, über die er einmal geschrieben wurde, gibt es nicht mehr.

Was Headless kostet

Die Kosten eines Headless-Projekts bestehen aus drei Teilen. Der erste ist der Aufbau: Das Frontend wird von Grund auf entwickelt, inklusive aller Funktionen, die das Standard-Theme mitgebracht hätte, und aller Erweiterungen, die neu angebunden oder gebaut werden müssen. Erfahrungsgemäss ist dieser Aufwand ein Vielfaches eines guten Theme-Projekts.

Der zweite Teil ist der Betrieb: Hosting, Monitoring, Caching und Deployment für ein zusätzliches System. Bei Shopify ist das Hosting auf Oxygen in den bezahlten Tarifen enthalten, die Arbeit am Betrieb aber nicht.

Der dritte und am häufigsten unterschätzte Teil ist die laufende Pflege. Framework-Updates, Schnittstellen-Versionen, Sicherheitsupdates und jede neue Funktion, die künftig nicht mehr per Plugin oder App kommt, sondern entwickelt werden muss. Wer Headless plant, plant ein dauerhaftes Entwicklungsbudget, kein einmaliges Projekt.

Wann sich Headless lohnt

Headless ist die richtige Wahl, wenn mindestens einer dieser Gründe zutrifft und der Nutzen die laufenden Kosten trägt:

• Mehrere Kanäle aus einem Backend: Webshop, App, Terminal im Laden, Marktplatz-Frontends oder Kundenportale sollen dieselben Daten nutzen.

• Ein Einkaufserlebnis, das ein Theme nicht abbilden kann: komplexe Konfiguratoren, stark inhaltsgetriebene Markenwelten oder Funktionen, die sich mit Templates nur mit grossem Aufwand umsetzen lassen.

• Eine bestehende Systemlandschaft: Ein vorhandenes Headless-CMS, eine eigene Suche oder ein Design-System, das über mehrere Marken und Länder hinweg genutzt wird.

• Ein eigenes Frontend-Team: Wer Entwicklerinnen und Entwickler für Vue oder React im Haus hat oder dauerhaft beauftragt, kann die Pflege tragen.

Wann nicht

• Wenn das Hauptmotiv Geschwindigkeit ist: Ein schlankes, sauber gebautes Theme ist der günstigere Weg zu guten Werten.

• Wenn der Shop stark von Plugins oder Apps lebt: Jede Erweiterung an der Oberfläche wird zum Einzelprojekt.

• Wenn Marketing Inhalte selbst pflegen soll und kein CMS-Konzept existiert.

• Wenn das Budget für den Start reicht, aber nicht für die Jahre danach.

Dazwischen gibt es einen Weg, der oft übersehen wird: den hybriden Ansatz. Der Hauptshop läuft auf dem Standard-Frontend, einzelne Kanäle oder Bereiche, etwa eine App, ein Kundenportal für B2B oder eine Markenwelt, werden headless gebaut. So entsteht Flexibilität dort, wo sie gebraucht wird, ohne den ganzen Shop umzubauen.

Eine Entscheidung in fünf Fragen

1. Welchen konkreten Nutzen soll Headless bringen, den das Standard-Frontend nicht liefern kann?

2. Welche Plugins oder Apps nutzen Sie, und wie viele davon wirken an der Oberfläche?

3. Wer pflegt das Frontend in drei Jahren, und mit welchem Budget?

4. Wie werden Inhalte gepflegt, wenn Theme-Editor oder Storefront wegfallen?

5. Wie sichern Sie beim Wechsel Rankings, Tracking und Zahlungsarten ab?

Lassen sich alle fünf Fragen überzeugend beantworten, ist Headless eine starke Option. Bleibt eine davon offen, ist sie fast immer der Grund, warum Projekte teurer werden als geplant.

Headless oder Standard: die Entscheidung mit arboro

arboro entwickelt Shopware- und Shopify-Shops seit vielen Jahren, mit klassischen Frontends ebenso wie mit Headless-Architekturen. Bevor gebaut wird, prüfen wir mit Ihnen, ob Headless für Ihren Shop wirtschaftlich sinnvoll ist: mit einer Bestandsaufnahme aller Plugins und Apps, einer ehrlichen Kostenschätzung über mehrere Jahre und einem Plan für SEO, Tracking und Zahlungsarten. Manchmal ist das Ergebnis ein Headless-Projekt, oft ein besseres Standard-Frontend. Beides ist eine gute Antwort, wenn sie zu Ihrem Geschäft passt. Mehr dazu unter Shopware- und Shopify-Entwicklung.