Headless Commerce erklärt: Mehr Flexibilität für moderne Online-Shops

Was bedeutet Headless Commerce?

Bei einem klassischen Shopsystem sind Oberfläche und Shop-Logik ein untrennbares Paket: Dasselbe System, das Produkte, Warenkorb und Bestellungen verwaltet, rendert auch die Seiten, die Ihre Kunden sehen. Headless Commerce trennt diese beiden Welten. Das Backend mit Produktdaten, Preisen, Warenkorb und Checkout-Logik bleibt beim Shopsystem; das Frontend, also der „Kopf“, wird als eigenständige Anwendung entwickelt und spricht über Schnittstellen (APIs) mit dem Backend.

Die Analogie: Der klassische Shop ist ein Haus mit fest eingebauter Fassade. Headless ist ein Haus, bei dem Statik und Haustechnik stehen bleiben, die Fassade aber frei gestaltet und jederzeit ausgetauscht werden kann, ohne die Leitungen anzufassen.

Headless Commerce ist eine Shop-Architektur, bei der das Frontend (die für Kunden sichtbare Oberfläche) vom Commerce-Backend (Produkte, Warenkorb, Checkout, Bestellungen) getrennt ist und beide ausschließlich über Schnittstellen miteinander sprechen. Das Backend bleibt ein etabliertes Shopsystem wie Shopify oder Shopware 6, das Frontend wird als eigenständige Web-Anwendung entwickelt, meist mit Frameworks wie Next.js. Der Begriff „headless“ bezeichnet ein System ohne eigenen „Kopf“, also ohne fest eingebaute Präsentationsschicht; dasselbe Prinzip gibt es bei Content-Systemen als Headless CMS.

Wo der klassische Shop an Grenzen stößt

Für die meisten Shops funktioniert das klassische Modell hervorragend, deshalb gleich vorweg: Headless ist kein Qualitätsmerkmal, sondern eine Architekturentscheidung. Eng wird es im Monolithen typischerweise an drei Stellen: bei der Performance, wenn Theme, Apps und Tracking-Skripte die Ladezeit aufblähen; bei der Individualisierung, wenn Design- oder Checkout-Wünsche gegen die Grenzen des Template-Systems laufen; und bei Multichannel-Strategien, wenn dieselben Produktdaten Website, App, Marktplätze und Instore-Displays bedienen sollen. Ein direkter Vergleich der klassischen Systeme steht in unserem Beitrag Shopify vs. WooCommerce.

Der technische Aufbau im Detail

Ein typischer Headless-Stack besteht aus drei Bausteinen:

• Commerce-Backend: übernimmt weiterhin Produktverwaltung, Preise, Warenkorb, Zahlungen und Bestellungen. In der Praxis sind das meist die APIs etablierter Systeme, etwa Shopifys Storefront-API oder die Store-API von Shopware 6, sodass Händler ihr gewohntes Admin-Panel behalten.
• Frontend: eine eigenständige Web-Anwendung, mit modernen Frameworks wie Next.js oder React umgesetzt, die Inhalte serverseitig rendert und dadurch sehr schnell ausliefert.
• Content-System (optional): ein Headless CMS wie Sanity oder Strapi für redaktionelle Inhalte wie Ratgeber, Markenseiten oder Kampagnen, die im Frontend mit den Produktdaten zusammenlaufen.

Der Kern: Jeder Baustein ist austauschbar. Wächst der Shop aus Shopify heraus, wird das Backend gewechselt, das Frontend samt Design, SEO-Substanz und Conversion-Optimierung bleibt stehen.

Die Vorteile und was sie konkret bedeuten

• Maximale Designfreiheit: Keine Theme-Grenzen, kein Template-Korsett, das Einkaufserlebnis wird exakt so gebaut, wie Marke und Conversion es verlangen.
• Performance: Serverseitig gerenderte, schlanke Frontends erreichen Ladezeiten, die mit App-beladenen Monolith-Themes kaum machbar sind. Warum das direkt auf Rankings und Conversion einzahlt, erklärt unser Beitrag zu Core Web Vitals.
• SEO-Substanz: Volle Kontrolle über URLs, strukturierte Daten, Rendering und interne Verlinkung, Stellschrauben, an die man in gehosteten Systemen teils nicht herankommt.
• Multichannel: Website, native App, Marktplatz-Feeds und POS-Systeme greifen auf dieselben APIs zu, ein Datenbestand, viele Touchpoints.
• Skalierbarkeit: Frontend und Backend skalieren unabhängig; Lastspitzen im Shop-Frontend berühren die Bestandssysteme nicht.

Die ehrlichen Nachteile

Headless hat einen Preis, und der besteht nicht nur aus Geld. Erstens: Zwei Systeme statt einem. Frontend und Backend werden getrennt entwickelt, deployt und gewartet. Ohne technisches Team oder betreuende Agentur ist das nicht seriös zu betreiben. Zweitens: Das App-Ökosystem greift nur noch teilweise. Viele Shop-Apps entfalten ihre Wirkung im Theme des Anbieters; im eigenen Frontend muss dieselbe Funktion entwickelt oder per API angebunden werden. Drittens: Redaktionelle Arbeit ändert sich. Marketing-Teams pflegen Inhalte nicht mehr im Shop-Theme, sondern im CMS. Das ist nach der Umgewöhnung oft besser, aber es ist eine Umstellung, die eingeplant werden will.

Was kostet Headless Commerce?

Headless-Projekte beginnen realistisch ab etwa 12.000 € und reichen je nach Umfang bis 40.000 € und darüber, deutlich mehr als ein Theme-basierter Shop, der ab rund 4.000 € machbar ist. Dazu kommen laufende Kosten für Hosting des Frontends, das Commerce-Backend und die Weiterentwicklung. Die vollständige Kostenlogik für Shop-Projekte, inklusive der laufenden Posten, die Angebote gern verschweigen, schlüsselt unser Leitfaden Online-Shop erstellen lassen: Kosten auf. Die Investition rechnet sich dann, wenn Performance, Individualität oder Multichannel-Fähigkeit messbar Umsatz bringen, nicht weil die Architektur moderner klingt.

Für wen lohnt sich Headless und für wen nicht?

Headless Commerce lohnt sich typischerweise für:

• Marken mit hohem Designanspruch, deren Erlebnis im Theme-Korsett nicht abbildbar ist
• internationale Shops mit mehreren Märkten und Touchpoints
• Unternehmen mit individuellen Checkout- oder Produktlogiken
• content-getriebene Strategien, bei denen Ratgeber und Shop verschmelzen sollen

Der klassische Shop bleibt die bessere Wahl für:

• überschaubare Sortimente mit Standard-Kaufprozess
• Teams ohne technische Betreuung
• Budgets unter etwa 10.000 €, hier liefert ein gut umgesetzter Theme-basierter Shop schlicht mehr Gegenwert
• Projekte, bei denen Time-to-Market vor Perfektion geht

Häufig ist auch der Mittelweg sinnvoll: erst mit Shopify oder Shopware klassisch starten, Traktion beweisen, und das Frontend später entkoppeln, wenn das Wachstum die Investition trägt. Genau diese Reihenfolge schützt davor, Architektur für ein Geschäftsmodell zu bauen, das es noch nicht gibt.

Headless Shopsysteme im Vergleich: Welche Backends infrage kommen

„Headless Shopsystem“ ist streng genommen ein Backend, das seine Funktionen vollständig über Schnittstellen bereitstellt. In der Praxis unterscheiden sich die Kandidaten weniger in der Frage, ob das geht, als darin, wie viel Ökosystem, Hosting und Eigenbetrieb dazugehören.

• Shopify: Die Storefront-API deckt Produkte, Warenkorb und Checkout ab; mit Hydrogen liefert Shopify ein eigenes React-Framework samt Hosting (Oxygen). Für Händler die geringste Betriebslast, weil das Backend vollständig gehostet bleibt. Grenzen liegen bei tiefen Eingriffen in den Checkout, die je nach Tarif eingeschränkt sind.
• Shopware 6: Die Store-API ist von Grund auf für entkoppelte Frontends gebaut, Shopware selbst stellt mit „Shopware Frontends“ eine Nuxt-basierte Referenz bereit. Stärke: B2B-Funktionen, Regelwerke und Preislogik, die sich über die API steuern lassen. Voraussetzung ist ein Hosting für das Backend, entweder selbst betrieben oder als Cloud-Variante.
• WooCommerce: Über die REST-API und GraphQL-Erweiterungen technisch möglich, aber das System ist als Plugin in WordPress gewachsen und nicht API-first. Für kleine Sortimente mit starkem Content-Anteil tragfähig, für komplexe Kaufprozesse selten die erste Wahl.
• API-first-Systeme (commercetools, Medusa, Saleor): Von Anfang an ohne eigenes Frontend gedacht. commercetools zielt auf Konzernbudgets, Medusa und Saleor sind Open Source und für Teams interessant, die das Backend ohnehin selbst betreiben wollen. Der Preis ist ein deutlich höherer Anteil an Eigenentwicklung, weil kein App-Ökosystem mitkommt.

Shopware headless: Was mit Shopware 6 konkret möglich ist

Shopware 6 wird in Deutschland am häufigsten für Headless-Projekte angefragt, weil viele Händler das Backend bereits betreiben. Der Wechsel ist dann kein Neuaufbau: Produkte, Kunden, Bestellungen, Regeln und Erweiterungen bleiben im Admin, das Storefront-Theme wird durch ein eigenes Frontend ersetzt, das über die Store-API liest und schreibt. Aufpassen muss man bei Plugins, die Funktionen ins Twig-Theme einhängen: Die müssen im neuen Frontend nachgebaut oder per API angebunden werden. Bei der Planung lohnt deshalb zuerst eine Liste aller installierten Erweiterungen mit der Frage, welche davon nur das Theme betreffen. Wie wir Shopware-Projekte generell aufsetzen, steht auf unserer Seite zur Shopware-Agentur.

Headless Commerce Beratung und Entwicklung: Was ein Projekt braucht

Ein Headless-Projekt scheitert selten an der Technik, häufiger an einer übersprungenen Vorentscheidung. Die Beratung vor dem ersten Code klärt vier Punkte: ob Headless für das Geschäftsmodell überhaupt nötig ist (siehe oben), welches Backend bleibt oder kommt, welcher Frontend-Stack zum Team passt und wer den Betrieb zweier Systeme danach verantwortet. Erst mit diesen Antworten lässt sich ein Angebot seriös kalkulieren.

Die Entwicklung selbst läuft in fünf Schritten, die sich bei uns über realistisch acht bis sechzehn Wochen erstrecken:

1. Architektur-Entscheidung: Backend, Frontend-Framework, Content-System, Hosting, Suchlösung. Ergebnis ist ein Blatt, auf dem jeder Baustein und seine Schnittstelle steht.
2. Datenmodell und Schnittstellen: Welche Produktattribute, Preise, Varianten und Kundenlogiken das Frontend braucht, und welche davon die Standard-API liefert. Lücken werden hier sichtbar, nicht im dritten Sprint.
3. Frontend-Aufbau: Produktlisten, Produktseite, Warenkorb, Checkout-Anbindung, Suche, Content-Seiten; serverseitig gerendert, mit Fokus auf Core Web Vitals und strukturierte Daten.
4. Migration und Tests: URL-Weiterleitungen, Tracking, Zahlungsarten, Versandregeln, Bestellstrecke mit echten Testkäufen. Der häufigste Fehler in dieser Phase ist ein Livegang ohne Redirect-Plan.
5. Betrieb: Monitoring, Updates für beide Systeme, klare Zuständigkeit. Ohne diesen Punkt im Angebot ist ein Headless-Projekt nicht vollständig.

Wir entwickeln Headless-Frontends mit Next.js auf Shopify- und Shopware-Backends; die technische Basis dafür beschreibt unsere Seite zur Webentwicklung in München. Ob Ihr Vorhaben diese Architektur rechtfertigt oder ob ein klassischer Shopify-Shop mit sauberem Theme das bessere Ergebnis liefert, klären wir in einem unverbindlichen Erstgespräch; wir sagen es auch, wenn Headless für Sie zu viel ist.

Drei häufige Missverständnisse

„Headless ist automatisch schneller.“ Nein, ein schlecht gebautes Headless-Frontend kann langsamer sein als ein gepflegtes Theme. Die Architektur schafft die Voraussetzung für Top-Performance, garantiert sie aber nicht, die Umsetzungsqualität gibt den Ausschlag. „Headless heißt, den Shop komplett neu zu bauen.“ Ebenfalls nein: Backend, Produktdaten, Bestellhistorie und Admin-Prozesse bleiben bestehen, ausgetauscht wird nur die Präsentationsschicht. „Headless ist nur etwas für Konzerne.“ Die Einstiegshürde ist gesunken: Mit etablierten Storefront-APIs und Frameworks wie Next.js sind Headless-Projekte heute im fünfstelligen Bereich machbar. Konzernbudgets braucht es dafür nicht mehr, wohl aber ein klares Geschäftsmodell, das die Investition trägt.

Häufige Fragen zu Headless Commerce

Ist Headless dasselbe wie Composable Commerce?

Nicht ganz. Headless beschreibt die Trennung von Frontend und Backend. Composable Commerce geht einen Schritt weiter und setzt auch das Backend aus austauschbaren Einzeldiensten zusammen: Suche, Zahlungen, Produktdaten und Warenkorb kommen von verschiedenen Anbietern. Jedes Composable-Setup ist headless, aber ein Headless-Shop mit Shopify oder Shopware als Backend ist noch lange nicht composable, und für die meisten Mittelständler auch nicht sinnvoll.

Brauche ich zusätzlich ein Headless CMS?

Nur, wenn redaktionelle Inhalte eine tragende Rolle spielen: Ratgeber, Markenwelten, Kampagnenseiten, mehrsprachige Landingpages. Für einen Shop, der vor allem Produkte verkauft, reichen die Content-Funktionen des Commerce-Backends oft aus. Ein CMS ist ein drittes System mit eigenem Pflegeaufwand; es sollte eine Antwort auf einen konkreten Bedarf sein, nicht Teil der Standardausstattung.

Kann ich mit Shopify headless gehen, ohne den Shop neu aufzusetzen?

Ja. Produkte, Bestellungen, Kunden und Apps bleiben im bestehenden Shopify-Backend. Neu gebaut wird nur das Frontend, das über die Storefront-API auf diese Daten zugreift. Der Checkout selbst bleibt bei Shopify, was den Aufwand senkt und PCI-Fragen beim Anbieter belässt.

Was bedeutet „headless“ außerhalb von Online-Shops?

Dasselbe Prinzip auf ein anderes System angewandt: Ein Headless CMS verwaltet Inhalte und liefert sie per API aus, ohne selbst Seiten zu rendern. Wann das für eine Unternehmenswebsite sinnvoll ist und wann klassisches WordPress genügt, vergleichen wir im Beitrag WordPress vs. Headless CMS.

Fazit

Headless Commerce trennt das Frontend eines Online-Shops von der Shop-Logik im Backend; beide kommunizieren über APIs. Das bringt maximale Designfreiheit, sehr gute Ladezeiten, volle SEO-Kontrolle und Multichannel-Fähigkeit, kostet aber mit realistisch 12.000 bis 40.000 € Projektbudget und laufender technischer Betreuung deutlich mehr als ein Theme-basierter Shop. Lohnend ist der Ansatz für wachsende Marken mit hohem Designanspruch, internationalen Ambitionen oder individuellen Kaufprozessen. Für überschaubare Sortimente mit Standard-Checkout bleibt der klassische Shop die wirtschaftlichere Wahl, mit der Option, das Frontend später zu entkoppeln, wenn das Wachstum die Investition rechtfertigt.