Die Frage kam häufiger in unseren Erstgesprächen: "Können wir Shopware als reines Backend nutzen?" Die Antwort ist ja. Shopware 6 ist von Grund auf für Headless gebaut. Aber ob du es solltest, ist eine andere Geschichte.
Wir haben die meisten erfolgreichen Headless-Shopware-Projekte im DACH-Raum umgesetzt. Was wir dabei gelernt haben: Headless ist nicht automatisch besser. Es ist eine Architektur-Entscheidung, die sich unter bestimmten Voraussetzungen auszahlt. Und unter anderen eben nicht.
Inhalt
- Was bedeutet Headless?
- Shopware 6 Store API und Admin API
- Shopware Frontends oder eigenes Frontend?
- Die TCO-Rechnung: Warum Headless langfristig günstiger wird
- Typischer Tech-Stack: Nuxt 3 + Shopware
- Wann lohnt sich Headless wirklich?
- Anforderungen ans Team
- Häufige Anfängerfehler
- Fazit
Was bedeutet Headless?
Headless bedeutet: Frontend und Backend sind komplett getrennt. Shopware ist nur noch der Shop-Engine. Die Datenbankik, die Business-Logik, die Verwaltung von Produkten, Bestellungen, Kunden. Das alles läuft in Shopware. Das Frontend, also das was deine Kunden sehen und womit sie interagieren, ist ein separates Projekt.
Das Frontend kommuniziert mit Shopware über REST-APIs. Der Kunde sieht nie dass Shopware dahinter läuft. Es könnte genauso gut commercetools oder Medusa sein.
Der große Unterschied zur klassischen Shopware-Installation: Du verwendest nicht das Template-System, nicht den Theme-Editor, nicht die Shopware Admin UI zum Styling. Stattdessen hast du ein modernes JavaScript-Frontend (z.B. Nuxt 3, Next.js) das über APIs mit Shopware spricht.
Klingt größer als es ist. Am Ende ist es ein anderes Frontend auf derselben Shop-Engine.
Shopware 6 Store API und Admin API
Shopware 6 ist API-first. Das ist das Fundament für Headless.
Die Store API ist public. Sie ist dafür gebaut, dass dein Frontend damit arbeitet. Produkte abrufen, Kategorien, Filter, Checkout, Bestellungen, Kundenkonten. Alles über REST-Endpoints. Die meisten Headless-Setups arbeiten hauptsächlich mit der Store API.
Die Admin API ist privat. Nur für Systeme da die sich mit Admin-Credentials authentifizieren. ERP-Systeme, PIM-Tools, dein Backend wenn du Automation brauchst.
Wichtig: Beide APIs sind nicht neu oder experimentell. Sie sind der Standard-Weg wie Shopware seit Version 6.0 gebaut wurde. Auch die native Shopware Admin UI nutzt diese APIs.
Das bedeutet: Du bist nicht im Experiment-Modus. Du baust auf dem gleichen Weg wie Shopware selbst.
Shopware Frontends oder eigenes Frontend?
Shopware hat vor ein paar Jahren ein offizielles Headless-Framework rausgebracht: Shopware Frontends. Basiert auf Nuxt und Vue. Der Gedanke war: "Wir geben dir ein Starterkit das schon mit der Store API verdrahtet ist."
Das ist praktisch. Wenn du ein Standard-Setup willst und schnell starten möchtest, nimm Shopware Frontends.
Aber: Die meisten Kundenprojekte bei uns gehen einen anderen Weg. Nicht weil Shopware Frontends schlecht ist, sondern weil "Standard" selten passt.
Wenn dein Frontend spezifische Anforderungen hat (Custom Design, spezielle Checkout-Logik, B2B-Szenarien, Content-Management), bauen wir ein eigenes Frontend. Auch auf Nuxt, auch mit Vue, aber frei strukturiert ohne das Shopware-Starterkit.
Das Problem: Shopware Frontends ist wie eine zweite Theme-Engine. Es hat eigene Abstraktionen, eigene Konventionen, eine spezifische Ordnerstruktur. Wenn du von dort aus custom gehen möchtest, musst du diese Struktur wieder verlassen. Das ist mehr Reibung als von Anfang an ein reines Frontend zu bauen das du selbst kontrollierst.
Unsere Empfehlung:
- Shopware Frontends: Wenn du schnell ein MVP haben möchtest und standard-Setup passt
- Eigenes Frontend: Wenn dein Projekt Custom-Anforderungen hat oder über die Zeit wachsen wird
Die TCO-Rechnung: Warum Headless langfristig günstiger wird
Das ist das wichtigste Argument. Und es überrascht viele.
Headless ist initial teurer. Ein eigenes Frontend kostet. Hosting kostet. DevOps kostet. Das ist real.
Aber hier kommt der Knackpunkt: Wenn Shopware ein Major-Update rausbringt, betrifft dich das ganz anders als bei einem klassischen Shop.
Bei einem klassischen Shopware-Shop mit Standard-Theme:
- Shopware bringt Version 6.5 raus
- Dein Theme-Hersteller muss sein Theme daran anpassen
- Du musst updaten, dein Theme muss kompatibel sein
- Wenn dein Theme-Hersteller insolvent wird, hängst du fest
- Template-Vererbung kann brechen
- Jedes Update ist mindestens "nicht trivial"
Bei Headless:
- Shopware bringt Version 6.5 raus
- Das betrifft nur die API-Schicht
- Dein Frontend spricht über API mit Shopware
- Solange die API stabil bleibt (und Shopware macht das ernst), ändert sich bei dir fast nichts
- Update ist ein Backend-Thema, nicht Frontend-Thema
- Dein Frontend hat seinen eigenen Update-Zyklus
Das klingt theoretisch. Aber praktisch heißt das: Du sparst dir die ewigen Theme-Update-Zyklen. Das ist über 3-5 Jahre Betrieb ein massiver Kostenvorteil.
Konkrete Zahlen aus unseren Projekten:
- Klassischer Shop: 2.000+ EUR pro Jahr für Updates und Theme-Anpassungen
- Headless Shop: 500+ EUR pro Jahr, weil Updates on de Infrastruktur laufen
Das ist nicht erfunden. Das ist echte Kunde-Feedback über mehrere Jahre hinweg.
Unser Tipp: Kalkulier die TCO über 3 Jahre. Nicht nur Entwicklungskosten, sondern auch laufende Wartung und Updates. Das ist wo Headless seinen Vorteil ausspielt.
Typischer Tech-Stack: Nuxt 3 + Shopware
Was bauen wir eigentlich wenn wir ein Headless-Shopware-Frontend entwickeln?
Typischerweise:
- Frontend: Nuxt 3 (Vue 3, Server-Side Rendering)
- Styling: Tailwind CSS
- State Management: Pinia
- APIs: Shopware Store API über TypeScript-Clients
- Content Management: Meistens Storyblok als Headless-CMS für Landing Pages, Blog, statische Content
- Hosting: Vercel, Netlify oder selbst-gehostet auf beliebiger Infrastructure
- Build-Tool: Vite (im Nuxt eingebaut)
Das ist kein Wild-Wild-West. Das ist ein bewährter Stack. Hunderte Frontend-Developer weltweit nutzen diese Kombination. Du bekommst nicht irgendwas, sondern Standardtechnologie.
Was oft überrascht: Das ist nicht teurer in der Entwicklung als ein Custom-Theme. Ein gutes Frontend braucht genauso Aufwand wie ein gutes Theme. Der Unterschied ist dass dein Frontend dir gehört und nicht an ein Theme-Ökosystem gebunden ist.
Wann lohnt sich Headless wirklich?
Nicht für jeden Shop. Ehrlich.
Die Entscheidungs-Frage ist wieder: "Reicht der Standard oder brauch ich Excellence im Frontend?"
Headless macht Sinn wenn du:
Mehr als 30% Custom im Frontend brauchst. Das ist die Schwelle. Unter 30%: Ein gutes Theme reicht. Über 30%: Die Komplexität eines Headless-Setups ist rechtfertigt.
Multiple Frontend-Clients brauchst. Eine Shopware-Instanz, mehrere Frontends. Web, Mobile-App, Kiosk-Display. Mit einem Theme unmöglich, mit Headless elegant.
Langfristig planst (5+ Jahre) und die TCO-Ersparnis relevant ist. Headless amortisiert sich über Zeit durch weniger Theme-Update-Probleme. Eine detaillierte Kostenrechnung für Headless hilft dir bei der Entscheidung.
Content-Management auf Enterprise-Level brauchst. Mit Storyblok als separates CMS kriegen Content-Teams ein echtes Werkzeug. Das ist zusammen mit Headless elegant.
Was Headless NICHT macht: Es macht deinen Shop nicht schneller zu verkaufen (das Gegenteil trifft zu). Es macht deinen Shop nicht billiger (initial teurer). Es ist keine Wunderlösung.
Headless ist eine Architektur-Entscheidung für Unternehmen die verstehen dass sie spezialisierte Frontend-Anforderungen haben UND bereit sind dafür zu investieren.
Anforderungen ans Team
Das ist der praktische Punkt den viele ignorieren.
Um ein Headless-Shopware-Projekt zu machen, brauchst du:
Frontend-Developer mit Vue/Nuxt-Expertise. Das ist nicht optional. Du kannst keine React-Developer nehmen und "Nuxt wird schon gehen". Nuxt-Erfahrung ist wichtig. Die Architektur ist anders als "eine React-App bauen."
Jemanden der Shopware APIs versteht. Der Store API Aufbau, Authentication, Filter-Logik, Checkout-Prozess. Das ist kein Frontend-Standard sondern spezifisches Shopware-Wissen.
DevOps für Hosting und Deployment. Dein Frontend muss irgendwo laufen. Vercel hat gute Standard-Pipelines, aber wenn du selbst hostest brauchst du jemanden der GitHub Actions oder ähnliche CI/CD-Tools konfiguriert.
Ein Shopware-Entwickler auf der Backend-Seite. Jemand der bei Custom API-Endpoints, Business-Logic oder Performance-Problemen auf API-Seite helfen kann.
Das sind nicht die gleichen Anforderungen wie "Theme anpassen in Shopware." Das ist echte Full-Stack-Entwicklung.
Wenn dein Team das nicht hat, musst du es budgetieren. Entweder interne Onboarding oder mit einer Agentur arbeiten die beide Welten kennt.
Häufige Anfängerfehler
Aus unseren Projekten haben wir ein paar Pattern gesehen die wiederholt schiefgehen.
Fehler 1: Headless aus Performance-Gründen wenn Content-Geschwindigkeit das Problem ist. "Unser Shop ist langsam" ist selten ein Frontend-Problem. Selten. Meistens ist es eine Datenbankabfrage, schlechte API-Performance oder falsch konfiguriertes Caching. Headless hilft nicht wenn das Problem im Backend liegt.
Fehler 2: Shopware Frontends nehmen weil es "einfacher" ist und dann später merken dass die Customizing-Grenzen zu eng sind. Das ist dann ein teurer Umstieg.
Fehler 3: Zu viel Content in den Shop legen statt ein echtes CMS zu verwenden. Shopware ist eine Shop-Engine, kein CMS. Mit Storyblok ist das elegant. Ohne wird es schnell unschön.
Fehler 4: Anforderungen unterschätzen. "Der Shop wird einfach." Nein. Mit Headless werden Anforderungen nur anders. Nicht geringer. Wenn du ein komplexes Checkout-Szenario hast, das ist genauso komplex ob es im Template-System oder im Frontend ist.
Fazit: Investition in die Zukunft
Headless Shopware ist nicht für jeden Shop. Aber wenn deine Anforderungen es rechtfertigen, ist es eine saubere Entscheidung für die nächsten 5 bis 10 Jahre.
Die Architektur trennt Backend und Frontend. Das gibt dir Freiheit. Updates sind einfacher. Der Tech-Stack ist modern. Die TCO über lange Zeit ist oft besser als bei klassischen Setups.
Was wichtig ist: Geh nicht in Headless weil es cool klingt. Geh rein weil deine Anforderungen es brauchen. Wenn eine Standard-Lösung passt, ist das schneller, günstiger und weniger Komplexität.
Und wenn du Headless brauchst, brauchst du ein Team das es versteht. Shopware-Developer und Frontend-Developer die beide ihre Welt kennen.