Headless Commerce ist keine Zukunftsmusik mehr. Es ist längst Realität in Shops die nicht in Template-Schubladen passen. Aber Achtung: Es ist auch nicht die Lösung für alle Probleme. Wir arbeiten seit Jahren mit Headless-Architekturen und bauen damit anspruchsvolle Commerce-Projekte. Das bedeutet wir kennen auch genau die Fälle in denen Headless die falsche Wahl ist. Hier ist was du wissen musst um die richtige Entscheidung zu treffen.
Inhalt
- Was ist Headless Commerce? Das Prinzip kurz erklärt
- Die Architektur im Detail: Monolith vs. Headless vs. Composable
- Vorteile die wirklich zählen
- Nachteile die du nicht unterschätzen solltest
- Wann lohnt sich Headless wirklich?
- Headless Systeme und Plattformen im Überblick
- Was kostet ein Headless-Projekt?
Was ist Headless Commerce? Das Prinzip kurz erklärt
Headless bedeutet wortwörtlich "kopflos". Der Commerce-Engine der Kopf fehlt. Das klingt merkwürdig, ist aber das perfekte Bild für das Konzept.
Bei einem klassischen monolithischen Shop (Shopware, Shopify, WooCommerce) sind Frontend und Backend fest zusammengespannt. Das Template zeigt die Produkte an, Backend und Frontend sind ein Brocken. Wenn du das Design änderst, änderst du am Shop. Wenn das Template ein Update bekommt, bekommt dein ganzer Shop ein Update. Monolithen sind nicht flexibel. Sie sind stabil, solange der Standard-Use Case passt.
Headless trennt Backend und Frontend komplett auf. Das Backend stellt nur eine API zur Verfügung. Die Commerce-Logik sitzt dort: Produktdaten, Bestand, Preise, Checkout, Payment. Das Frontend kann da drangebaut werden wo es sinnvoll ist. Ein Nuxt.js Shop im Browser. Eine Mobile App. Eine Progressive Web App. Ein Shop im Smartwatch-Browser. Der Commerce-Engine ist egal wie der Frontend aussieht, solange Daten über die API fließen.
Die Brücke zwischen Backend und Frontend ist immer eine API (meist REST oder GraphQL). Das ist das Kernkonzept von Headless: Datentransfer über definierte Schnittstellen, nicht über fest verdrahtete Templates.
Die Architektur im Detail: Monolith vs. Headless vs. Composable
Um Headless richtig einzuordnen ist es hilfreich zu verstehen wie es sich zum klassischen Ansatz und zur noch modulareren Composable Commerce abgrenzt.
Monolith (z.B. Shopware mit Theme, Shopify mit Classic Templates): Ein System, alles drin. Frontend wird über Theme-Logik definiert. Updates können Breaking Changes bringen. Skalierung bedeutet oft den ganzen Stack zu skalieren. Vorteil: einfach zu deployен, weniger Koordination nötig. Nachteil: Flexibilität ist eingebaut, nicht grenzenlos.
Headless (z.B. Shopware Headless mit Nuxt Frontend, Shopify mit Hydrogen, commercetools + Custom Frontend): Backend und Frontend sind zwei separate Systeme. Das Backend (Commerce Engine) spricht nur über APIs. Das Frontend ist eigenständig deploybar, updatebar, skalierbar. Vorteil: maximale Frontend-Freiheit, unabhängige Versionierung. Nachteil: zwei Systeme die orchestriert werden müssen.
Composable Commerce (z.B. commercetools, MACH-Architektur): Das nächste Level der Modularisierung. Backend ist auch nicht mehr ein Block sondern einzelne Microservices. PIM, Pricing, Fulfillment, etc. sind austauschbar. Vorteil: extrem flexibel, du wählst beste-of-breed für jeden Service. Nachteil: hohe Komplexität, braucht ein starkes Tech-Team.
Für diesen Artikel fokussieren wir auf Headless. Composable ist ein anderes Kaliber und sinnvoll nur bei wirklich großen, fragmentierten Anforderungen.
Vorteile die wirklich zählen
Es gibt gute Gründe warum sich Shops aus monolithischen Systemen abkoppeln. Hier sind die die in unseren Projekten den Unterschied machen.
Performance und echte Ladezeiten
Ein Headless Frontend kann auf moderne Frameworks laufen die für Geschwindigkeit gebaut sind. Nuxt.js mit SSR und Hybrid-Rendering, Next.js mit App Router, solide JavaScript-Bundles. Das Backend ist nicht mit Frontend-Code blockiert. Ein API-Response ist schneller als das Rendern einer ganzen Theme-Seite mit mehreren DOM-Manipulationen. Wir sehen typischerweise Ladezeit-Verbesserungen von 30-50% wenn wir klassische Theme-Shops zu Headless migrieren. Das hat echten Business-Impact: jede 100ms Ladezeit-Verbesserung bedeutet messbar höhere Conversion Rates.
Designfreiheit ohne Limits
Templates zwingen dich in ihre Logik. Du willst eine personalisierte Produktseite mit dynamischem Layout je nach Produkttyp? Das wird kompliziert mit einem Theme das auf Standard-Logik aufgebaut ist. Mit Headless baust du genau die Frontend-Logik die du brauchst. Keine Template-Vererbung die dich zwingt irgendwelche Fallbacks zu unterstützen. Kein "das kann das Theme nicht". Designer und Developer haben freie Hand. Das führt zu besseren UX und zu Shops die sich anfühlen wie modern und zielgerichtet.
TCO kann langfristig deutlich niedriger werden
Das ist das stärkste Argument, wird aber oft missverstanden. Eine Headless-Implementierung ist teuer am Anfang (more on that later). Aber über mehrere Jahre kann der TCO niedriger sein als ein klassisches Setup. Warum?
Plattform-Updates sind bei Monolithen radikal. Ein Theme-Update kann Breaking Changes bringen. Dein Frontend kann betroffen sein. Du musst testen, anpassen, mergen. Bei Headless trennt sich das. Das Backend (die Commerce Engine) kann Updates bekommen. Die API-Schnittstellen bleiben stabil. Dein Frontend bleibt unberührt solange die APIs nicht breaking sich ändern. Und wenn sie sich ändern, ist das nur eine beschränkte Änderung, nicht eine komplette Redesign.
Ein weiterer Punkt: Theme-Abhängigkeit. Shopware Themes kosten Lizenzen. Wenn du ein Custom-Theme hast von einem Theme-Hersteller, bist du abhängig von dessen Update-Zyklus. Das Theme bleibt ewig dein Theme, die Plattform marschiert weiter. Mit Headless baust du dein Frontend selbst oder mit einer Agentur die es verwaltet. Kein Theme-Hersteller. Kein Lizenzwirrwarr. Das zahlt sich aus wenn das Projekt 5-10 Jahre läuft.
Unabhängigkeit von Theme-Herstellern
Damit verwandt aber eigenständig wichtig: Du bist nicht in der Abhängigkeit eines Theme-Herstellers der irgendwann aufgibt, deine Theme-Version nicht mehr supported oder zu teuer wird. Mit Headless brauchst du keinen Theme-Hersteller. Der Code ist dein Code, von deiner Agentur oder deinem Team geschrieben. Die Wartbarkeit und der Update-Zyklus liegen bei dir.
Nachteile die du nicht unterschätzen solltest
Kein System ist universell gut. Headless hat echte Nachteile die nicht wegdiskutiert werden können.
Deutlich höhere Initialkosten
Ein Headless-Projekt ist am Anfang teurer. Viel teurer. Du baust nicht auf einem Theme auf, sondern ein vollständiges Frontend von Grund auf. Das bedeutet 4 bis 6 Monate zusätzliche Entwicklung. Das ist eine größere Investition vor dem ersten Sale.
Braucht ein starkes Dev-Team oder eine erfahrene Agentur
Monolithen sind designed um auch mit mittelmäßigen Teams zu funktionieren. Headless nicht. Du brauchst Leute die Frontend-Architektur verstehen, SSR/SSG Rendering-Strategien, API-Integration. Das ist nicht Standard-Skill-Level eines Theme-Customizers.
Mehr Verantwortung für Frontend-Sicherheit
Ein Theme ist getestet und secured. Mit Headless bist du verantwortlich. CORS, API-Keys, XSS-Prävention. Das ist Basis-Hygiene aber nicht optional.
Für Standard-Shops ist es unnötige Komplexität
Das ist die wichtigste Erkenntnis: Die Mehrheit der Shops braucht Headless nicht. Ein Standard E-Commerce Projekt mit Katalog, Produktseite, Cart, Checkout funktioniert bei Shopify oder Shopware hervorragend. Die Designfreiheit existiert (gute Themes sind flexibel), Performance ist gut, TCO ist niedrig.
Headless macht Sinn nur wenn deine Anforderungen über den Standard hinausgehen UND gleichzeitig mehr als 30% Custom im Frontend brauchst.
Wann lohnt sich Headless wirklich?
Das ist die Kernfrage und die Antwort ist nicht emotional sondern rational.
Die wichtigste Entscheidungs-Frage: "Reicht der Standard oder brauch ich Excellence in dieser Domain?"
Das ist pro Bereich unterschiedlich. Content-Domain: Reicht Shopware CMS oder brauch ich Storyblok? Search-Domain: Reicht Shopware-Standard oder brauch ich Algolia? Headless ist nicht automatisch besser. Es ist eine Entscheidung pro Domain.
Headless macht Sinn wenn du...
- Ein eigenes Design brauchst das wirklich nicht in Template-Grenzen passt. Aber "Custom-Design" ist nicht dasselbe wie "Headless braucht". Es ist eine Architektur-Entscheidung WENN mehr als 30% deiner Frontend-Anforderungen Custom sind.
- Multiple Clients brauchst (Web, App, Kiosk). Ein API, mehrere Konsumenten.
- Mit Content und Commerce arbeiten brauchst wo die Trennung echten Nutzen bringt (separate Teams, schnellere Updates).
- Langfristig (5+ Jahre) planst und die Kostenersparnis durch weniger Theme-Updates relevant ist.
Wenn du unter 30% Custom im Frontend brauchst, reicht ein gutes Theme und Standard-Plattform (Shopware oder Shopify). Das ist schneller und günstiger.
Wichtig: Die 30%-Regel ist eine Architektur-Entscheidung, nicht eine Plattform-Wahl. >30% Custom im Frontend = Headless macht Sinn. >30% Custom im Backend = vielleicht Microservices oder spezialisierte Services, aber nicht automatisch andere Plattform.
Headless Systeme und Plattformen im Überblick
Es gibt mehrere Wege um Headless umzusetzen. Jeder mit einer anderen Philosophie.
Shopware Headless
Shopware ermöglicht es vollständig Headless zu fahren. Das Backend ist die Shopware-API, das Frontend ist z.B. Nuxt.js oder Next.js. Das ist bei weitem der häufigste Weg den wir fahren, weil Shopware massiv investiert hat in API-Stabilität und Dokumentation. Die Store API ist solide. Shopware bleibt updatable und wartbar, der Frontend wird komplett zu deinem Projekt.
Wir haben die meisten erfolgreichen Headless-Shopware-Projekte im DACH-Raum umgesetzt. ARMEDANGELS, Fischer Sports, Schöffel fahren auf dieser Architektur und das funktioniert hervorragend.
Shopify Hydrogen
Shopify hat mit Hydrogen ein Framework gebaut das Headless mit Shopify vereinfachen soll. Das ist ein schönes Framework aber hat eine wichtige Limitation: Hydrogen läuft nur auf Shopify. Keine Alternative für die Backend. Das ist für manche Projekte OK, für andere zu inflexibel. Wenn du Shopify willst und nur ein Web-Frontend brauchst ist Hydrogen OK, aber nicht technisch überlegen gegenüber einem Standard-Frontend mit Shopify Storefront API.
commercetools
Commercetools ist ein reiner Commerce-Backend ohne Frontend, kein Themensystem, keine Anbindungen. Das ist die Enterprise-Lösung für wirklich große Systeme. Die API ist extrem mächtig. Der Preis ist es auch. Für kleine bis mittlere Projekte ist das Overkill, aber wenn du mehrere Millionen Bestellungen pro Jahr hast und dein Geschäftsmodell in keinen vorgefertigten Commerce-Stack passt dann ist commercetools das Werkzeug. Die Komplexität rechtfertigt sich durch absolute Flexibilität.
Andere Ansätze: Spree, Medusa, etc.
Es gibt noch andere Open-Source Commerce-Backends. Spree, Medusa, Prestashop API. Diese sind oft günstiger, haben aber auch weniger Ökosystem und weniger etablierte Sicherheit/Performance. Sie sind Optionen für kleinere Projekte oder wenn du wirklich viel Konfiguration machen willst.
Was kostet ein Headless-Projekt?
Ein klassischer Monolith-Shop mit Theme: 30.000+ EUR.
Ein Headless-Shop: 80.000+ EUR.
Dieser Range ist gro, aber begründet sich durch die Komplexität der Projektphasen:
Anfang: Architektierung und Setup. Welche Frontend-Technologie, welche API-Strategie, Hosting, CI/CD. Das dauert 2-3 Wochen und ist bei Headless komplexer weil mehr Variablen.
Phase 2: Frontend-Entwicklung. Das ist der Löwenanteil der Kosten. Du brauchst 2-4 Senior Entwickler für 4-6 Monate um eine solide, performante Storefront zu bauen. Das ist signifikant teurer als ein Theme customizen.
Phase 3: Integration und API-Anpassungen. Payment, Fulfillment, PIM/ERP-Anbindung. Das ist bei Headless nicht simpler weil mehr Schichtenzu koordinieren sind.
Phase 4: Performance-Optimierung. Headless braucht richtige Performance-Optimierung um die Vorteile zu zahlen. SSR/SSG-Strategie, Image Optimization, Caching. Das braucht spezialisiertes Know-how.
Die Faustregel: Ein Headless-Projekt ist 2-3x teurer als ein klassischer Theme-Shop. Dafür bekommst du aber ein System das langfristig günstiger zu halten ist, weil Updates nicht dein Frontend kaputt machen.
Fazit: Headless ist nicht das neue Standard, es ist eine Speziallösung
Headless Commerce ist mächtig und für anspruchsvolle Projekte essentiell. Aber es ist nicht die beste Wahl für alle. Die Entscheidung ist nicht "monolith vs headless" sondern "was sind meine Anforderungen und welche Architektur passt?"
Für 70-80% der E-Commerce Projekte ist ein moderner Monolith (Shopware oder Shopify) immer noch die bessere Wahl. Schneller, günstiger, weniger Komplexität. Für die 20-30% mit wirklich speziellen Anforderungen ist Headless nicht verhandelbar.
Die gute Nachricht: Wir bauen beide. Und wir sagen dir ehrlich welche Lösung für dein Projekt passt.