
Was Shopware Headless für Onlinehändler in Österreich technisch bedeutet, welche Frontend-Optionen 2026 noch gepflegt werden (Shopware Frontends, Next.js, nicht mehr Shopware PWA), was ein eigenes Frontend kostet und wann die Storefront reicht.
Shopware 6 ist von Haus aus headless-fähig. Die Store API liefert Produkte, Warenkorb, Checkout und Kundenkonto als JSON, also in einem maschinenlesbaren Format, und die mitgelieferte Storefront nutzt intern dieselben Routen. Ein eigenes Frontend ist deshalb eine Option, keine Pflicht.
Headless lohnt sich für wenige, klar umrissene Fälle: mehrere Kanäle aus einem Backend, Marken mit sehr hohem Content-Anteil, Apps und Portale oder ein Entwicklungsteam, das ohnehin mit Vue oder React arbeitet.
Rechnen Sie mit mindestens 40.000 € für das Frontend und danach mit zwei Systemen im laufenden Betrieb. Für die meisten Händler bis weit in den siebenstelligen Umsatz ist die Shopware Storefront mit eigenem Theme die wirtschaftlichere Wahl.
Dieser Beitrag richtet sich an Onlinehändler in Österreich, die über ein eigenes Frontend für ihren Shopware-Shop nachdenken. Wir betreuen Shopware-Projekte in Österreich und Deutschland und zeigen, wann sich Headless lohnt und wann die Storefront reicht.
Ein eigenes Frontend verspricht Designfreiheit und Tempo, kostet aber ein Mehrfaches eines Themes und verdoppelt den Betrieb. Dieser Beitrag richtet sich an Geschäftsführer und E-Commerce-Leiter vor einer Plattform- oder Relaunch-Entscheidung sowie an Händler, die neben dem Webshop eine App, ein Portal oder weitere Markenauftritte planen.
Nach dem Lesen können Sie entscheiden, ob Storefront, Hybrid oder Headless zu Ihrem Shop passt, kennen die 2026 gepflegten Frontend-Optionen und können Budget, Team und Projektablauf realistisch planen.
Wir haben vor der Gründung von solution25 selbst einen Online-Shop betrieben und auf mehr als 500 Bestellungen am Tag gebracht. Seit 2017 setzen wir Shopware-Projekte um, mit klassischer Storefront ebenso wie mit entkoppelten Frontends auf Basis der Store API. Kosten und Teambedarf sind Erfahrungswerte aus unseren Projekten, alle Preise Stand Oktober 2026, zuzüglich Mehrwertsteuer.
Rund um Shopware Headless werden drei Begriffe oft vermischt. Sie beschreiben aber unterschiedliche Dinge, und die Unterscheidung entscheidet später über Budget und Team.
„Headless“ heißt wörtlich „kopflos“. Gemeint ist ein System ohne fest verbundene Präsentationsschicht. Ein Headless Shop ist also kein Shop ohne Oberfläche, sondern einer, dessen Oberfläche austauschbar ist.
Shopware selbst nennt den Kern von Shopware 6 „Headless Core“ und setzt in seiner Wissensdatenbank Headless und Composable Commerce gleich. Für die Planung lohnt die Trennung: Composable bedeutet mehr Systeme, mehr Verträge und mehr Schnittstellen.
Shopware 6 stellt zwei Schnittstellen bereit, die in einem Headless-Projekt unterschiedliche Aufgaben haben. Die Unterschiede, auch zu GraphQL, erklären wir ausführlich unter GraphQL und REST-APIs in Shopware.
| Schnittstelle | Zweck | Zugriff | Typische Nutzer |
|---|---|---|---|
| Store API | Alles, was ein Kunde im Shop tut: Produkte, Kategorien, Suche, Warenkorb, Checkout, Kundenkonto, Erlebniswelten, SEO-URLs | Öffentlich je Vertriebskanal (Header sw-access-key), Sitzung über den Header sw-context-token | Headless-Frontends, Apps, Terminals |
| Admin API | Verwaltung aller Daten: Produkte anlegen, Bestellungen abrufen, Kunden, Medien, Konfiguration | OAuth-Zugang über Integrationen oder Benutzer, Pfad /api | ERP, PIM, Middleware, eigene Werkzeuge |
Die Store API liegt unter dem Pfad /store-api und ist auf Frontends zugeschnitten: Sie gibt nur Daten heraus, die für Kunden bestimmt sind, und funktioniert für Gäste wie für angemeldete Kunden. Jeder Aufruf trägt den Zugangsschlüssel des Vertriebskanals im Header sw-access-key.
Die Sitzung läuft über den Header sw-context-token. Er hält Warenkorb, Anmeldung, Sprache, Währung und Zahlungsart zusammen, ohne dass der Server eine klassische Session braucht. Wie das im Detail funktioniert, steht in unserem Glossar unter Kontext-Token.
Die wichtigsten Routen zeigen, wie vollständig die Schnittstelle ist: POST /store-api/product für Listen und Suche, POST /store-api/checkout/cart/line-item für den Warenkorb, POST /store-api/account/login für Kunden, POST /store-api/checkout/order für die Bestellung. Auch SEO-URLs und CMS-Seiten kommen aus der Store API, sodass ein Headless-Frontend dieselben Pfade wie die Storefront verwenden kann.
Ein Detail, das viele Diskussionen entschärft: Die mitgelieferte Twig-Storefront ruft intern dieselben Store-API-Routen auf, die ein Headless-Frontend von außen nutzt. Shopware beschreibt das in seiner Architekturdokumentation ausdrücklich so. Die Storefront ist damit technisch bereits ein Konsument der API, nur eben in PHP und auf demselben Server.
Wer headless geht, bekommt also keine andere Datenbasis und keine anderen Funktionen, sondern eine andere Präsentationsschicht mit anderem Stack, anderem Hosting und anderem Team.
In der Administration legen Sie für ein eigenes Frontend einen Vertriebskanal vom Typ „Headless“ an, mit eigenem Zugangsschlüssel, eigenen Domains, Sprachen, Währungen und Zahlungsarten. So laufen Webshop, App und B2B-Portal parallel auf einem Backend, auf Wunsch mit getrennten Sortimenten und Preisen.
Die Frage, womit das Frontend gebaut wird, hat sich in den letzten drei Jahren geklärt. Einige Optionen aus älteren Artikeln sind eingestellt.
| Option | Stack | Gepflegt von | Stand Oktober 2026 |
|---|---|---|---|
| Shopware Frontends (Composable Frontends) | Vue 3, Nuxt 4, TypeScript | Shopware, MIT-Lizenz | Offizielle Lösung, Vue Starter Template als produktionsreife Basis |
| Next.js Shopware Starter | React, Next.js App Router, Tailwind | Shopware Labs, Vorlage bei Vercel | Referenzprojekt ohne integrierten Checkout |
| Eigenbau mit @shopware/api-client | Beliebiges JavaScript-Framework, auch Astro, Svelte oder Angular | Shopware (Paket), Projekt (Frontend) | Typisierter Client, Typen aus dem OpenAPI-Schema des eigenen Shops |
| Shopware PWA (mit Vue Storefront) | Vue 2, Nuxt 2 | Niemand mehr | Repository seit 31. Oktober 2024 archiviert, Alokai führt Shopware nicht als Integration |
Shopware Frontends, im Marketing Composable Frontends genannt, ist das eigene Framework von Shopware für Headless-Storefronts. Es besteht aus mehreren npm-Paketen: @shopware/api-client (framework-unabhängig), @shopware/helpers, @shopware/composables mit rund 60 Vue-Composables wie useCart, useUser oder useListing, dem Nuxt-Modul und dem Paket cms-base-layer, das die Erlebniswelten aus dem Shopware-CMS rendert.
Shopware empfiehlt als Ausgangspunkt das Vue Starter Template auf Nuxt 4 mit Server-Side Rendering, Mehrsprachigkeit und generierten TypeScript-Typen. Es enthält bewusst keine fertige Shop-Oberfläche: Navigation, Produktseiten, Warenkorb, Checkout und Kundenkonto setzt das Projekt selbst aus den Composables zusammen.
Wichtig für Teams, die 2023 oder 2024 gestartet sind: Das frühere Demo Store Template ist laut Dokumentation abgekündigt und nicht für den Produktivbetrieb gedacht. Daneben gibt es ein Astro-Template und ein leeres Template ohne UI-Paket.
Voraussetzungen sind Node.js 22 (LTS) und eine Shopware-6-Instanz, selbst gehostet oder als SaaS. Das Framework ist Open Source unter MIT-Lizenz, und auf der Preisseite von Shopware ist Headless kein Planmerkmal: Store API und Frontends stehen auch mit der Community Edition zur Verfügung.
Für React-Teams stellt Shopware Labs einen Next.js Shopware Starter bei Vercel bereit: App Router, React Server Components, Server Actions, Tailwind, angebunden über @shopware/api-client. Der Starter liefert keinen fertigen Checkout. Projekte leiten entweder in den Checkout der Shopware Storefront um oder bauen den Checkout über die Store API selbst.
Shopware PWA, 2020 gemeinsam mit Vue Storefront gestartet, war der erste Headless-Ansatz von Shopware. Im Dezember 2022 kündigte Shopware an, das Projekt in Shopware Frontends zu überführen, und am 31. Oktober 2024 wurde das Repository archiviert, mit Verweis auf Composable Frontends als Nachfolger.
Vue Storefront heißt heute Alokai. In der Integrationsliste von Alokai stehen SAP Commerce Cloud, commercetools, Adobe Commerce, BigCommerce, Salesforce Commerce Cloud, plentysystems und Odoo, aber kein Shopware. Wer heute „Vue Storefront für Shopware“ plant, plant mit einem Stand von 2022.
Bestehende PWA-Projekte brauchen einen Migrationspfad auf Shopware Frontends, denn Nuxt 2 als Basis von Shopware PWA erhält laut nuxt.com seit dem 30. Juni 2024 keine Sicherheitskorrekturen mehr.
Composable wird es, wenn der Content aus einem eigenen System kommt. Shopware dokumentiert für Frontends die Anbindung von Storyblok, Strapi und Sanity und nennt Contentful, Hygraph und Builder.io als kompatibel. Empfohlen wird, dass das CMS redaktionelle Seiten liefert, Shopware Preise, Bestände und Checkout behält und die Erlebniswelten als Rückfallebene für Routen dienen, die das CMS nicht kennt.
Die Vorteile sind real, gelten aber nur, wenn das Projekt sie nutzt. Ein Headless-Frontend, das dieselbe Shop-Seite in einem anderen Stack nachbaut, hat keinen davon.
Die Nachteile stehen seltener in Artikeln, weil sie erst im Projekt sichtbar werden. Sechs Punkte sprengen erfahrungsgemäß die Budgets.
Die folgenden Zahlen sind Erfahrungswerte aus Agenturprojekten, keine Listenpreise. Die Lizenz von Shopware ändert sich durch Headless nicht: Community Edition 0 €, Rise ab 600 €, Evolve ab 2.400 € im Monat laut Preisseite. Was ein Shopware-Projekt insgesamt kostet, haben wir unter Shopware Kosten aufgeschlüsselt.
| Position | Storefront mit eigenem Theme | Headless-Frontend |
|---|---|---|
| Frontend-Umsetzung, einmalig | 5.000 bis 30.000 € (Theme) | 40.000 bis 120.000 €, selten darunter |
| Nachbau von Plugin-Oberflächen | entfällt | 10.000 bis 30.000 €, je nach Anzahl |
| Dauer bis zum Go-live | 6 bis 16 Wochen | 4 bis 9 Monate |
| Hosting im Monat | 50 bis 1.500 € für den Shop | Shop wie links, plus 50 bis 500 € für das Frontend |
| Wartung und Weiterentwicklung im Monat | 400 bis 2.500 € | 1.500 bis 5.000 € |
| Team im Betrieb | Shopware-Agentur reicht | Frontend-Entwickler (Vue oder React), Shopware-Entwickler, DevOps |
Die Spanne beim Frontend erklärt sich aus dem Pflichtumfang: Katalog, Suche, Warenkorb, Checkout, Kundenkonto, CMS-Rendering, Tracking, Consent und SEO braucht jeder Shop, egal wie klein er ist. Deshalb sinkt der Preis bei kleinen Shops kaum. Die üblichen Projektkosten für Shopware selbst, Schnittstellen und Datenmigration kommen hinzu.
Als Faustregel aus unseren Projekten: Unter rund 2 Mio. € Jahresumsatz oder ohne einen zweiten Kanal mit eigener Oberfläche trägt ein Headless-Frontend seine Kosten selten.

Abbildung: Die Grafik zeigt die einmaligen Frontend-Kosten je Variante; bei Headless kommt der Nachbau der Plugin-Oberflächen hinzu, deshalb rechnet sich der Weg meist erst mit einem zweiten Kanal. Erfahrungswerte solution25 aus Agenturprojekten, Stand Oktober 2026, zuzüglich MwSt.
Die Storefront von Shopware 6 ist eine serverseitig gerenderte Anwendung auf Twig, Bootstrap und SCSS, mit Theme-System, Erlebniswelten, Rule Builder und Flow Builder. Für die meisten Händler ist sie nicht die „alte“ Variante, sondern die mit dem besten Verhältnis von Funktion zu Kosten.
Zwischen Storefront und Vollausbau gibt es Zwischenstufen, die oft den gewünschten Effekt bringen. Eine Markenseite oder ein Magazin in Nuxt oder einem Headless CMS, während Katalog, Checkout und Konto in der Storefront bleiben. Eine App, die über die Store API bestellt, neben dem Webshop. Ein Konfigurator als Vue-Komponente innerhalb der Storefront.
Der Vorteil: Der Checkout mit allen Zahlungsarten, Rechtstexten und Plugins bleibt, wie er ist. Der Preis: Übergänge zwischen beiden Welten (Warenkorb, Anmeldung, Tracking) müssen sauber gelöst werden, sonst verlieren Kunden auf dem Weg ihren Warenkorb.
Aus Projekten und Anfragen der letzten Jahre haben sich fünf Muster herausgebildet, bei denen die Rechnung aufgeht.
Nicht dazu gehört der klassische B2C-Shop mit einigen tausend Produkten, einer Sprache und einem Kanal. Er wird durch Headless nicht schneller, nicht schöner und nicht umsatzstärker, nur teurer.
Foleja, ein grenzüberschreitender Marktplatz in Südosteuropa, läuft auf einer modularen Shopware-6-Architektur für mehrere Länder, Währungen und über 1.000 Verkäufer. Zum Projekt gehörten native Apps für iOS und Android mit synchronisierten Produkt-, Bestell- und Benachrichtigungsdaten, also ein zweiter Kanal mit eigener Oberfläche wie im ersten Muster oben.
Laut Case Study steigerten die Apps die Zahl der täglich aktiven Nutzer und die Wiederkaufrate, insgesamt lag die Conversion-Rate um 20 bis 30 Prozent höher. Der Fall zeigt, wo sich die Arbeit an Schnittstellen auszahlt: bei einem Kanal, den es ohne sie nicht gäbe.
| Kriterium | Storefront (Twig) | Hybrid | Headless (Frontends oder Next.js) |
|---|---|---|---|
| Budget für das Frontend | 5.000 bis 30.000 € | 15.000 bis 50.000 € | ab 40.000 € |
| Zeit bis zum Go-live | 6 bis 16 Wochen | 2 bis 5 Monate | 4 bis 9 Monate |
| Team im Betrieb | Shopware-Agentur | Agentur plus Frontend-Entwickler | Eigenes Team oder Agentur mit JavaScript-Schwerpunkt |
| Store-Plugins mit Oberfläche | Laufen sofort | Laufen in der Storefront, nicht im entkoppelten Teil | Müssen nachgebaut werden |
| Erlebniswelten | Vollständig, mit Vorschau | In der Storefront vollständig | Rendering über cms-base-layer, Vorschau selbst bauen |
| Zweiter Kanal (App, Terminal) | Über die Store API möglich, getrennt vom Webshop | Ja, das ist der Zweck | Ja, mit geteilten Komponenten |
| Designfreiheit | Hoch, innerhalb der Seitenstruktur | Hoch in den entkoppelten Teilen | Ohne Vorgaben |
| Risiko bei Updates | Theme und Plugins testen | Beides plus die Übergänge | Store-API-Änderungen testen, Frontend-Abhängigkeiten pflegen |
| Passt für | Die meisten B2C- und B2B-Shops | Content-Marken, Shops mit App | Multi-Channel, Multi-Brand, Portale, JavaScript-Teams |
Unsere Einschätzung: Ohne zweiten Kanal mit eigener Oberfläche raten wir von einem vollständigen Headless-Frontend ab und stecken das Budget lieber in Theme, Hosting und Plugin-Bereinigung. Kommt eine App, ein Portal oder ein weiterer Markenauftritt hinzu, empfehlen wir Shopware Frontends auf Nuxt, weil Shopware das Framework selbst pflegt und es die Erlebniswelten rendern kann. Wer schrittweise vorgehen will, lässt den Checkout zunächst in der Storefront, denn dort laufen Zahlungsarten, Rechtstexte und Plugins bereits.
Erheben Sie die Werte vier Wochen vor dem Wechsel als Basis, messen Sie in den ersten acht Wochen danach wöchentlich und anschließend monatlich.
Nachsteuern müssen Sie, wenn Klicks oder Conversion-Rate nach acht Wochen unter der Basis liegen, die Store API in Lastspitzen langsamer antwortet oder die Betriebskosten über einem Prozent des Umsatzes bleiben. Dann helfen meist Caching, fehlende Weiterleitungen oder ein schlankerer Funktionsumfang.
Headless Commerce, auch Headless E-Commerce genannt, trennt die Oberfläche eines Shops vom Shopsystem. Das Shopsystem liefert Produkte, Preise, Warenkorb und Bestellungen über Schnittstellen, die Oberfläche wird separat entwickelt und kann eine Website, eine App oder ein Terminal sein. Shopware 6 unterstützt das über die Store API. Für Shops in Österreich gilt dasselbe: Headless ist eine Architekturentscheidung, kein Muss.
Wörtlich „kopflos“. Der „Kopf“ ist die Präsentationsschicht, also das, was Kunden sehen. Ein Headless-System hat keinen fest verbundenen Kopf, sondern lässt sich mit jedem Frontend verbinden.
Shopware 6 ist API-first gebaut und damit headless-fähig, aber nicht ausschließlich headless. Die mitgelieferte Storefront nutzt intern dieselben Store-API-Routen, die ein eigenes Frontend verwenden würde. Sie entscheiden je Vertriebskanal, ob die Storefront oder ein eigenes Frontend die Oberfläche liefert.
Headless entkoppelt nur das Frontend vom Shopsystem. Composable Commerce setzt zusätzlich weitere Bausteine wie CMS, Suche oder Zahlung aus spezialisierten Diensten zusammen. Shopware verwendet beide Begriffe nebeneinander, für die Kalkulation ist Composable der deutlich größere Schritt.
Höhere Umsetzungskosten, zwei Systeme im Betrieb, Store-Plugins ohne Frontend-Teil, der Nachbau von Checkout, SEO und Consent sowie die dauerhafte Abhängigkeit von Frontend-Entwicklern. Wer diese Punkte nicht einplant, zahlt sie später im Betrieb.
Für das Frontend rechnen wir mit 40.000 bis 120.000 € Umsetzung, selten weniger, plus 10.000 bis 30.000 € für den Nachbau von Plugin-Oberflächen. Im Betrieb kommen 1.500 bis 5.000 € im Monat für die Pflege beider Systeme und 50 bis 500 € für das Frontend-Hosting hinzu. Diese Werte sind Erfahrungswerte aus Agenturprojekten, keine Listenpreise.
Die Backend-Logik ja, die Oberfläche nein. Ein Zahlungs-Plugin verarbeitet Zahlungen weiterhin über die Store API, sein Twig-Template und sein JavaScript erscheinen im eigenen Frontend aber nicht. Jedes Plugin mit Oberfläche muss im Frontend nachgebaut werden.
Nur mit Server-Side Rendering, korrekten Canonicals, Weiterleitungen und einer Sitemap. Dann rankt ein Headless-Frontend wie jede andere Seite und profitiert von kurzen Ladezeiten. Ohne diese Arbeit verliert ein Shop beim Wechsel die Rankings, die er mit der Storefront hatte.
Wir betreuen Onlinehändler in Österreich und Deutschland. Sie planen ein eigenes Frontend, eine App oder einen zweiten Kanal auf Shopware und möchten vorher wissen, was das kostet und ob die Storefront nicht ausreicht? Schreiben Sie uns. Wir prüfen Plugins, Kanäle und Team und sagen Ihnen auch, wenn Headless für Sie die teurere Lösung ohne Mehrwert wäre.
Sie betreiben bereits einen Shop und überlegen, ob Ladezeit oder Design ein neues Frontend rechtfertigen? Unsere kostenlose Shop-Analyse zeigt, wo der aktuelle Shop Umsatz verliert und ob ein Headless-Projekt oder eine Optimierung der Storefront der bessere Weg ist.
Mehr über unsere Arbeitsweise, Zertifizierungen und Standorte lesen Sie auf der Seite Shopware Agentur solution25.

Besnik Bilalli ist Gründer und CEO von solution25, der Shopware Agentur aus Bremen. Vor der Agenturgründung 2017 hat er selbst einen Online-Shop aufgebaut und auf mehr als 500 Bestellungen am Tag gebracht. Seitdem begleitet er Händler bei Shopware-Projekten, von der ersten Kalkulation bis zum laufenden Betrieb. Fragen zum Artikel beantwortet er gern persönlich: Kontakt aufnehmen.
Verantwortlich für Inhalt und Aktualisierung: Besnik Bilalli. Stand: Oktober 2026. Nächste inhaltliche Prüfung: Jänner 2027.