Storyblok ist ein Headless CMS. Shopware ist eine Commerce-Plattform. Getrennt sind sie beide stark. Zusammen bauen sie etwas, das im E-Commerce nicht oft zu sehen ist: eine echte Trennung zwischen Content und Commerce, ohne dass man etwas aufgibt.
Die Kombination Storyblok plus Shopware macht nicht für jeden Sinn. Aber für bestimmte Projekte ist sie unschlagbar. Wir setzen solche Integrationen im DACH-Raum um und sagen dir hier, wann die Kombi passt und wie es konkret funktioniert.
Inhalt
- Was Storyblok und Shopware trennt
- Wie die beiden zusammenarbeiten
- Der Visual Editor macht den Unterschied
- Technische Architektur: Nuxt als Brücke
- Wann lohnt sich die Kombination?
- Performance und SEO Vorteile
- Wieviel kostet so ein Setup?
Was Storyblok und Shopware trennt
Das klingt banal, aber es ist essentiell: Storyblok verwaltet Content. Shopware verwaltet Commerce.
Shopware alleine: Das CMS ist in Shopware eingebaut. Du kannst Kategorieseiten, Landingpages, Blog-Inhalte direkt in der Admin-Oberfläche editieren. Das ist praktisch für kleine Seiten, aber für größere Inhaltsmengen schnell eng. Shopwares CMS-Funktionen sind auf das ausgelegt was die Plattform gut kann: Produktseiten, Checkout, einfache Kampagnenseiten.
Storyblok alleine: Das ist ein echtes Headless CMS ohne Commerce-Features. Es gibt dir einen Visual Editor, Versionskontrolle, Mehrsprachenmanagement. Was es nicht hat: Produkte, Warenkörbe, Checkout. Das ist nicht sein Job.
Die Kombination: Storyblok kümmert sich um alles was mit Content zu tun hat. Landingpages, Blog, Kategorieseiten, SEO-Texte, alles mit Visual Editor. Shopware kümmert sich um Commerce: Produkte, Preise, Verfügbarkeit, Warenkorb, Checkout. Dazwischen eine API-Verbindung die beide miteinander verbindet.
Das ist sauberer als das, was die meisten E-Commerce-Seiten bauen. Es ermöglicht größeren Content-Teams zu arbeiten, ohne dass sie sich in Commerce-Logik verheddern. Und es ermöglicht schnellere Änderungen ohne dass jede Landingpage-Anpassung durch einen Developer gehen muss.
Wie die beiden zusammenarbeiten
Die technische Brücke ist die API. Nicht die Web-Oberfläche, nicht eine Integration über Plugins, sondern reine API-Kommunikation.
So sieht es aus:
Storyblok speichert die Inhalte als strukturierte Daten. Eine Landingpage für "Winter Sale" ist nicht HTML, sondern ein Datenmodell mit Blöcken: Hero-Image, Produktgrid, Text, CTA. Jeder Block hat definierte Felder.
Frontend (meistens Nuxt, seltener Next.js) holt sich zur Laufzeit die Inhalte von Storyblok und die Produktdaten von Shopware. Beides wird zusammengebracht und gerendert.
Beispiel: Eine Kategorie-Landingpage für "Sportschuhe" sieht so aus:
- Storyblok liefert den Text, das Hero-Image, die Kategorieüberschrift, SEO-Meta-Daten
- Shopware liefert die Produkte dieser Kategorie, Verfügbarkeit, Preise
- Das Frontend kombiniert beides in einer Seite
Das Wichtige: Das passiert auf Anfrage, nicht im Voraus. Storyblok muss nicht wissen wie Shopware funktioniert. Shopware muss nicht wissen dass es Storyblok gibt. Das Frontend ist der Orchestrator.
Diese Entkopplung ist der Grund warum das Modell funktioniert. Content-Updates in Storyblok brauchen keine Shopware-Deployment. Produktpreis-Anpassungen in Shopware brauchen keine Content-Änderung. Für Shops die von einem Monolith auf dieses Setup wechseln, lohnt ein Blick auf unsere Replatforming-Leistung.
Der Visual Editor macht den Unterschied
Das technische Modell ist elegant. Aber was davon echten Nutzen hat ist etwas anderes: der Visual Editor.
In Shopwares Standard-CMS editierst du eine Landingpage im Admin und siehst ein Seitengerüst mit Feldern. Das ist funktional, aber nicht das was Marketing-Teams brauchen.
Im Storyblok Visual Editor editierst du die Seite so wie sie am Ende aussieht. Du siehst live wie der Text sitzt, wie die Bilder wirken, wie die CTAs platziert sind. Kein "speichern und auf der Live-Seite nachschauen". Der Editor ist WYSIWYG wie es sein sollte.
Das klingt nach Kleinigkeit, aber es verändert die Arbeit massiv. Marketing-Teams, Content-Redakteure, auch Product Manager können eigenständig Content-Seiten bauen und anpassen. Das ist bei Storyblok Standard. Bei Shopware ist das nicht die Stärke.
Ein Beispiel aus unseren Projekten: Bei ARMEDANGELS war die Kampagnen-Seite früher ein 2-Stunden-Job für einen Developer (Content kopieren, Layout anpassen, Deploy, Testing). Mit Storyblok ist es jetzt ein 30-Minuten-Job für den Content-Manager. Das ist nicht nur schneller. Das ist ein anderes Modell.
Technische Architektur: Nuxt als Brücke
Wenn du diese Kombination baust, brauchst du eine Schicht dazwischen. Das Frontend.
Nuxt 3 ist hier der Standard bei unseren Projekten. Das liegt daran dass Nuxt beides kann: Statische Seiten generieren (für Performance und SEO) und dynamische Inhalte (für Shop-Logik) parallel bedienen.
So funktioniert es:
- Storyblok API liefert Inhaltsblöcke als JSON
- Shopware API liefert Produktdaten, Preise, Warenkorb-Logik
- Nuxt kombiniert beides, rendert HTML auf dem Server
- Ergebnis ist eine schnelle, SEO-freundliche Seite die trotzdem dynamische Commerce-Features hat
Das ist nicht einfach zu bauen. Du brauchst:
- API-Layer im Frontend der beide APIs anspricht
- Caching-Strategien (Storyblok-Inhalte ändern sich selten, können statisch generiert werden; Shopware-Daten sind dynamisch, müssen live sein)
- Error-Handling falls eine API ausfällt
- Authentifizierung für den Shopware-Zugriff
Das ist kein Low-Code-Setup. Es ist Custom-Development. Die Frage ist: wann lohnt sich der Aufwand?
Wann reicht Shopware CMS allein?
Das ist die erste Frage die du stellen solltest: Wie viel machst du tatsächlich mit dem CMS? Im Daily Business, nicht in Projekten.
Die Faustregel: Wenn dein Content-Bedarf unter 30% liegt, reicht Shopware.
Shopware CMS reicht wenn:
- Du regelmäßig nur Banner, Hero-Bilder und Kategorie-Texte änderst (monatlich oder weniger)
- Deine Inhalte sind primär produktorientiert, nicht Story-fokussiert
- Dein Team arbeitet eher mit Produkten als mit Content-Seiten
- Mehrsprachigkeit ist einfach strukturiert
- Freigabeprozesse sind nicht kritisch (oder dein Team ist klein)
Spar dir das Setup. Shopware CMS funktioniert dafür und es ist einfach.
Shopware CMS wird zu eng wenn:
- Du hast 50+ Content-Seiten mit verschiedenen Layouts
- Du brauchst echte redaktionelle Workflows (mehrere Redakteure, Freigabeprozesse)
- Content ändert sich täglich oder mehrmals pro Woche
- Du willst dass das Marketing-Team ohne Developer arbeiten kann
- Du hast mehrsprachige Varianten mit regionalen Unterschieden
Das ist dann der Punkt wo Storyblok sinnvoll wird, nicht weil Shopware "schlecht" ist, sondern weil Storyblok spezialisiert ist.
Wann brauchst du Storyblok dazu?
Storyblok wird relevant wenn sich die Aufgabe ändert:
- Viele Seiten: Du hast 100+ Content-Seiten, nicht nur Kampagnen
- Viel Content: Täglich oder mehrmals pro Woche Änderungen
- Viele Updates: Saisonale Kampagnen, A/B-Tests, regelmäßige Inhalts-Aktualisierungen
- Viel Redaktion: Blog mit mehreren Autoren, unterschiedliche Content-Formate
- Freigabeprozesse: Content muss genehmigt werden bevor es live geht
- Großes Team: Marketing, Redaktion, Designer arbeiten zusammen ohne Developer
Die Entscheidung hängt vom täglichen Betrieb ab. Nicht von dem was irgendwann schön wäre. Was machst du wirklich regelmäßig?
Bei Fischer Sports war das klare Entscheidungskriterium: 50+ Sportarten-Seiten mit eigenem Content, Design, Messaging, mehrmals wöchentliche Updates. Das brauchte ein echtes Content-System. Mit Shopware alleine wäre das zäh geworden. Mit Storyblok ist es wartbar.
Performance und SEO Vorteile
Das technische Modell bringt Performance mit sich, nicht weil die Technologien magisch sind, sondern weil die Architektur es erlaubt.
Caching: Storyblok-Inhalte ändern sich selten. Du kannst statische Seiten generieren, das heißt HTML wird zur Deploy-Zeit gebaut, nicht zur Request-Zeit. Das ist nicht "dynamisch", aber es ist sehr schnell. Shopware-Daten (Produkte, Verfügbarkeit) sind dynamisch, die musst du live laden. Mit Nuxt kannst du beides haben: statische Content-Seiten und dynamische Commerce-Logik auf der gleichen Seite.
Separation of Concerns: Shopware-Updates betreffen nicht dein Frontend. Frontend-Änderungen brauchen keine Shopware-Neuinstallation. Das reduziert Deployment-Risiko und macht Updates schneller.
SEO: Headless-Setups mit Nuxt sind SEO-freundlich wenn es richtig gebaut wird. Server-Side Rendering (SSR) ist Standard, Meta-Tags werden korrekt gesetzt, Open Graph funktioniert, JSON-LD für strukturierte Daten ist möglich. Das funktioniert auch mit Storyblok alleine, aber mit Shopware dazwischen musst du es bewusst bauen.
Ein reales Szenario: Eine Kategorie-Seite wird nicht jedes Mal neu gerendert. Der HTML wird einmal pro Stunde oder Tag generiert (abhängig wie oft Inhalte sich ändern). Der Server muss nur die Produktliste von Shopware laden und in den gecachten HTML einbinden. Das ist schneller als dass Shopware jedes Mal eine vollständige Seite rendert.
Die Core Web Vitals Scores sind typischerweise höher bei solchen Setups, wenn die Caching-Strategie stimmt.
Wieviel kostet so ein Setup?
Das ist die unbequeme Frage.
Es gibt kein einfaches "Storyblok + Shopware kostet X". Das Setup hat vier Kostenblöcke:
1. Shopware (laufend)
- Lizenz: 0 EUR (Open Source Community Edition) bis Enterprise (zum aktuellen Zeitpunkt auf der Shopware-Website)
- Hosting: 200+ EUR/Monat je nach Infrastruktur
- Support/Wartung: 2.000+ EUR/Monat
2. Storyblok (laufend)
- Lizenzen: Aktuelle Preise zum aktuellen Zeitpunkt auf der Storyblok-Website
- Höhere Stufen bei viel Content oder vielen Nutzern
3. Frontend (initial)
- Ein individuelles Nuxt-Frontend von Grund auf: 50.000+ EUR
- Das ist nicht optional. Du brauchst das um die beiden zusammenzubringen.
- Bei uns dauert so ein Projekt meistens 6-12 Monate je nach Komplexität.
4. Laufende Entwicklung
- 2-4 Senior Developer zur Wartung und Weiterentwicklung
- 8.000+ EUR/Monat
Das ist nicht günstig. Das ist für Projekte mit echtem Budget. Typischerweise spricht man hier von: Marken mit vielen Integrationen, mehrsprachige Shops, große Content-Teams, B2B-Komplexität.
Wenn es um B2B auf Shopware geht: Schau dir auch b2b-sellers.com an. Eine interessante Alternative für spezifische B2B-Anforderungen. Bei Interesse melde dich bei uns.
Wenn dein Budget unter 100.000+ EUR liegt, ist ein individuelles Frontend meistens nicht die Antwort. Dann brauchst du eine Theme-basierte Lösung oder eine andere Plattform.
Die Frage ist immer: Was ist deine Alternative? Wenn die Alternative "Shopware alleine mit Custom-Development für große Content-Mengen" ist, dann ist Storyblok + Shopware oft günstiger. Wenn die Alternative "ein Theme nehmen" ist, dann ist es teurer.
Fazit: Die richtige Architektur für die richtige Aufgabe
Storyblok und Shopware zusammen sind nicht die Lösung für jeden Shop. Sie sind die Lösung für Projekte die zwei Probleme haben: Sie brauchen ernsthaftes Content-Management mit vielen Seiten, Sprachen, Änderungen. Und sie brauchen ernsthaften E-Commerce mit Produkten, Preisen, Verfügbarkeit.
Wenn du nur eins von beidem hast, brauchst du das nicht.
Wenn du beides hast und es wächst, wird es irgendwann zu klein für Shopwares CMS. Dann wird eine Entkopplung interessant. Nicht weil Storyblok magisch ist, sondern weil eine Trennung klarer ist. Content-Teams können schneller arbeiten. Developer brauchen nicht auf Content-Änderungen warten. Die Fehlerrate sinkt weil die Systeme weniger gekoppelt sind.
Das ist Architektur. Nicht Hype.