Headless Commerce: Wann sich die Trennung lohnt

Ob ein Onlineshop eine eigene Oberfläche bekommen soll, ist eine Aufwandsentscheidung, keine Geschmacksfrage. Die Trennung von Storefront und Shop-Logik kostet dauerhaft Personal und Betrieb. Sie zahlt sich nur aus, wenn mehrere Kanäle oder regelmäßige Frontend-Änderungen sie tragen. Dieser Artikel macht die Entscheidung an drei messbaren Größen fest.

Was Headless Commerce bedeutet

Der Begriff beschreibt eine Aufteilung, kein einzelnes Produkt. Die Shop-Logik – Artikel, Preise, Lagerbestand, Warenkorb, Bestellungen und Zahlungen – läuft als eigenständiger Dienst. Die Oberfläche, also der Storefront, ist ein getrenntes Programm, das diesen Dienst über eine Schnittstelle aufruft. Weil die Shop-Logik keine feste Oberfläche mitbringt, heißt sie „headless”.

Dieses Vorgehen nutzt eine Trennung, die das Web selbst kennt. Das W3C unterscheidet in seiner Empfehlung Architecture of the World Wide Web (Fassung vom 15. Dezember 2004) drei Kernbausteine: die Kennzeichnung von Ressourcen, die Darstellung ihres Zustands und die Protokolle, über die Programme mit Ressourcen interagieren. Ein Artikel ist danach eine Ressource in der Shop-Logik; die Produktseite ist eine von mehreren möglichen Darstellungen.

Die Schnittstelle folgt technischen Standards. Eine Storefront-Schnittstelle kann auf HTTP aufsetzen; nach RFC 9110 ist HTTP ein zustandsloses Anwendungsprotokoll für verteilte Systeme. GraphQL ist nach seiner Spezifikation (Ausgabe September 2025) eine Abfragesprache für Schnittstellen, mit der ein Client genau die Felder anfordert, die er braucht. Solche Dokumente sind technische Standards der Fachgremien; sie binden nicht von Gesetzes wegen, sondern weil Produkte und Verträge sie umsetzen.

Der Verband MACH Alliance beschreibt solche Architekturen in seiner aktuellen Fassung als offen, komponierbar und verbunden (Seite abgerufen am 14. Oktober 2026). Verbunden heißt bei ihm API-first: Jede Funktion ist über eine Schnittstelle steuerbar, nicht nur über eine Bedienoberfläche. Ein Whitepaper desselben Verbands (März 2024, am 14. Oktober 2026 geöffnet) führt die vier Prinzipien hinter dem Kürzel MACH auf: Microservices, API-first, Cloud-native SaaS und Headless. Derselbe Verband hält in seinen Definitionen fest, dass MACH eine Teilmenge der komponierbaren Architektur bezeichnet und nicht deckungsgleich mit ihr ist (Global Annual Research Report 2025, Definitions, Seite 7).

Die drei Spielarten

Drei Ausprägungen sind zu unterscheiden. Sie unterscheiden sich darin, was getrennt läuft und wer den Storefront ändert.

Variante	Was getrennt läuft	Wer den Storefront ändert	Grenze
Gekoppeltes System (Monolith)	Nichts: Oberfläche und Logik sind ein System	Änderungen laufen über das Shopsystem; ob sie Vorlagen oder Logik berühren, hängt vom System ab	Ein Kanal; weitere Kanäle teilen sich dasselbe System
Headless	Ein getrennter Storefront vor der Shop-Logik	Ihr Team ändert den Storefront, ohne die Logik anzufassen	Setzt eigene Frontend-Betreuung voraus
Komponierbar	Mehrere Dienste je über eine eigene Schnittstelle	Ihr Team ändert jeden Dienst einzeln	Mehr Integration und Betriebsaufwand als bei headless

Ein gekoppeltes System nennt man auch Monolith: Oberfläche und Logik stecken in derselben Software. Headless und komponierbar sind zwei Stufen derselben Idee. Komponierbar trennt zusätzlich die Dienste untereinander, etwa Shop-Logik, Redaktionssystem und Suche; headless trennt zunächst nur die Oberfläche von der Logik. Das Kürzel MACH steht für eine komponierbare Architektur mit vier Prinzipien (Microservices-basiert, API-first, Cloud-native SaaS und Headless); der Verband MACH Alliance, der den Begriff verwendet, ordnet MACH ausdrücklich als Teilmenge komponierbarer Architektur ein (Global Annual Research Report 2025, Definitions, Seite 7). MACH und komponierbar sind damit nicht dasselbe: Nicht jede komponierbare Architektur ist eine MACH-Architektur, und ob ein Aufbau die vier Prinzipien erfüllt, folgt nicht schon daraus, dass mehrere Dienste getrennt laufen.

Der Entscheidungsbaum

Drei Größen entscheiden über die Trennung. Messen Sie sie, bevor Sie Angebote vergleichen.

Eingang	Wie Sie ihn messen
Teamgröße	Personen, die den Storefront und die Schnittstellen dauerhaft bauen und betreuen können – im eigenen Team oder als fester Dienstleister
Kanalzahl	Verkaufskanäle, die denselben Bestand und dieselben Preise führen (Web, App, Marktplatz, Kasse in der Filiale)
Release-Frequenz	Storefront-Änderungen je Monat, die heute einen Eingriff in die Shop-Logik erfordern

Der Baum fragt die drei Eingänge in dieser Reihenfolge ab.

• Frage 1 – Teamgröße: Können Sie den Storefront dauerhaft bauen und betreuen?
  • Nein: Starten Sie kein Headless-Projekt; prüfen Sie zuerst Shopsoftware mieten oder kaufen.
  • Ja: weiter zu Frage 2.
• Frage 2 – Kanalzahl: Führen drei oder mehr Kanäle denselben Bestand?
  • Ja: Die Trennung lohnt sich; der betreute Storefront lässt alle Kanäle dieselbe Logik über die Schnittstelle nutzen.
  • Nein: weiter zu Frage 3.
• Frage 3 – Release-Frequenz: Berührt mehr als die Hälfte Ihrer Storefront-Änderungen je Monat die Shop-Logik?
  • Ja: Trennung prüfen; der betreute Storefront löst diese Änderungen von der Logik, auch bei einem einzigen Kanal.
  • Nein: Das gekoppelte System genügt; nur der Betriebsaufwand für Schnittstellen und Storefront käme hinzu.

Die Werte drei Kanäle und die halbe Änderungszahl sind redaktionelle Startwerte, keine gemessenen Marktgrenzen. Setzen Sie Ihre eigenen Zahlen ein.

Ein Rechenbeispiel

Beispielrechnung mit erfundenen Zahlen, alle Beträge netto. Angenommen, eine Storefront-Änderung, die die Logik mitberührt, kostet im gekoppelten System drei Arbeitstage, im getrennten Storefront einen Arbeitstag, zu je 900 Euro. Im Monat fallen vier solche Änderungen an.

Posten	Gekoppeltes System	Getrennter Storefront
Arbeitstage je Änderung	3	1
Kosten je Änderung (900 Euro je Tag)	2.700 Euro	900 Euro
Vier Änderungen im Monat	10.800 Euro	3.600 Euro
Aufbau, einmalig	0 Euro	60.000 Euro
Betrieb je Monat	im Shopsystem enthalten	3.000 Euro

Die monatliche Ersparnis aus den Änderungen beträgt 10.800 − 3.600 = 7.200 Euro. Nach Abzug der Betriebskosten bleiben 7.200 − 3.000 = 4.200 Euro im Monat. Der einmalige Aufbau von 60.000 Euro ist damit nach 60.000 ÷ 4.200 = 14,3 Monaten ausgeglichen, also im 15. Monat. Die Rechnung hängt an jeder Annahme: Setzen Sie Ihre Tagessätze, Ihre Änderungszahl und Ihre Betriebskosten ein. Für die Kosten über einen längeren Zeitraum siehe Kostenvergleich über drei Jahre.

Typische Fehler

• Nur auf die Technik schauen. Wer den Storefront trennt, ohne jemanden für den laufenden Betrieb zu benennen, macht aus jeder Änderung ein eigenes Projekt.
• Die Schnittstelle vergessen. Ohne saubere Schnittstellen der Shop-Logik nutzt der getrennte Storefront nichts; siehe Schnittstellen im Shop-Umfeld.
• Einen Kanal überdimensionieren. Bei einem einzigen Kanal fehlt der Kanalvorteil, der Betriebsaufwand bleibt.
• Die Betriebskosten unterschätzen. Hosting, Ausfallsicherheit und Betreuung des Storefronts bleiben dauerhaft beim Händler.
• Den Ausstieg nicht prüfen. Vor der Entscheidung gehören Datenexport und Anbieterbindung und Datenexport auf den Tisch.

So gehen Sie vor

1. Messen Sie einen Monat lang die drei Eingänge: Teamgröße, Kanalzahl und Release-Frequenz.
2. Gehen Sie den Entscheidungsbaum durch, bis ein Ergebnis feststeht.
3. Rechnen Sie Ihre eigenen Werte in das Beispiel ein: Tagessatz, Änderungen je Monat, Betriebskosten.
4. Holen Sie Angebote mit getrennten Posten für Aufbau, Betrieb und Änderung ein; das Vorgehen steht unter Shopsystem auswählen.
5. Beginnen Sie mit einem Kanal, bevor Sie alle Kanäle umstellen.