Unklares Ziel
„Moderner“ oder „schneller“ ist kein Grund für eine neue Architektur. Ohne messbares Ziel lässt sich nicht prüfen, ob sich der Umbau gelohnt hat.
Headless Commerce
Headless Commerce mit Shopware — wenn ein eigenes Frontend den Aufwand wert ist.
Wir klären mit Ihnen, ob ein eigenes Frontend über die Store API Ihrem Shop etwas bringt, das die Shopware-Storefront nicht kann — und setzen es um, wenn ja. Mit gemessenen Grenzen der Schnittstelle statt Architekturdiagrammen aus dem Prospekt.
Shopware-Partner seit 2014Shopware Bronze & Extension PartnerMittelstand & B2B
Pixup Media
Strategie. Technik. Marketing. Aus einer Hand.
- Store API gegen 20 Handelsfunktionen geprüft
- Entscheidung vor Umsetzung
- SEO im Frontend von Anfang an
Ausgangslage
Headless wird oft entschieden, bevor klar ist, welches Problem es lösen soll.
Ein eigenes Frontend kann einen Shop schneller, flexibler und besser in andere Kanäle eingebunden machen. Es verlagert aber auch Arbeit, die die Storefront heute still erledigt, in Ihr eigenes Projekt.
Unterschätzte Eigenleistung
Routing, Rendering, Formulare, Fehlerseiten, SEO-Ausgaben — alles, was die Storefront mitbringt, muss das eigene Frontend selbst können.
Plugins ohne Schnittstelle
Viele Erweiterungen bringen nur Storefront-Templates mit. Im Headless-Betrieb fehlt dann ihre Oberfläche — und manchmal ihre Funktion.
Leistungsumfang
Was wir übernehmen.
Vom Workshop, der die Entscheidung trifft, bis zum Betrieb des fertigen Frontends — oder nur den ersten Teil, wenn die Antwort lautet, dass die Storefront reicht.
Architektur-Workshop
Ziele, Kanäle, Inhalte, vorhandene Plugins. Ergebnis ist eine begründete Empfehlung: Storefront, Storefront mit eigenen Teilen oder Headless.
Store-API-Anbindung
Kontext, Warenkorb, Kundenkonto, Checkout, Listing und Suche über die Store API. Mit Prüfung, welche Ihrer Plugins eigene Schnittstellen haben.
Frontend
Auf Basis von Shopware Frontends oder einem eigenen Framework — je nachdem, was Ihr Team später pflegen kann.
SEO im Frontend
Serverseitiges Rendern, Canonicals, Sitemap, strukturierte Daten, Weiterleitungen. Was die Storefront ab Werk ausgibt, muss im eigenen Frontend neu entstehen.
Betrieb
Hosting des Frontends, Caching, Überwachung und Updates beider Teile — Shopware und Frontend haben eigene Versionszyklen.
Was Headless bei Shopware heißt
In der Standard-Storefront liefert Shopware Daten und fertige Seiten aus einer Hand. Headless heißt: Shopware liefert nur noch Daten über die Store API, und ein eigenes Frontend baut daraus die Seiten. Die Handelslogik — Preise, Regeln, Warenkorb, Bestellung — bleibt in Shopware. Alles, was mit Darstellung zu tun hat, wandert ins Frontend.
Das ist kein Schalter, sondern ein zweites Softwareprojekt neben dem Shop. Es lohnt sich, wenn es etwas ermöglicht, das die Storefront nicht kann. Es lohnt sich nicht, wenn es nur ein Problem lösen soll, das sich in der Storefront günstiger beheben lässt.
Was die Store API kann — gemessen
Bevor man sich für Headless entscheidet, ist die wichtigste Frage, ob die Schnittstelle alles hergibt, was der Shop braucht. Wir haben das in Shopware 6.7.13.1 an zwanzig vorab festgelegten Storefront-Funktionen geprüft, jeweils mit einem echten Aufruf gegen die Store API (zur Messung):
| Bereich | Ergebnis |
|---|---|
| Kategorie, Listing, Produkt, Suche, Suchvorschlag, Navigation | erreichbar |
| Warenkorb lesen und füllen, Versand- und Zahlarten | erreichbar |
| Registrierung, Anmeldung, Newsletter, Kontaktformular | erreichbar |
| Captcha für Formulare | keine Store-API-Route |
Geprüft war, dass jeder Endpunkt antwortet, nicht, dass er Feld für Feld dasselbe liefert wie die Storefront-Seite. Der Bestellabschluss war nicht Teil der Stichprobe. Und die Installation hatte neun Plugins — Ihre Plugins können eigene Routen mitbringen oder eben keine.
Wo der eigentliche Aufwand liegt
Nicht in fehlenden Endpunkten, sondern im Frontend selbst. Zustand des Warenkorbs, Routing für Kategorien und Produkte, Fehlerseiten, Weiterleitungen, Formularschutz — und alles, was Suchmaschinen sehen: Canonicals, strukturierte Daten, Sitemap, hreflang bei mehreren Sprachen. Die Storefront gibt das ab Werk aus. Ein eigenes Frontend muss es neu bauen, sonst verliert der Shop beim Umstieg Sichtbarkeit.
Die Entscheidung vor der Umsetzung
Deshalb beginnen wir mit einem Workshop, nicht mit einem Framework. Am Ende steht eine von drei Antworten: Die Storefront reicht. Die Storefront bleibt, einzelne Bereiche bekommen ein eigenes Frontend. Oder der Shop wird headless — mit einer Liste dessen, was das neue Frontend selbst leisten muss, und einer Prüfung jedes Plugins.
Headless verschiebt Arbeit vom Shop ins Frontend. Es lohnt sich, wenn diese Arbeit etwas ermöglicht, das vorher nicht ging.
Für wen geeignet
Wann Headless passt — und wann nicht.
Passt zu Ihnen, wenn
Passt, wenn …
- Sie bespielen neben dem Shop weitere Kanäle — App, Terminal, Kundenportal — aus denselben Daten
- Ihr Frontend-Team arbeitet bereits mit einem JavaScript-Framework und soll den Shop selbst gestalten
- Inhalte und Einkauf sollen in einer Oberfläche zusammenlaufen, die die Storefront nicht abbildet
- Sie haben ein messbares Ziel, das die Storefront nachweislich nicht erreicht
Eher nicht das Richtige, wenn
Eher nicht, wenn …
- Der Shop soll vor allem schneller werden — das gelingt meist günstiger in der Storefront
- Viele Ihrer Plugins haben nur Storefront-Templates und keine Schnittstelle
- Niemand im Team kann ein eigenes Frontend dauerhaft pflegen
Vorgehen
So gehen wir vor.
- 01
Ziel und Bestand
Welche Kanäle, welche Inhalte, welche Plugins. Welche messbare Verbesserung soll das neue Frontend bringen?
- 02
Prüfen
Je Plugin und Sonderfunktion: Gibt es eine Store-API-Route oder muss sie gebaut werden? Wo liegen die Lücken?
- 03
Entscheiden
Mit der Liste der Eigenleistungen auf dem Tisch. Lautet die Antwort Storefront, sparen Sie den Umbau.
- 04
Umsetzen und betreiben
Frontend, Anbindung, SEO-Ausgaben, Tests gegen die Store API, Übergabe und laufende Betreuung.
Ergebnis
Was Sie am Ende haben.
- Eine begründete Architekturentscheidung mit der Liste, was das eigene Frontend selbst leisten muss
- Eine Prüfung Ihrer Plugins auf Store-API-Tauglichkeit
- Bei Umsetzung: Frontend mit Store-API-Anbindung, SEO-Ausgaben und Formularschutz
- Dokumentation der Schnittstellen und ein Betriebskonzept für beide Teile
FAQ
Fragen zu Headless mit Shopware
Weiterlesen
Was hinter der Entscheidung steckt.
Verwandte Leistungen
Aus unserer Praxis
- Eigene Messung
Zwanzig Storefront-Funktionen gegen die Store API
20 von 20 erreichbar, eine echte Lücke.
- Wissen
Store API oder Admin API?
Welche Schnittstelle wofür gedacht ist.
- Wissen
Die Grenzen der beiden Shopware-APIs
Was keine der beiden Schnittstellen kann.
- Eigene Messung
Core Web Vitals in Shopware-Shops
51 Startseiten im Labor gemessen.
Aus dem Pixup Magazin
Lassen Sie uns sprechen
Erst die Entscheidung, dann das Frontend.
Schreiben Sie uns, welche Kanäle Ihr Shop bedienen soll und welche Plugins laufen. Wir melden uns zeitnah bei Ihnen und sagen, ob sich ein Architektur-Workshop lohnt. Das Erstgespräch ist kostenfrei.
Wir melden uns zeitnah bei Ihnen.Persönlicher AnsprechpartnerKostenfreies Erstgespräch