Headless Commerce: Lohnt sich der Aufwand für Ihren Shop?

Wer sich tiefer mit Online-Shop-Technologie befasst, stößt früher oder später auf den Begriff Headless Commerce - und schnell auch auf enthusiastische Agentur-Blogbeiträge, die diesen Ansatz als die Lösung für praktisch jedes E-Commerce-Problem verkaufen. Als jemand, der seit 13 Jahren WordPress- und WooCommerce-Shops für KMU in Deutschland und Polen umsetzt, kann ich sagen: Die Technologie ist real und für bestimmte Szenarien wirklich leistungsstark. Aber der Hype hat deutlich mehr Projekte in die Irre geführt, als er geholfen hat.

In diesem Beitrag erkläre ich, was Headless Commerce konkret bedeutet, wann es echten Mehrwert bringt und - mindestens genauso wichtig - wann es schlicht überdimensioniert ist und nur Kosten verursacht. Ich gehe dabei von realen Projektsituationen aus, nicht von Benchmark-Demos auf Konferenzen.

Was Headless Commerce eigentlich ist

Bei einem klassischen WooCommerce-Shop ist alles in einem System: PHP rendert das Template, füllt es mit Produktdaten aus der Datenbank und schickt fertiges HTML an den Browser. Frontend und Backend sind eng verzahnt. Das hat Vorteile - Plugins greifen direkt in Templates ein, Checkout und Produktseiten funktionieren ohne zusätzliche Schichten.

Headless Commerce trennt dieses Konstrukt radikal auf. Das Backend - in unserem Fall typischerweise WooCommerce oder Shopware - kümmert sich ausschließlich um Produktdaten, Bestände, Bestellungen und Preislogik. Es gibt kein eigenes Frontend mehr, nur eine API (REST oder GraphQL), über die diese Daten abgerufen werden. Das Frontend ist ein separates Projekt, meist mit React- oder Vue.js-Frameworks wie Next.js oder Nuxt.js gebaut, das diese Daten über die API holt und selbst rendert.

Der Begriff kommt daher, dass dem System buchstäblich der Kopf fehlt: die Darstellungsschicht ist abgetrennt.

Die Zahlen hinter dem Markt

Headless Commerce ist kein Nischenthema mehr. Der globale Markt erreichte 2025 einen Wert von 1,74 Milliarden US-Dollar und wächst laut Branchenanalysen mit einer jährlichen Rate von 22,4 Prozent - schneller als der E-Commerce-Markt insgesamt. Bis 2032 werden über 7 Milliarden US-Dollar Marktvolumen erwartet.

Noch aufschlussreicher sind Adoptionszahlen: 73 Prozent der Unternehmen, die 2025 neu in headless-ähnliche Architekturen investierten, berichten von messbaren Performance-Verbesserungen. Dokumentierte Case Studies zeigen 20-50 Prozent kürzere Ladezeiten und in einigen Fällen 42 Prozent höhere Conversion Rates nach der Migration. Diese Zahlen kommen jedoch fast ausnahmslos aus Enterprise-Kontexten, bei denen das alte System tatsächlich ein Bottleneck war.

Wichtig ist bei diesen Zahlen die Einordnung: Sie stammen aus Projekten mit vorherigen, ernsthaften Performance-Problemen. Ein WooCommerce-Shop, der bereits gut läuft, wird diese Gains nicht automatisch erzielen.

Wann Headless Commerce Sinn ergibt

Nach über 120 Projekten in unterschiedlichen Branchen und Größenordnungen kann ich drei Situationen klar benennen, in denen ein headless Ansatz berechtigt ist.

Situation 1: Messbarer Performance-Bottleneck mit hohem Traffic. Wenn die Produktseiten eines Shops mit 50.000+ monatlichen Besuchern nachweislich schlechte Core Web Vitals haben und alle Caching-Optimierungen ausgereizt sind, kann ein statisch gerendertes Next.js-Frontend den Unterschied machen. Static Site Generation (SSG) liefert HTML direkt vom CDN-Edge-Node - da ist PHP schlicht physikalisch nicht schneller.

Bei einem Kunden aus dem Bereich Sportequipment hatten wir genau diese Situation: 80.000 Besucher pro Monat, LCP auf Mobile bei 4,2 Sekunden trotz LiteSpeed-Caching und optimierter Bilder. Nach Migration der Produktseiten auf ein Next.js-Frontend mit WooCommerce-Backend fiel der LCP auf 1,1 Sekunden. Die Abbruchrate im Checkout sank um 18 Prozent innerhalb von 8 Wochen.

Situation 2: Multi-Channel mit einem einzigen Backend. Wer denselben Produktkatalog auf einer Webseite, in einer mobilen App, auf Kioskterminals in Filialen oder in B2B-Portalen ausspielen will, profitiert enorm von einer sauberen API-Schicht. Das Backend wird einmal gepflegt, jeder Kanal konsumiert die Daten nach eigenen Bedürfnissen. Das ist ein starkes Argument.

Situation 3: Hochindividuelles Design, das kein Theme abbilden kann. Manchmal kommt ein Kunde mit einem Figma-Entwurf, der schlicht mit keinem Page-Builder und keinem Theme umsetzbar ist - zu spezielle Animationen, zu komplexe Produktkonfiguratoren, zu eigenständige Navigation. In solchen Fällen ist ein React-Frontend ohnehin der pragmatischste Weg, und headless ergibt sich fast von selbst.

Die echten Kosten - was die Hype-Artikel verschweigen

Hier wird es konkret, und hier weichen viele Beiträge von der Realität ab. Wer headless mit WooCommerce oder Shopware aufbaut, rechnet zunächst: Backend ist WooCommerce (kostenlos), Frontend ist Next.js (Open Source), WPGraphQL ist kostenlos. Klingt günstig.

Die tatsächlichen Kosten entstehen woanders.

Erstens die Entwicklungszeit: Eine produktionsreife headless WooCommerce-Implementierung mit Next.js, vollständigem Checkout-Flow, Warenkorb-State-Management, Sprachversionen und Zahlungsanbindung (Stripe, Klarna) braucht bei einem erfahrenen Team aus zwei Entwicklern realistisch 8-12 Wochen. Bei Agentur-Tagessätzen von 800-1.200 Euro (Deutschland) bedeutet das 30.000-50.000 Euro. Günstigere Angebote unter 12.000 Euro erkaufen sich die Einsparung fast immer durch fehlende Funktionen oder mangelnde Wartbarkeit.

Zweitens Plugin-Kompatibilität: Genau hier brennt es in der Praxis am häufigsten. WooCommerce Germanized, das für den deutschen Markt quasi unverzichtbar ist, rendert seine Pflichthinweise über PHP-Filter in WooCommerce-Templates. Im headless Setup gibt es diese Templates nicht. Jeder Pflichttext, jedes Widerrufsrecht, jede Preisauszeichnung nach PAngV muss manuell im React-Frontend implementiert werden. Das gilt genauso für Klarna, für dynamische Versandberechnungen, für Produktkonfiguratoren auf Plugin-Basis.

Bei einem Projekt mit einem Hamburger Modeversand haben wir unterschätzt, wie viele kleine Plugin-Hooks im klassischen Checkout steckten - 14 separate Plugins griffen in den Bestellprozess ein. Jedes einzelne musste entweder per API nachgebildet oder durch eine Custom-Lösung ersetzt werden. Das hat das Projekt um 6 Wochen verlängert.

Drittens laufende Infrastrukturkosten: Ein klassischer WooCommerce-Shop läuft auf einem VPS für 20-50 Euro pro Monat. Im headless Setup brauchen Sie den WooCommerce-VPS (80-150 Euro, weil er als API-Server stabil und schnell sein muss) plus Hosting für das Next.js-Frontend - entweder Vercel (ab 20 Euro pro Monat im Pro-Plan, bei hohem Traffic deutlich mehr) oder ein eigener Node.js-Server.

Viertens Wartungsaufwand: Zwei separate Systeme mit zwei separaten Deployment-Pipelines müssen aktuell gehalten werden. Next.js released mehrfach pro Jahr Breaking Changes. WooCommerce-Major-Updates können API-Endpunkte verändern. Dieser Overhead ist nicht zu unterschätzen - ich schätze 30-50 Prozent höheren Wartungsaufwand gegenüber einer klassischen WooCommerce-Installation.

Wenn klassisches WooCommerce die klügere Wahl ist

Für die überwiegende Mehrheit der KMU-Shops im deutschen Markt ist ein gut optimiertes klassisches WooCommerce-Setup die bessere Wahl. "Gut optimiert" bedeutet konkret: LiteSpeed- oder Nginx-Server mit Redis-Objektcaching, optimiertes Theme (Blocksy, Kadence oder ein schlankes Custom-Theme), Bild-Kompression mit WebP-Ausgabe, wenige, sorgfältig ausgewählte Plugins, und Cloudflare als vorgeschaltetes CDN.

Ein solches Setup erreicht auf vielen Produktseiten Lighthouse-Scores zwischen 85 und 95. Das ist Performance-technisch ausreichend für die allermeisten Shops, und die Conversion-Kurve macht bei diesen Werten selten einen dramatischen Sprung.

Für Shops mit unter 500.000 Euro Jahresumsatz, Standard-Katalog und einer Person oder kleinen Agentur als technischen Partner ist das fast immer der richtige Weg. Wenn Sie einen WooCommerce-Onlineshop aufbauen, sollten Sie zuerst alle Performance-Hebel im klassischen Setup ausschöpfen, bevor headless überhaupt auf die Agenda kommt.

Das technische Fundament: WPGraphQL vs. REST API

Wer sich für headless entscheidet, steht vor der Wahl der API-Schicht. WooCommerce bringt eine vollständige REST API mit, die ohne zusätzliche Plugins funktioniert. WPGraphQL ist ein Canonical-Plugin auf wordpress.org (seit Oktober 2024 offiziell von Automattic gesponsert) und ermöglicht GraphQL-Abfragen, die genau die Felder zurückgeben, die das Frontend braucht - kein Over-Fetching.

Die pragmatische Antwort: Nutzen Sie beide. GraphQL eignet sich hervorragend für lesende Abfragen - Produktseiten, Kategorielisten, Suchindizes. REST eignet sich besser für schreibende Operationen - Warenkorb-Manipulation, Checkout, Bestellstatus-Updates. CoCart ist eine ergänzende Open-Source-Lösung, die eine vollständige REST API speziell für headless Warenkörbe bietet und in diesem Bereich Lücken der nativen WooCommerce REST API schließt.

Für die Produktsuche empfehle ich bei größeren Katalogen frühzeitig den Einsatz eines dedizierten Suchservices - Algolia oder Typesense - der unabhängig vom WordPress-Backend operiert. Das entlastet den Datenbankserver erheblich.

Der hybride Mittelweg

Zwischen "alles klassisch" und "vollständig headless" gibt es einen Bereich, der für viele KMU-Shops im deutschen Markt den besten Trade-off bietet: die Hybridlösung.

Die Idee: WooCommerce bleibt vollständig als Backend und Storefront, inklusive Theme, Checkout und aller Plugins. Nur ausgewählte Bereiche werden entkoppelt. Zum Beispiel:

• Das Magazin oder der Ratgeber-Bereich wird über ein Headless CMS wie Storyblok verwaltet und als statisch gebaute Seiten ausgeliefert. Storyblok bietet einen integrierten Visual Editor und kostet im Team-Plan ab 99 Euro pro Monat.
• Landingpages für Kampagnen werden als Next.js-Seiten gebaut und per CDN ausgeliefert, während der eigentliche Checkout im WooCommerce-Kontext bleibt.
• Die Startseite nutzt manuell gecachte API-Daten für Produktkarussells, die der Kunde selbst konfiguriert.

Diese Hybridarchitektur bringt 70-80 Prozent der Performance-Vorteile von vollständig headless bei deutlich geringerem initialen Aufwand. Das Checkout-Risiko - der kritischste und fehleranfälligste Teil - bleibt im bewährten WooCommerce-Kontext.

Falls Sie ohnehin überlegen, das Shopsystem zu wechseln oder zwischen Open-Source und SaaS-Lösungen abzuwägen, ist der headless Aspekt eine Dimension, die in diese Überlegung einfließen sollte.

Plattform-Alternativen jenseits von WooCommerce

Wer ernsthaft in Headless Commerce investiert, sollte auch prüfen, ob WooCommerce die optimale Backend-Wahl ist.

Shopware 6 ist von Grund auf API-first designed und unterstützt headless offiziell über die Store API. Die Headless-Dokumentation ist umfangreicher, die Entwickler-Community im DACH-Raum kennt diese Architektur gut. Shopware Community Edition ist kostenlos, ab dem Rise-Tier (früher Professional) liegt die Lizenz bei 600 Euro pro Monat - das setzt einen entsprechenden Umsatz voraus.

Commercials wie commercetools (ein deutsches Unternehmen aus München) oder Fabric sind reine Headless-Commerce-Backends ohne eigenes Frontend. Die Preise sind nicht öffentlich, bewegen sich aber im Bereich sechsstelliger Jahresverträge - das ist Enterprise-Territory, für KMU nicht relevant.

BigCommerce bietet seit August 2024 offiziell eine Composable-Commerce-Strategie. Die Preise beginnen bei 29 Dollar pro Monat für Standard, werden aber für ernsthafte Headless-Projekte schnell höher.

Für deutsche Shops mit Germanisierungs-Anforderungen (TDDDG, PAngV, Widerrufsrecht, E-Rechnung seit 01.01.2025) bleibt WooCommerce + Germanized + WPGraphQL eine der pragmatischsten Ausgangsbasis für headless - vorausgesetzt, das Team kennt beide Welten. Ich bin Webentwickler, kein Anwalt: Bei Fragen zur konkreten rechtlichen Umsetzung der deutschen E-Commerce-Anforderungen sollten Sie einen Fachanwalt hinzuziehen.

Realistische Umsatzgrenzen und Entscheidungsrahmen

Ich arbeite mit einer einfachen Daumenregel, die sich über viele Projekte bewährt hat:

Unter 300.000 Euro Jahresumsatz: Optimiertes klassisches WooCommerce. Investieren Sie das Headless-Budget lieber in Inhalte, SEO und Conversion-Optimierung.

300.000 bis 1 Million Euro: Hybridlösung prüfen. Wenn konkrete Performance-Probleme messbar sind, selektives headless für Landingpages und Content-Bereiche.

Über 1 Million Euro mit messbaren Conversion-Verlusten durch Ladezeiten: Vollständiges Headless-Projekt mit dediziertem Entwicklungsteam ist berechtigt. Planen Sie 6-12 Monate Projektlaufzeit und ein initiales Budget von mindestens 25.000-50.000 Euro.

Diese Grenzen sind keine festen Regeln, sondern Orientierungspunkte. Ein Nischen-Shop mit sehr hohen Warenwerten und 80.000 Euro Jahresumsatz kann trotzdem headless-berechtigt sein, wenn der Traffic hoch genug ist und die Conversion-Rate den Unterschied macht.

Für den deutschen Online-Shop-Markt gilt zudem: Die meisten KMU-Betreiber arbeiten lieber mit einem einzigen Ansprechpartner, der sowohl das Backend als auch das Frontend versteht. Der organisatorische Overhead, zwei Entwicklungsstacks parallel zu managen, ist nicht zu unterschätzen.

Was die meisten Guides falsch machen

Ein Punkt, den ich immer wieder in headless-Beiträgen vermisse: Die Frage der organisatorischen Reife. Headless Commerce ist nicht nur eine technische Architekturentscheidung, sondern verändert wie ein Team arbeitet.

Bei einem klassischen WooCommerce-Shop kann ein Marketingmitarbeiter mit etwas Einweisung Produkte anlegen, Preise anpassen, Banner tauschen. Bei einer vollständig entkoppelten headless Architektur ist jede Content-Änderung, die das Frontend betrifft, eine Deployment-Operation. Entweder gibt es ein Headless CMS (Storyblok, Contentful, Sanity) als visuelle Content-Schnittstelle, oder der Content-Workflow wird deutlich technischer.

Zweitens wird die Testpflicht unterschätzt. Bei einem monolithischen System testet man nach einem Plugin-Update die Kernfunktionen manuell und rollt bei Problemen zurück. Im headless Setup gibt es zwei unabhängige Deployments, mehrere API-Versionen und den möglichen Drift zwischen Backend-Änderungen und Frontend-Erwartungen. Automatisierte End-to-End-Tests (Playwright, Cypress) sind hier keine Kür, sondern Pflicht.

Drittens ist SEO im headless Kontext nicht automatisch besser. Suchmaschinen können JavaScript-gerenderte Inhalte grundsätzlich crawlen, aber die bevorzugte Methode bleibt Server-Side Rendering oder Static Site Generation. Falsch konfiguriertes Client-Side Rendering kann die Indexierung verschlechtern. Diese Fallstricke zu vermeiden, erfordert Next.js-Kenntnisse und eine sorgfältige Rendering-Strategie. Im Kontext von SEO-Optimierung darf das headless Rendering nie ein nachträglicher Gedanke sein.

Meine Empfehlung

Headless Commerce ist eine ausgereifte, produktionsreife Architektur mit echten Vorteilen - in den richtigen Händen, für die richtigen Projekte. Es ist nicht mehr Hype, aber auch nicht die Universallösung, als die es manchmal vermarktet wird.

Wenn Sie einen wachsenden Shop mit messbaren Performance-Problemen, einem erfahrenen Entwicklungsteam und dem Budget für eine ernsthafte Investition betreiben: Ja, evaluieren Sie headless ernsthaft. Beginnen Sie dabei mit einem Proof of Concept für eine einzelne Produktkategorie, bevor Sie den gesamten Shop migrieren.

Wenn Sie einen funktionierenden Shop mit Standard-Anforderungen betreiben und überlegen, ob Headless das nächste Upgrade sein sollte: Nein. Investieren Sie das Geld in Content, SEO, bessere Produktfotos und strukturierte Daten. Das bringt messbar mehr zurück.

Die ehrliche Frage ist nicht "Ist Headless Commerce gut?", sondern "Löst Headless Commerce das konkrete Problem, das mein Shop gerade hat?" Wenn die Antwort unklar ist, ist die Antwort meistens nein. Ich bespreche solche Architekturentscheidungen gerne konkret - ohne Agentur-Pitch, ohne vorab festgelegte Empfehlung. Sprechen Sie mich über /de/kontakt/ an.

Häufige Fragen

Was bedeutet Headless Commerce genau?

Bei Headless Commerce ist das Frontend (die Darstellungsschicht, die der Kunde sieht) vollständig vom Backend (Produktdaten, Warenkorb, Bestelllogik) getrennt. Beide Seiten kommunizieren ausschließlich über eine API. Das Frontend wird meist mit React-Frameworks wie Next.js oder Nuxt.js gebaut, das Backend kann WooCommerce, Shopware oder ein spezialisierter Headless-Commerce-Dienst sein. Der Name kommt daher, dass dem System der 'Kopf' - die HTML-Ausgabe - fehlt.

Wie viel kostet ein headless WooCommerce-Shop?

Eine produktionsreife headless WooCommerce-Lösung mit Next.js-Frontend kostet in der Entwicklung realistisch zwischen 12.000 und 25.000 Euro, je nach Komplexität des Katalogs und der Checkout-Logik. Hinzu kommen laufende Kosten von 150-300 Euro pro Monat für Hosting (VPS für WooCommerce plus CDN/Vercel für das Frontend). Einfache Plugin-Integrationen, die im klassischen WooCommerce ein paar hundert Euro kosten, können im headless Setup tausende Euro an Eigenentwicklung erfordern.

Welche Shops profitieren wirklich von Headless Commerce?

Am meisten profitieren Shops mit hohem Traffic und messbaren Core-Web-Vitals-Problemen, Multi-Channel-Anbieter die denselben Katalog auf Web, App und Kiosk ausspielen müssen, Shops mit sehr individuellem Design-Anspruch der in keinen Standard-Theme passt, und Unternehmen mit vorhandenen PIM- oder ERP-Systemen, die sauber per API angebunden werden müssen. Für einen Standard-Shop mit 200-500 Produkten und solidem Theme ist klassisches WooCommerce klar effizienter.

Funktionieren WooCommerce-Plugins im headless Setup?

Die meisten Standard-WooCommerce-Plugins funktionieren im headless Setup nicht automatisch, weil sie PHP-Templates ausgeben, die im entkoppelten Frontend nicht gerendert werden. Germanized, Klarna, Stripe und ähnliche Plugins müssen über ihre jeweilige API oder einen eigenen Checkout-Prozess eingebunden werden. Das ist machbar, erfordert aber Entwicklungsaufwand und muss bei Plugin-Updates stets auf Kompatibilität geprüft werden.

Ist WPGraphQL oder die WooCommerce REST API besser für headless?

Beide Ansätze haben ihre Daseinsberechtigung. WPGraphQL (inzwischen ein offizielles Canonical Plugin auf wordpress.org, gesponsert von Automattic) ermöglicht präzise Datenabfragen in einem einzigen Request und ist ideal für komplexe Produktseiten. Die WooCommerce REST API ist einfacher zu debuggen und ohne Plugin-Abhängigkeit direkt verfügbar. Viele produktionsreife Projekte nutzen GraphQL für Lesevorgänge (Produkte, Kategorien, Content) und REST für Schreibvorgänge (Warenkorb, Checkout, Bestellungen).

Was ist der Unterschied zwischen Headless und Composable Commerce?

Headless Commerce ist das technische Prinzip der Trennung von Frontend und Backend. Composable Commerce ist die strategische Weiterentwicklung: Statt nur Frontend und Backend zu trennen, werden alle Commerce-Fähigkeiten (Suche, Zahlungen, Reviews, Loyalität) in separate Best-of-Breed-Dienste aufgespalten, die per API zusammengesteckt werden. Composable Commerce ist mächtiger, aber auch deutlich komplexer und teurer - das ist eher Enterprise-Terrain, kein KMU-Thema.

Kann ich mit Shopware headless arbeiten?

Shopware 6 ist von Grund auf API-first konzipiert und unterstützt headless offiziell über die Store API. Viele Agenturen im DACH-Raum nutzen Shopware als Commerce-Backend mit einem entkoppelten Vue.js- oder Next.js-Frontend. Das macht mehr Sinn als WooCommerce headless, weil Shopware das Headless-Szenario aktiv fördert und die API vollständiger ist. Für kleinere Shops unter 100.000 Euro Jahresumsatz ist jedoch auch Shopware headless überdimensioniert.

Was ist eine sinnvolle Alternative zu vollständigem Headless für kleinere Shops?

Eine Hybridlösung ist oft der beste Mittelweg: WooCommerce bleibt das vollständige Backend inklusive Theme, aber einzelne Bereiche werden entkoppelt - zum Beispiel das Magazin/Blog über ein Headless CMS wie Storyblok, oder die Startseite als statisch gebaute Seite per Elementor mit manuell gecachten API-Daten. Damit lassen sich 70-80 Prozent der Headless-Vorteile bei 30-40 Prozent des Aufwands erreichen. Zudem bringt ein professionell konfiguriertes Caching (LiteSpeed, Redis) auf klassischem WooCommerce oft mehr messbare Performance als ein teures headless Projekt.