Headless Commerce

Was bedeutet „API-first“ konkret?

Bei einem klassischen Shopsystem sind Backend und Frontend fest verzahnt: JTL-Shop rendert seine Seiten über NOVA-Templates, Shopify über Liquid — die Darstellung ist Teil des Shopsystems selbst. Bei Headless Commerce wird diese Verbindung aufgebrochen: Das Backend liefert Daten ausschließlich über APIs (meist REST oder GraphQL), das Frontend ist eine komplett eigenständige Anwendung, oft mit Frameworks wie Next.js oder Nuxt gebaut.

Der Begriff „headless“ bezieht sich auf das fehlende feste „Haupt“ (Head) im Sinne einer vorgegebenen Darstellungsschicht — das Backend weiß nicht, wie oder wo seine Daten angezeigt werden. Dieselben Produktdaten lassen sich dadurch parallel auf einer Website, in einer App, an einem Kiosk-Terminal oder in einem Voice-Assistant ausspielen.

Wie funktioniert Headless Commerce technisch?

Das Bindeglied zwischen Backend und Frontend ist eine Storefront-API: eine speziell für die Kundenansicht gedachte Schnittstelle, über die das Frontend Produktdaten, Preise, Warenkorb und Bestellungen abruft und schreibt. Wo ein klassisches Theme direkt auf die Datenbank des Shopsystems zugreift, spricht ein Headless-Frontend nur noch mit dieser API-Schnittstelle — meist über GraphQL, weil sich damit gezielt genau die Felder anfragen lassen, die eine Seite tatsächlich braucht.

Ein typischer Stack sieht so aus: Ein Frontend-Framework wie Next.js oder Nuxt (auf Basis von React beziehungsweise Vue) rendert die Seiten und holt sich die Daten über die Storefront-API des Shopsystems. Bei Shopify ist das die Storefront API; wer stärker im Shopify-Ökosystem bleiben will, nutzt Hydrogen, Shopifys eigenes React-Framework für Headless-Storefronts, das häufig im Umfeld der erweiterten Möglichkeiten von Shopify Plus zum Einsatz kommt. Eine andere Kategorie sind reine Composable-Stacks, bei denen eine spezialisierte Commerce-Engine (etwa commercetools) mit einem separaten Headless-CMS für Inhalte (etwa Sanity oder Contentful) kombiniert wird. Allen gemeinsam ist: Das Frontend ist ein eigenes Software-Projekt mit eigenem Deployment, eigenem Hosting und eigenem Build-Prozess.

Headless, Monolith oder Composable Commerce — was ist der Unterschied?

Die Begriffe werden oft vermischt, meinen aber unterschiedliche Architekturen:

Ein Monolith liefert Frontend und Backend aus einem Guss — JTL-Shop, Shopware im Standard oder ein klassisches Shopify-Theme. Headless trennt die Darstellung ab, lässt das Backend aber als eine zusammenhängende Commerce-Engine bestehen. Composable Commerce geht noch einen Schritt weiter und setzt den gesamten Shop aus einzelnen, austauschbaren Bausteinen zusammen (Commerce-Engine, Suche, CMS, Payment, jeweils „best of breed“). Merksatz: Jedes Composable-Setup ist headless, aber nicht jedes Headless-Setup ist composable — und die meisten Shops brauchen keines von beiden.

Vor- und Nachteile ehrlich abgewogen

Der zentrale Trade-off: Headless tauscht Einfachheit gegen Kontrolle. Wer diese Kontrolle nicht aktiv braucht — weil ein Kanal reicht, das Standard-Theme performant genug ist und Marketing eigenständig Inhalte pflegen soll — zahlt nur die Nachteile, ohne die Vorteile zu nutzen.

Was kostet Headless Commerce wirklich?

Die ehrlichste Antwort lautet: deutlich mehr als ein klassisches Shop-Projekt — und zwar dauerhaft, nicht nur einmalig. Der eigentliche Kostentreiber ist nicht die erste Umsetzung, sondern die Tatsache, dass ein eigenes Frontend ein eigenes Produkt ist, das gepflegt, aktualisiert und weiterentwickelt werden muss:

• Keine Theme-Abkürzung: Bei einem klassischen Shop kauft oder passt man ein Theme an, das tausende Details bereits mitbringt — Warenkorb, Filter, Checkout, Responsive-Verhalten. Headless bedeutet, viele dieser Bausteine selbst zu bauen.
• Laufende Entwicklung: Jede Änderung — vom neuen Landingpage-Layout bis zum Bugfix — ist ein Entwicklungsvorgang mit Deployment, nicht ein Klick im Editor.
• Zwei Systeme im Betrieb: Backend und Frontend müssen getrennt gehostet, überwacht und aktuell gehalten werden.
• Kein Ökosystem von der Stange: Apps und Plugins, die im klassischen Theme einfach „funktionieren“, müssen im Headless-Frontend oft eigens integriert werden.

Konkrete Zahlen hängen zu stark vom Einzelfall ab, um seriös pauschal zu sein — aber als Größenordnung liegt ein tragfähiges Headless-Projekt deutlich über dem, was ein klassisches Shop-Projekt kostet, und verursacht spürbare laufende Kosten für die Weiterentwicklung.

Welche SEO-Implikationen hat Headless?

Headless ist für SEO weder automatisch gut noch schlecht — es kommt vollständig auf die Rendering-Strategie an. Der entscheidende Punkt: Suchmaschinen müssen die Inhalte zuverlässig sehen können.

• Server-Side-Rendering (SSR) oder Static Site Generation (SSG) sind Pflicht. Wird das Frontend rein clientseitig gerendert, erscheinen Inhalte erst durch JavaScript im Browser — das riskiert schlechtere oder verzögerte Indexierung. Frameworks wie Next.js oder Nuxt lösen das über SSR/SSG, aber nur, wenn es bewusst eingesetzt wird.
• Core Web Vitals als Chance: Ein sauber gebautes Headless-Frontend kann bei Ladezeit und Interaktivität glänzen und damit ein positives Ranking-Signal liefern — genau der Vorteil, für den viele Headless überhaupt in Betracht ziehen.
• Neue Risiken: URL-Struktur, Weiterleitungen, Canonical-Tags, strukturierte Daten und hreflang müssen im Frontend selbst korrekt umgesetzt werden — Aufgaben, die ein klassisches Theme oft mitbringt. Fehler an dieser Stelle kosten Sichtbarkeit.

Kurz: Headless verlagert die SEO-Verantwortung ins Frontend-Team. Richtig gemacht ist es ein Vorteil; nebenbei erledigt wird es zum Risiko.

Wann lohnt sich Headless Commerce?

Headless Commerce zahlt sich typischerweise aus bei:

• Echtem Multi-Channel-Bedarf: derselbe Produktkatalog soll auf Website, App und weiteren Touchpoints mit unterschiedlichem Design erscheinen.
• Sehr spezifischen Performance-Anforderungen, die über das hinausgehen, was ein optimiertes Standard-Theme leisten kann.
• Komplexen, individuellen User-Experiences, die sich mit Theme-Bordmitteln nicht abbilden lassen — etwa stark konfigurierbare Produkte oder ungewöhnliche Checkout-Flows.
• Bestehendem, eingespieltem Entwicklerteam, das die dauerhafte Pflege eines eigenständigen Frontends stemmen kann.

Wann ist Headless die falsche Wahl?

In der Praxis ist das der häufigere Fall. Headless bringt nichts — kostet aber viel —, wenn eine dieser Bedingungen zutrifft:

• Standard-Sortiment und ein Verkaufskanal: Wer Produkte über einen gut gebauten Webshop verkauft und keinen zweiten Touchpoint mit eigenem Design bedient, nutzt die Multi-Channel-Stärke von Headless gar nicht.
• Kleines Team ohne feste Entwicklung: Ohne dauerhaften Entwicklungszugriff wird jede kleine Änderung zum Ticket. Ein Shopify-Liquid-Theme oder JTL-Shop auf NOVA-Basis lässt sich dagegen im Editor pflegen.
• Budget unterhalb des mittleren fünfstelligen Bereichs: Reicht das Budget nicht für Aufbau und laufende Pflege eines eigenen Frontends, ist Headless finanziell nicht tragfähig.
• Das Theme reicht: Wenn ein optimiertes Standard-Theme die Performance- und Design-Anforderungen erfüllt, gibt es schlicht keinen Grund, die Komplexität zu erhöhen. Die Annahme, Headless sei „automatisch schneller“, stimmt nicht — ein schlecht umgesetztes Headless-Frontend mit unnötigen API-Roundtrips kann langsamer sein als das Theme, das es ersetzen sollte.

Halbe Schritte: Hybride Ansätze

Zwischen klassischem Theme und vollständigem Headless-Umbau gibt es Zwischenstufen, die in der Praxis oft übersehen werden. Shopify erlaubt es etwa, einzelne Bereiche eines ansonsten klassischen Themes über die Storefront-API mit eigenem Frontend-Code zu versehen, während der Rest des Shops weiter über Liquid läuft. Das reduziert den Aufwand gegenüber einem kompletten Headless-Umbau erheblich und eignet sich für Shops, die nur an einzelnen Stellen — etwa einem individuellen Produktkonfigurator — mehr Kontrolle brauchen, aber sonst mit dem Standard-Theme zufrieden sind.

Was Headless für die Datenarchitektur bedeutet

Ein Headless-Setup verschiebt die Verantwortung für konsistente, kanalübergreifende Produktdaten stärker ins Backend, weil kein Theme mehr „mitdenkt“, wie Daten dargestellt werden sollen. Ohne ein sauber strukturiertes Datenmodell — häufig unterstützt durch ein eigenes PIM-System — wird die vermeintliche Flexibilität schnell zur Fehlerquelle, weil jedes Frontend die Rohdaten unterschiedlich interpretieren muss.

Entscheidungs-Checkliste: Ist Headless das Richtige?

Vor einer Headless-Entscheidung sollten diese Fragen ehrlich beantwortet sein:

1. Gibt es echten Multi-Channel-Bedarf? Sollen dieselben Produktdaten auf mehreren Kanälen (Web, App, weitere) mit unterschiedlichem Design erscheinen?
2. Stößt das Standard-Theme nachweislich an Grenzen? Gibt es konkrete Design- oder Performance-Anforderungen, die sich mit Theme-Bordmitteln nicht lösen lassen?
3. Steht ein dauerhaftes Entwicklerteam bereit? Kann jemand das Frontend nicht nur bauen, sondern über Jahre pflegen?
4. Trägt das Budget Aufbau UND Betrieb? Ist Raum für laufende Weiterentwicklung eingeplant, nicht nur für die einmalige Umsetzung?
5. Ist ein sauberes Datenmodell vorhanden? Sind die Produktdaten — idealerweise über ein PIM-System — kanalübergreifend konsistent gepflegt?
6. Ist die Redaktion mitgedacht? Gibt es ein CMS oder Interface, über das Inhalte ohne Entwickler gepflegt werden können?

Wer mehrere dieser Fragen mit „nein“ beantwortet, fährt mit einem optimierten klassischen Shop fast immer besser.

Typische Fehler bei Headless-Projekten

1. Headless gewählt, weil es „modern“ klingt — ohne konkreten Multi-Channel- oder Performance-Bedarf entsteht nur Mehraufwand ohne Gegenwert.
2. Unterschätzter Wartungsaufwand — zwei Systeme (Backend + Frontend) bedeuten zwei Update-Zyklen, zwei potenzielle Fehlerquellen, zwei Hosting-Umgebungen.
3. Fehlendes zentrales Datenmodell — ohne sauber gepflegte Produktdaten, oft über ein eigenes PIM-System, wird die API-Schicht zur Fehlerquelle statt zur Stärke.
4. Redaktion ohne Werkzeug — wird kein CMS oder Headless-Interface für Inhalte eingerichtet, landet jede Textänderung im Entwickler-Backlog.
5. Caching vernachlässigt — ohne durchdachte Caching-Strategie ist ein Headless-Frontend oft langsamer als das Theme, das es ersetzen sollte.

Die richtige Architektur-Entscheidung treffen

Ob Headless Commerce den Mehraufwand wert ist, hängt von echtem Bedarf ab, nicht vom Trend. Wir prüfen das im Rahmen unserer Entwicklung-Beratung ergebnisoffen und begleiten bei Bedarf die Umsetzung — sei es ein optimiertes klassisches Shopify-Theme über unsere Shopify-Agentur oder ein individuelles Headless-Frontend. Häufig ist die wirtschaftlichere Lösung nicht die technisch aufwendigste.