Was ist Headless Commerce? Funktionsweise, Vor- und Nachteile, Beispiele

Headless Commerce ist eine E-Commerce-Architektur, bei der die Storefront, die Käufer sehen (der „Head“), von der Commerce-Engine getrennt ist, die Produkte, Preise, Warenkörbe, Checkout und Bestellungen steuert (das Backend). Beide sprechen nur über APIs miteinander. Du kannst ein Frontend neu bauen, umgestalten oder hinzufügen, ohne das Backend anzufassen, und ein Backend kann mehrere Frontends gleichzeitig versorgen: eine Website, eine mobile App, einen Kiosk im Laden oder einen Marketplace-Feed.

In einem klassischen Setup, etwa einem Shopify-Theme oder einer Magento-Storefront im Auslieferungszustand, kommen Template-Ebene und Commerce-Engine als ein Produkt. In einem Headless-Setup baut ein Entwicklerteam die Storefront mit einem Framework seiner Wahl und holt jedes Produkt, jeden Preis und jeden Warenkorb über die API der Plattform. Das gibt dir volle Kontrolle über das Erlebnis, im Tausch gegen mehr Entwicklungsaufwand und höhere Anforderungen an deine Produktdaten. Dieser Beitrag erklärt, wie es funktioniert, wie es sich von klassischem und Composable Commerce unterscheidet, wann es sich lohnt und was es für die Leute ändert, die den Katalog pflegen.

Die drei Ebenen eines Headless-Shops

Ein Headless-Shop hat drei Ebenen. Jede lässt sich separat betreiben, hosten und ändern.

• Das Frontend (der Head): der Storefront-Code, oft mit einem JavaScript-Framework wie React oder Vue gebaut. Er rendert Seiten, steuert die Navigation und ruft Daten über APIs ab. Es kann mehr als einen Head geben: einen Webshop, eine iOS-App und einen Kassenbildschirm.
• Die API-Ebene: der Vertrag zwischen Head und Body. Shopifys Storefront API ist rein GraphQL, Adobe Commerce bietet GraphQL als Grundlage für Headless-Storefronts, und die Store API von WooCommerce stellt Endpunkte für Warenkorb und Checkout für jedes Frontend bereit.
• Das Backend (der Body): die Commerce-Plattform, die Katalog, Bestand, Preise, Aktionen, Checkout, Zahlungen und Bestellungen verwaltet. Produktinhalte kommen oft aus weiteren Systemen, etwa einem Headless CMS für redaktionelle Seiten und einem PIM für Produktdaten.

Eine Produktseitenanfrage in einem Headless-Shopify-Shop zeigt den Ablauf. Ein Käufer in Deutschland öffnet /de/products/merino-crew-socks-3-pack. Die Storefront fragt die Storefront API nach diesem Produkt, mit Land Deutschland und Sprache Deutsch, und erhält den deutschen Titel, die Beschreibung, die Variantenoptionen (Größe 39 bis 42, 43 bis 46), Preise in Euro und Bild-URLs. Dann rendert die Storefront die Seite in ihrem eigenen Design. Nichts an dieser Seite stammt aus einer Theme-Datei der Plattform.

Headless vs. klassischer (monolithischer) Commerce

Der Unterschied liegt darin, wo die Storefront lebt und wer sie ändern kann.

Wo Composable Commerce und MACH weitergehen

Diese Begriffe sind verwandt, aber nicht gleich. Headless beschreibt eine Trennung: Frontend vom Backend. Das Backend kann trotzdem eine einzige All-in-one-Plattform sein. Viele Headless-Shops betreiben eine eigene React-Storefront auf einem Standard-Backend wie Shopify Plus oder Adobe Commerce.

Composable Commerce geht weiter: Das Backend selbst wird aus einzelnen Services zusammengesetzt, die du einzeln auswählst, etwa die Suche von einem Anbieter, den Checkout von einem anderen und Aktionen von einem dritten. Headless ist eine Voraussetzung für Composable, aber du kannst headless sein, ohne composable zu sein. MACH-Architektur (Microservices, API-first, Cloud-native, Headless) ist ein Label für das vollständig composable Ende dieses Spektrums.

Beispiele für Headless-Setups

Die meisten gängigen Plattformen unterstützen einen Headless-Modus. Ein paar typische Muster:

• Shopify mit Hydrogen: Shopifys eigenes React-basiertes Framework für individuelle Storefronts, gehostet auf Oxygen, mit Daten aus der Storefront API. Shopify beschreibt es so, dass die Plattform „unter der Haube“ bleibt, während du das Frontend kontrollierst (Shopify).
• Shopify oder BigCommerce mit einer Next.js-Storefront: ein Framework, das das Team bereits kennt, auf einer allgemeinen Hosting-Plattform bereitgestellt, mit der Commerce-Plattform als reinem Backend.
• Adobe Commerce (Magento 2) mit einer PWA: eine Progressive-Web-App-Storefront, die Katalog- und Warenkorbdaten über GraphQL liest.
• WooCommerce headless: WordPress und WooCommerce verwalten weiter Katalog und Bestellungen, während ein separates Frontend die Store API für Warenkorb und Checkout nutzt.
• Ein Backend, mehrere Heads: Eine Marke betreibt einen Webshop, eine mobile App und Touchscreens in ihren eigenen Läden, die alle dieselben Produkte und Bestände lesen.

Vorteile von Headless Commerce

Die Vorteile sind real, aber jeder setzt voraus, dass du das Team hast, um ihn zu nutzen.

• Designfreiheit: Die Storefront kann aussehen und sich verhalten, wie du willst, ohne die Grenzen der Sections und Einstellungen eines Themes.
• Frontend-Geschwindigkeit: Ein modernes Framework mit serverseitigem Rendering, Caching am Edge und schlanken Seiten kann schneller laden als ein Theme mit einem Dutzend App-Skripten. Das ist möglich, aber nicht automatisch.
• Mehrere Kanäle aus einer Quelle: Apps, Kioske, Smart Displays und neue Storefronts nutzen denselben Katalog und Checkout, statt jeweils eine eigene Kopie zu bekommen.
• Unabhängige Release-Zyklen: Das Frontend-Team kann täglich ausliefern, ohne den Checkout zu gefährden, und eine Backend-Migration erzwingt kein Redesign.
• Internationale Storefronts: Ein Backend kann getrennte Länderseiten mit eigenem Design und Inhalt versorgen und dabei Bestand und Bestellungen teilen.

Nachteile und Kosten von Headless

Teams, die auf Headless umsteigen, unterschätzen meist dieselben Kosten.

• Du besitzt ein Softwareprodukt. Die Storefront braucht Entwickler für jede neue Funktion, jeden Bugfix und jedes Framework-Upgrade, solange sie läuft.
• Verlorenes App-Ökosystem: Theme-Apps für Bewertungen, Bundles, Wunschlisten und Filter funktionieren eventuell nicht und müssen per API integriert oder neu gebaut werden.
• Weniger Self-Service für Merchandiser: Ohne visuelles CMS wird jede Banner- oder Landingpage-Änderung zum Entwickler-Ticket.
• SEO-Risiko bei der Migration: Seiten, die von clientseitigem JavaScript abhängen, müssen gerendert werden, bevor Google sie indexieren kann. Google stellt JavaScript-Seiten in eine Rendering-Warteschlange und empfiehlt weiterhin serverseitiges Rendering oder Pre-Rendering, da nicht jeder Bot JavaScript ausführt (Google Search Central). Meta-Tags, strukturierte Daten, Canonical-Tags und Weiterleitungen müssen bewusst neu aufgebaut werden.
• Mehr Systeme zu überwachen: Frontend-Hosting, API, CMS und Commerce-Plattform können jeweils einzeln ausfallen.
• Höhere Gesamtkosten: Entwicklungskosten, Hosting, eine Headless-CMS-Lizenz und laufende Entwicklung kommen zur Gebühr der Commerce-Plattform hinzu.

Ist Headless Commerce das Richtige für dich? Eine Entscheidungsliste

Nutze das als schnellen Check. Trifft das meiste aus der ersten Liste zu, lohnt sich ein ernsthafter Blick auf Headless. Trifft das meiste aus der zweiten Liste zu, ist ein gut gebautes Theme wahrscheinlich die bessere Investition.

Anzeichen, dass sich Headless lohnt

• Du verkaufst über mehr als ein Frontend (Web plus App, Kioske oder mehrere Länderseiten), die einen gemeinsamen Katalog und Checkout nutzen sollen.
• Dein Theme blockiert tatsächlich umsatzrelevante Erlebnisse, etwa Produktkonfiguratoren, redaktionelles Shopping oder individuelle Bundles.
• Du hast ein internes Frontend-Team oder eine langfristige Agenturbetreuung, oder du kannst eines davon finanzieren.
• Die Ladegeschwindigkeit ist ein gemessenes Problem, das Theme-Optimierung nicht gelöst hat.
• Deine Produktdaten sind bereits strukturiert: typisierte Attribute, saubere Varianten, Übersetzungen und Bilder pro Kanal.

Anzeichen, dass es sich nicht lohnt

• Dein Team ändert den Shop meist über den Theme-Editor und hat keinen Entwickler auf Abruf.
• Umsatzprobleme kommen von Traffic, Sortiment oder Produktinhalten, nicht von der Storefront-Technik.
• Du betreibst einen Shop in einer Sprache, und das Theme tut, was du brauchst.
• Dein Katalog hat noch Lücken: fehlende Attribute, einzeilige Beschreibungen, uneinheitliche Einheiten. Ein neues Frontend zeigt diese Lücken deutlicher, statt sie zu verstecken.

Was Headless für deine Produktdaten ändert

Das ist der Teil, den die meisten Guides weglassen. Ein Theme verzeiht viel: Ein Händler kann eine Größentabelle ins Beschreibungs-HTML einfügen, das Material in den Titel schreiben und per Theme-Einstellung ein Badge ergänzen. Eine Headless-Storefront rendert Felder. Steht ein Wert nicht in einem Feld, kann das Frontend ihn weder platzieren noch danach filtern noch an den nächsten Head weitergeben.

Nimm wieder die Merinosocken. In einem typischen Theme-Shop sieht das Produkt vielleicht so aus: Titel „Merino socks 3-pack grey/navy/black 43-46 SALE“, eine Beschreibung mit eingefügter HTML-Tabelle für die Größen und das Material einmal im dritten Absatz erwähnt. Eine Headless-Storefront, eine mobile App und ein Marketplace-Feed brauchen alle dasselbe Produkt, aufgeteilt in Felder:

• title: Merino Crew Socks 3-Pack (keine Größe, Farbe oder Aktionstext im Titel)
• short_description: ein oder zwei Sätze für Produktkacheln und App-Screens
• description: schlichter, strukturierter Text, ohne Layout-HTML, das nur in einem Theme funktioniert
• material: 80 % Merinowolle, 18 % Polyamid, 2 % Elasthan (ein typisiertes Attribut, damit die Storefront danach filtern kann)
• pack_size: 3
• Variantenoptionen: Größe (39 bis 42, 43 bis 46) und Farbe (Grau, Navy, Schwarz) als echte Optionen, jede Variante mit eigener SKU, GTIN und eigenem Bestand
• care_instructions: Maschinenwäsche 30 °C, als Attribut, das die Produktseite als Symbolliste darstellen kann
• images: eigene Bilder pro Farbvariante, jedes mit Alt-Text
• seo_title und meta_description: pro Sprache gesetzt, weil der Head sie rendert und es keinen Theme-Fallback gibt
• translations: jedes Feld oben in jeder Storefront-Sprache, denn eine deutsche Länderseite braucht auch deutsche Attributwerte (Wolle statt wool)

Headless vervielfacht außerdem meist die Kanäle, und jeder hat eigene Feldregeln. Der Webshop kann eine Beschreibung mit 1.200 Wörtern zeigen; die App-Kachel zeigt zwei Zeilen; ein Marketplace-Feed hat Längengrenzen für Titel. Die Daten müssen einmal vollständig sein und pro Kanal angepasst werden, und genau dafür gibt es Product Information Management. Manche Teams ergänzen ein Headless PIM, das Produktinhalte per API an jeden Head ausliefert, neben der Commerce-Plattform, die Preise, Bestand und Checkout verwaltet.

Fallen bei der Headless-Migration, vom Redesign-Denken bis zu verlorenem SEO

1. Es als Redesign behandeln. Headless ist ein Architekturwechsel. Plane Budget für den Bau und die Pflege von Software ein, nicht für einen neuen Look.
2. Unordentliche Daten unverändert migrieren. Fakten, die im Beschreibungs-HTML, in Bildtexten oder Titeln steckten, tauchen in der neuen Storefront nicht als Filter oder Spezifikationen auf. Verschiebe sie zuerst in Attribute.
3. SEO-Parität vergessen. URL-Struktur, Weiterleitungen, Canonical-Tags, strukturierte Daten, hreflang und Meta-Felder müssen vor dem Launch neu gebaut und getestet werden. Unser Guide zu Produktseiten-SEO listet die Felder auf, die du pro Seite prüfen solltest.
4. Alles auf einmal launchen. Ein schrittweiser Rollout, zum Beispiel beginnend mit Produktlistenseiten oder einer Länderseite, begrenzt das Risiko.
5. Merchandiser ohne Werkzeuge lassen. Plane ein CMS oder einen Page Builder ein, damit das Content-Team Seiten ohne Entwickler ändern kann.
6. Die Kataloglogik im Frontend nachbauen. Variantenregeln, Übersetzungen und Kanalausnahmen gehören in die Systeme, die die Daten besitzen, nicht fest codiert in Storefront-Komponenten.

Die Produktinformationsebene hinter einer Headless-Storefront

WISEPIM ist eine Produktinformationsebene, keine Storefront und keine Commerce-Engine. In einem Headless-Setup steht es neben deiner Plattform: Es importiert den Katalog, füllt fehlende Attribute, Beschreibungen und Übersetzungen mit AI, prüft die Vollständigkeit mit Quality Guard und überträgt das Ergebnis per Plattform-Sync an Shopify, WooCommerce, Magento 2 und andere verbundene Shops. Die Storefront liest dann saubere, strukturierte Felder aus der API der Plattform. Wenn sich in WISEPIM etwas ändert, überträgt der optionale Auto-Sync das gespeicherte Produkt an den verbundenen Shop, sodass der Head nie auf einen manuellen Export warten muss.

Wenn du ein Headless-Projekt abwägst, fang mit den Daten an: Du kannst deinen Katalog im kostenlosen Plan importieren und sehen, welche Felder fehlen, bevor die Frontend-Arbeit beginnt.