Was ist Headless Commerce?

„Headless“, kopflos, beschreibt ein System, dem die Darstellungsschicht fehlt. Laut einem Forrester-Analysten (2019) und laut commercetools selbst hat Dirk Hoerig, Mitgründer von commercetools, den Begriff 2013 vorgeschlagen. Auf den Seiten von sphere.io, dem ersten Produktnamen von commercetools, die das Internet Archive im April 2013 gespeichert hat, kommt das Wort nicht vor. Die Zuschreibung bleibt deshalb eine Angabe dieser beiden Quellen.

Eine Commerce-Engine verwaltet Produkte, Preise, Bestand und Bestellungen und stellt sie per API bereit, zum Beispiel über REST oder GraphQL. Das Frontend, eine Website, eine App oder ein anderer Kanal, holt diese Daten ab und baut daraus die Seiten. Laut Shopify kannst du so auf einer Website, in einer App, in einem Spiel, in einem Livestream oder über einen Kaufbutton auf einer anderen Website verkaufen.

Neben der Engine steht oft ein Headless CMS für Texte und Bilder. Der Unterschied liegt im Inhalt: Das Headless CMS verwaltet Inhalte, die Commerce-Engine verwaltet Produkte, Preise und Bestellungen.

Quelle: Shopify, „About headless commerce“; BigCommerce, „Introduction to Headless Commerce“ (abgerufen am 12.11.2026).

Manche Hersteller sprechen bei ähnlichen Ansätzen von „composable“, Shopware etwa bei seinen Composable Frontends.

Shopify stellte am 29. Juni 2021 Hydrogen vor, damals ein React-Framework für Headless-Shops, und dazu Oxygen als Hosting. In der Version 2026-10 arbeitet Hydrogen mit Frameworks wie Next.js, React Router, Nuxt, Astro und SvelteKit. Shopware verbindet seine Frontends über die Store API mit dem Shop, mit einem Demo-Shop auf Basis von Vue.js und Nuxt.

Bei einem Headless-Shop lohnt es sich zu messen, was bei Google ankommt. Das URL-Prüftool der Google Search Console zeigt einen Screenshot der gerenderten Seite, die geladenen Ressourcen und die Ausgabe des JavaScript. Eine Anfrage mit curl an eine Produktseite zeigt, ob das HTML vom Server schon Name, Preis und Text enthält oder ob diese erst später per JavaScript kommen.

Der Vorteil ist Freiheit: jede Technik fürs Frontend, ein Katalog für mehrere Kanäle und die Möglichkeit, ein CRM, ein ERP oder ein PIM anzubinden.

Die Kosten räumt Shopify selbst ein: „A headless storefront costs more to build and run than a theme“. Du musst diese Komplexität in Kauf nehmen und auch nach dem Start Entwickler haben. Shopify empfiehlt headless nur, wenn sich die Anforderungen mit seinen Themes und Apps nicht lösen lassen.

Für SEO ist headless weder besser noch schlechter. Es kommt auf die Umsetzung an:

• Das Rendering. Google stellt Seiten mit Code 200 in die Rendering-Warteschlange und empfiehlt Server-Side-Rendering oder Pre-Rendering, weil nicht alle Bots JavaScript ausführen. Ein Frontend, das Produktseiten nur im Browser zusammensetzt (Client-Side-Rendering), hängt von diesem zweiten Schritt ab.
• Die Statuscodes. In einer Single-Page-App kann eine nicht vorhandene URL 200 liefern und zum Soft 404 werden. Google beschreibt, wie du das vermeidest.
• Die Ressourcen. Google warnt davor, Skripte per robots.txt zu sperren, ohne die es die Seite nicht versteht.
• Die Filter. Facettennavigation erzeugt viele URLs; Google empfiehlt, ihr Crawling zu verhindern, wenn sie nicht in den Index müssen.
• Die strukturierten Daten für Produkte, die das Frontend aus der API erzeugt.

Wie wir das selbst mit einem Headless CMS und Astro gelöst haben, steht in unserem Artikel zu Headless CMS und SEO.

Ein Headless CMS trennt Inhalte und Darstellung; Headless Commerce macht dasselbe mit der Verkaufslogik. Ein Shop kann beides gleichzeitig nutzen. E-Commerce ist der Oberbegriff für den Verkauf im Internet; headless beschreibt nur, wie der Shop gebaut ist.

Quelle: Dokumentation der jeweiligen Hersteller (abgerufen am 12.11.2026). Alphabetisch, ohne Wertung.

Die Zahlen der Hersteller zu Umsatz oder Ladezeit von Headless-Shops nennen keine Methode, deshalb stehen sie hier nicht. Eine einheitliche Definition gibt es auch nicht: Jeder Hersteller beschreibt headless von seinem Produkt aus.

• Prüf, ob deine jetzige Plattform mit ihren Themes und Apps schon abdeckt, was du brauchst.
• Sorg für ein Entwicklungsteam fürs Frontend, auch nach dem Start.
• Wähl ein Frontend, das Kategorie- und Produktseiten als HTML vom Server ausliefert.
• Plan die Weiterleitungen der alten URLs vor dem Umzug.
• Erzeug die strukturierten Daten für Produkte aus der API.
• Prüf in der Search Console das gerenderte HTML einer Kategorie- und einer Produktseite.

• Liefere für Produkte, die es nicht mehr gibt, einen echten 404, keine leere Seite mit 200.
• Lass Googlebot die Skripte und Stylesheets laden, die er zum Rendern braucht.

• Auf headless umsteigen, ohne eigenes Team für die Pflege des Frontends.
• Ein Frontend starten, das Inhalte nur im Browser zeichnet.
• Die Weiterleitungen des alten Shops vergessen.

Dieser Eintrag entstand im November 2026 mit Unterstützung von KI. Die Angaben stammen aus der Doku von Shopify, BigCommerce, Shopware, Adobe Commerce, VTEX und commercetools, aus einem Forrester-Blog, aus Googles Doku und aus dem Internet Archive. Er wurde vor der Veröffentlichung geprüft und enthält keine Kundendaten.