Headless Commerce: Welche Vorteile bei einem Shopify-Wechsel wirklich zählen

In fast jedem zweiten Erstgespräch mit einem Umsteiger fällt das Wort innerhalb der ersten zehn Minuten. “Wir überlegen, ob wir gleich headless gehen.” Manchmal kommt es vom CTO, häufiger von der Agentur davor, gelegentlich aus einem LinkedIn-Post.

Und fast immer steht dahinter eine berechtigte Erfahrung: Im alten System war das Frontend der Ort, an dem Ideen gestorben sind. Jede Designänderung ein Ticket, jedes Ticket ein Release, jedes Release ein Risiko. Wer das jahrelang erlebt hat, will beim Umstieg vor allem eines - nie wieder vom Frontend blockiert werden.

Headless verspricht genau das. Die Frage ist nur, ob Sie dafür Headless brauchen. Und was es kostet, wenn Sie es nehmen, ohne es zu brauchen.

Was Headless technisch bedeutet

Kurz und ohne Marketing: Headless heißt, dass Frontend und Backend voneinander getrennt sind. Die Storefront - also alles, was Ihre Kunden sehen - ist eine eigenständige Anwendung. Sie holt sich Produkte, Preise, Bestände und Warenkorbzustände über APIs aus dem Commerce-System und rendert daraus, was sie will.

Bei Shopify heißt diese Schnittstelle Storefront API. Das Backend bleibt Shopify: Katalog, Checkout, Zahlungsabwicklung, Bestellverwaltung, Steuern, Betrugserkennung. Was Sie ersetzen, ist ausschließlich die Präsentationsschicht - die Liquid-Storefront.

Shopify liefert dafür zwei eigene Bausteine: Hydrogen, ein React-Framework mit vorgefertigten Commerce-Komponenten, und Oxygen, das passende Hosting am Edge. Sie sind nicht verpflichtet, beides zu nehmen - Next.js oder Nuxt auf Vercel funktioniert genauso - aber die Kombination nimmt Ihnen einen guten Teil der Integrationsarbeit ab.

Wichtig für die Einordnung: Der Checkout bleibt in praktisch allen Fällen bei Shopify. Das ist kein Mangel, sondern der Grund, warum Shopify-Headless überhaupt beherrschbar ist. Sie behalten Shop Pay, die PSD2-Konformität, die Betrugsprüfung und die Conversion-Optimierung, die Shopify über Millionen Shops hinweg fährt. Was Sie am Checkout anpassen wollen, machen Sie über Checkout Extensibility - nicht über Headless.

Architektur

Was sich ändert - und was nicht

Headless tauscht ausschließlich die Präsentationsschicht aus. Die beiden unteren Ebenen sind in beiden Varianten dasselbe System.

Variante A

Liquid-Storefront

1. Liquid-Theme

   Shopify

   Sektionen, JSON-Templates, App Blocks - serverseitig von Shopify gerendert

2. Commerce-Kern

   Shopify

   Katalog, Preise, Bestände, Kunden, Bestellungen

3. Checkout

   Shopify

   Shop Pay, PSD2, Betrugsprüfung, Steuern

Variante B

Headless-Storefront

1. Eigenes Frontend

   Ihr Team

   Hydrogen, Next.js oder Nuxt - eigenes Repo, eigenes Deployment

2. Storefront API

   Schnittstelle

   GraphQL - liefert Produkte, Preise, Bestände, Warenkorbzustand

3. Commerce-Kern

   Shopify

   Katalog, Preise, Bestände, Kunden, Bestellungen

4. Checkout

   Shopify

   Shop Pay, PSD2, Betrugsprüfung, Steuern

Der Checkout bleibt in praktisch allen Fällen bei Shopify. Genau das ist der Grund, warum Shopify-Headless überhaupt beherrschbar ist.

Die acht Vorteile im Realitätscheck

Die Standardliste der Headless-Vorteile ist überall dieselbe. Sie ist nicht falsch. Sie ist nur selten danach sortiert, wie viel davon Sie auf einer modernen Liquid-Storefront ohnehin bekommen. Genau das machen wir hier.

Realitätscheck

Acht Vorteile, drei Urteile

• 2 Echt - unter Bedingung echte Headless-Argumente
• 3 Auch auf Liquid bekommen Sie auch auf Liquid
• 3 Trägt nicht halten dem Check nicht stand

1. 1

   Design- und Technologiefreiheit

   Echt - unter Bedingung

   Versprechen Keine Template-Vorgaben mehr

   Echt bei anderer Interaktionslogik - nicht bei anderem Aussehen

2. 2

   Schnellere Anpassungen

   Trägt nicht

   Versprechen Features ohne Eingriff in die Architektur

   Kippt ins Gegenteil: schneller für Entwicklung, langsamer für alle anderen

3. 3

   Mehrere Kanäle auf einem Backend

   Auch auf Liquid

   Versprechen Ein Backend, viele Frontends

   POS, Marktplätze und Social laufen nativ auf demselben Katalog

4. 4

   Personalisierte Erlebnisse

   Echt - unter Bedingung

   Versprechen Getrennte Flüsse für B2B, B2C, Region

   Echt nur bei serverseitiger Personalisierung ohne Layout-Sprung

5. 5

   Flexible Systemintegration

   Auch auf Liquid

   Versprechen CMS, PIM, Analytics über APIs

   Gilt unabhängig von der Storefront - ERP und PIM ändern sich nicht

6. 6

   Performance

   Trägt nicht

   Versprechen Frei auf Geschwindigkeit optimierbar

   Nicht automatisch schneller - wir sehen häufiger das Gegenteil

7. 7

   Internationalisierung

   Auch auf Liquid

   Versprechen Eigene Frontends pro Markt

   Shopify Markets deckt Währung, Steuern, Sprache und Domains ab

8. 8

   Gezielte Skalierbarkeit

   Trägt nicht

   Versprechen Komponenten unabhängig skalieren

   Löst der Wechsel auf Shopify - nicht der Wechsel auf Headless

1. Design- und Technologiefreiheit

Das Versprechen: Keine Template-Vorgaben mehr. Eigene Produktberater, eigene Navigationskonzepte, ein Frontend, das exakt zur Marke passt.

Der Realitätscheck: Das ist der ehrlichste Punkt auf der Liste - und trotzdem der am häufigsten überschätzte. Shopify-Themes seit Online Store 2.0 sind Sektionen-basiert, JSON-Templates lassen sich pro Seitentyp frei zusammenstellen, und mit App Blocks und Custom Liquid bauen Sie sehr weitgehend, was Sie wollen.

Wir haben Marken-Storefronts gebaut, die niemand als Shopify erkennt - komplett in Liquid. Die Grenze verläuft nicht bei “sieht individuell aus”, sondern bei “verhält sich grundsätzlich anders als ein Shop”: echte Konfiguratoren mit Abhängigkeitslogik, Produktberater über mehrere Schritte mit persistiertem Zustand, Visualisierungen in 3D. Dort wird Liquid zäh, weil es serverseitig rendert und jeden Zwischenschritt als Seitenwechsel behandelt.

Ihre Frage dazu: Ist Ihr Anspruch ein anderes Aussehen oder eine andere Interaktionslogik? Nur beim Zweiten ist Headless das passende Werkzeug.

2. Schnellere Anpassungen

Das Versprechen: Features entwickeln, testen und ausrollen, ohne die gesamte Commerce-Architektur anzufassen.

Der Realitätscheck: Hier kippt das Argument für die meisten Umsteiger sogar ins Gegenteil. Auf einer Liquid-Storefront ändert Ihr Marketing Content, Reihenfolge und Landingpages selbst - im Theme-Editor, ohne Entwickler, ohne Deployment. In einem Headless-Setup ist jede dieser Änderungen wieder ein Ticket, ein Pull Request und ein Build. Es sei denn, Sie hängen ein Headless-CMS daneben und pflegen die Redaktionsoberfläche mit.

Was Headless wirklich beschleunigt, ist die Arbeit des Entwicklungsteams: moderne Toolchain, Komponenten, Tests, Preview-Deployments pro Branch. Was es verlangsamt, ist die Arbeit aller anderen.

Ihre Frage dazu: Wer ändert bei Ihnen häufiger etwas am Frontend - Entwicklung oder Marketing? Die Antwort entscheidet, in welche Richtung dieser Punkt zeigt.

3. Mehrere Kanäle auf einem Backend

Das Versprechen: Ein Backend, viele Frontends - Web, App, Marktplatz, Terminal im Store.

Der Realitätscheck: Sachlich richtig, aber Shopify löst das teilweise schon ohne Headless. POS, Marktplatz-Anbindungen und Social-Channels laufen als native Vertriebskanäle auf demselben Katalog. Der Fall, in dem Headless zwingend wird, ist eine eigene native App oder ein selbstgebautes Store-Terminal, das dieselben Daten braucht.

Und selbst dann gilt: Sie brauchen dafür die Storefront API - aber nicht zwingend ein Headless-Web-Frontend. Eine native App über die API und daneben eine klassische Liquid-Storefront ist eine völlig legitime, deutlich günstigere Kombination. Diese Zwischenstufe wird fast immer übersehen.

4. Personalisierte Erlebnisse

Das Versprechen: Getrennte Storefronts für B2B und B2C, regionale Inhalte, unterschiedliche Nutzerflüsse.

Der Realitätscheck: B2B-Funktionen wie Firmenkonten, Preislisten pro Kunde, Zahlungsziele und Bestellfreigaben gibt es auf Shopify Plus nativ - inklusive B2B-fähiger Liquid-Themes. Für die klassische “wir brauchen einen eigenen Bereich für Händler”-Anforderung ist Headless mit Kanonen auf Spatzen geschossen.

Wo es sich dreht: wenn Sie personalisierte Inhalte serverseitig ausspielen wollen, ohne Layout-Sprünge und ohne dass die Personalisierung erst nach dem ersten Rendern greift. Das ist auf Liquid mit Caching-Vorgaben schwierig und in einem eigenen Frontend sauber lösbar.

5. Flexible Systemintegration

Das Versprechen: CMS, PIM, Analytics und Suche über APIs anbinden, statt alles in eine Plattform zu pressen.

Der Realitätscheck: Dieser Punkt gilt unabhängig von Headless. Ihr PIM schreibt in beiden Welten über die Admin API in den Shopify-Katalog. Ihr ERP synchronisiert Bestände und Bestellungen in beiden Welten identisch - die Muster dazu haben wir in unserem Überblick zu ERP-Integrationen beschrieben. Nichts davon ändert sich durch die Wahl der Storefront.

Der einzige Unterschied liegt beim Content: Wenn Sie ein Enterprise-CMS im Haus haben, in dem Redaktion, Freigabeprozesse und mehrsprachige Inhalte bereits leben, ist ein eigenes Frontend der natürliche Ort, um Commerce-Daten und CMS-Inhalte zusammenzuführen. Das ist ein echtes Headless-Argument - aber es ist ein Content-Argument, kein Integrations-Argument.

6. Performance

Das Versprechen: Das Frontend lässt sich frei auf Geschwindigkeit optimieren.

Der Realitätscheck: Der Punkt, bei dem am meisten geglaubt und am wenigsten gemessen wird. Headless ist nicht automatisch schneller. Ein schlecht gebautes React-Frontend mit 900 KB JavaScript, Client-seitigem Routing und drei Wasserfall-Requests bis zum ersten Produktbild ist messbar langsamer als ein aufgeräumtes Liquid-Theme, das serverseitig gerendert über Shopifys CDN ausgeliefert wird.

Wir haben mehr Headless-Storefronts mit schlechten Core Web Vitals gesehen als Liquid-Storefronts mit schlechten. Das liegt nicht an der Architektur, sondern daran, dass Liquid einen strengen Rahmen vorgibt und ein eigenes Frontend jede Menge Seil zum Selbstaufhängen mitliefert.

Was Headless ermöglicht: aggressives Prefetching, granulare Ladeprioritäten, Edge-Rendering nah am Nutzer. Was es verlangt: ein Team, das Performance-Budgets ernst nimmt und im CI überwacht. Ohne das Zweite bekommen Sie das Erste nicht. Unsere Sicht dazu steht ausführlicher im Artikel zu Mobile-First-Performance bei Shopify.

7. Internationalisierung

Das Versprechen: Eigene Frontends pro Land oder Region bei gemeinsamem Commerce-Kern.

Der Realitätscheck: Shopify Markets deckt Währungen, Preisregeln, Steuern, Sprachversionen und Domain-Struktur auf der Liquid-Storefront vollständig ab. Für neunzig Prozent der DACH-Shops, die nach Österreich, in die Schweiz und in die Niederlande expandieren, ist das die richtige und deutlich günstigere Antwort - Details dazu in unserem Überblick zu Shopify Markets.

Headless wird hier erst relevant, wenn sich Märkte inhaltlich stark unterscheiden - eigene Kampagnenlogik, eigene Redaktion, andere Seitenstrukturen pro Land. Wenn dagegen nur Sprache, Währung und Versandregeln variieren, lösen Sie das mit Markets.

8. Gezielte Skalierbarkeit

Das Versprechen: Einzelne Komponenten unabhängig voneinander skalieren.

Der Realitätscheck: Dieses Argument stammt aus der selbstgehosteten Welt und trifft auf Shopify kaum zu. Shopifys Backend skaliert für Sie, inklusive Black-Friday-Lastspitzen, ohne dass Sie etwas dimensionieren. Wenn Sie von Magento kommen und Skalierung bisher Ihr Problem war, ist die gute Nachricht: Das erledigt der Wechsel auf Shopify, nicht der Wechsel auf Headless.

Die Kostenseite, die in der Liste fehlt

Die acht Vorteile stehen überall. Die vier Posten hier stehen selten daneben - und genau sie entscheiden, ob ein Headless-Projekt zwei Jahre später noch geliebt wird.

Sie bauen und betreiben eine zweite Codebase. Ein eigenes Frontend ist eine eigene Anwendung mit eigenem Repository, eigenen Abhängigkeiten, eigenem Deployment und eigener Sicherheitsverantwortung. Framework-Major-Releases, Dependency-Updates, Build-Pipeline - das ist laufender Aufwand, der nie wieder verschwindet. Kalkulieren Sie ihn als feste Position, nicht als Projektende.

Sie verlieren einen Teil des App-Ökosystems. Der stärkste Grund für Shopify ist, dass es für fast jedes Problem eine fertige App gibt. Viele davon injizieren ihre Funktionalität aber über Theme App Extensions in die Liquid-Storefront. In einem eigenen Frontend funktioniert das nicht automatisch - Sie brauchen die API-Anbindung der App oder bauen die Funktion selbst nach. Prüfen Sie das vor der Architekturentscheidung für Ihre konkreten Apps, nicht danach.

Sie brauchen Frontend-Kompetenz im Haus oder verlässlich daneben. Ein Liquid-Theme kann in vielen Teams auch jemand ohne React-Erfahrung anfassen. Ein Hydrogen-Frontend nicht. Wenn Ihre Entwicklungskapazität aus einer halben Stelle plus Agentur besteht, ist Headless eine Abhängigkeit, die Sie sich sehr bewusst einkaufen sollten.

Sie verlagern Analytics- und Tracking-Arbeit zu sich. Auf der Liquid-Storefront kommen Consent-Management, Pixel-Integration und E-Commerce-Tracking weitgehend über Shopifys Customer Privacy API und die Pixel-Verwaltung. Im eigenen Frontend implementieren Sie das selbst - inklusive DSGVO-konformer Consent-Logik. Das ist machbar, aber es ist Arbeit, die im Angebot regelmäßig fehlt.

Wann Headless die richtige Entscheidung ist

Nach ungefähr fünfzehn dieser Architekturgespräche hat sich bei uns eine ziemlich einfache Heuristik herausgebildet.

Heuristik

Die Waage ist nicht symmetrisch

Für Headless müssen zwei Kriterien zutreffen. Für Liquid reicht eines. Diese Asymmetrie ist Absicht - die teurere Architektur trägt die Beweislast.

Headless nehmen

mindestens 2 von 5

• Interaktionslogik, die kein Shop-Frontend ist - Konfiguratoren mit Abhängigkeiten, mehrstufige Beratungsstrecken, komplexe Visualisierung
• Ein Enterprise-CMS mit etablierten Redaktionsprozessen, das die Content-Hoheit behalten muss
• Mehrere echte Frontends auf einem Katalog - native App, eigene Store-Terminals
• Ein festes Frontend-Team mit React-Erfahrung, dauerhaft zuständig für die Storefront
• Märkte, die sich strukturell unterscheiden - nicht nur sprachlich

Bei Liquid bleiben

genügt 1 von 4

• Ihr Marketing soll Landingpages und Kampagnen selbst bauen können
• Ihre Frontend-Kapazität ist eine Agentur mit begrenztem Retainer
• Ihr Hauptargument ist "individuelles Design" oder "Performance" - beides bekommen Sie auf Liquid
• Sie migrieren gerade und wollen zuerst stabil live gehen

Migration und Headless gleichzeitig ist eine Wette, die Sie nicht eingehen müssen. Wer parallel die Storefront-Architektur neu erfindet, kann bei einem Traffic-Einbruch nach dem Go-Live nicht mehr sauber unterscheiden, woran es lag.

Eine Plattformmigration bringt genug eigene Risiken mit - Datenübernahme, Redirect-Map, Prozessumstellung, Schulung. Unsere Migrations-Checkliste geht deshalb bewusst von einer Liquid-Storefront aus.

Der Weg, den wir Umsteigern meistens empfehlen

Es gibt eine dritte Option zwischen “alles Liquid” und “alles Headless”, und sie ist in der Praxis fast immer die beste.

Schritt eins: Auf Liquid migrieren und live gehen. Katalog, Checkout, Prozesse, Redirects, Team-Schulung. Sechs bis zwölf Wochen, klarer Umfang, überschaubares Risiko. Ihre Marketing-Kollegen bekommen sofort ein System, in dem sie selbst arbeiten können.

Schritt zwei: Drei bis sechs Monate Daten sammeln. Wo bricht die Conversion ab? Welche Seiten sind langsam? Was fragt Ihr Marketing an, das das Theme nicht hergibt? Diese Liste ist die einzige belastbare Grundlage für eine Headless-Entscheidung - und sie sieht regelmäßig anders aus als die Wunschliste vor dem Go-Live.

Schritt drei: Punktuell entkoppeln, wo es weh tut. Braucht nur der Konfigurator eine eigene Anwendung? Dann bauen Sie den als eingebettete Anwendung neben der Liquid-Storefront und lassen den Rest, wie er ist. Braucht die native App die Storefront API? Dann nutzen Sie sie dort - ohne das Web-Frontend anzufassen.

Headless ist keine Ja-Nein-Entscheidung für den ganzen Shop. Es ist ein Werkzeug, das Sie an genau den Stellen einsetzen können, an denen die Standard-Storefront nachweislich nicht reicht. Wer das so anwendet, zahlt die Kosten nur für die Teile, die den Nutzen auch liefern. Die verwandte Abwägung zwischen Theme-Anpassung und eigener App haben wir im Vergleich von Custom Liquid und Custom Apps durchgespielt.

Checkliste

Checkliste vor der Architekturentscheidung

Acht Punkte, die vor der Entscheidung für oder gegen ein eigenes Frontend beantwortet sein sollten. Ihre Häkchen bleiben in diesem Browser gespeichert.

• Anforderungen sortiert nach "anderes Aussehen" und "andere Interaktionslogik"
• Geprüft, welche Ihrer Wunsch-Apps ohne Theme App Extensions funktionieren
• Verantwortung für Frontend-Betrieb und -Wartung namentlich geklärt
• Realistisch beantwortet, wer Landingpages künftig baut
• Performance-Budget definiert und im CI verankert - falls Headless
• Consent- und Tracking-Implementierung als eigene Aufwandsposition kalkuliert
• Entschieden, ob Migration und Architekturwechsel getrennt werden
• Ausstiegs- und Zwischenszenario benannt: Was, wenn nur ein Teil entkoppelt wird?

---

Headless Commerce ist eine gute Architektur für Probleme, die Sie tatsächlich haben. Der teure Fehler ist nicht, sich dafür zu entscheiden - sondern, sich dafür zu entscheiden, bevor man weiß, welches Problem gelöst werden soll.

Wenn Sie gerade vor genau dieser Frage stehen und wissen wollen, ob Ihre konkrete Anforderungsliste ein eigenes Frontend rechtfertigt: Lassen Sie uns sprechen - wir gehen die Liste mit Ihnen durch und sagen Ihnen auch dann, wenn die Antwort “brauchen Sie nicht” lautet.