Storyblok ist eines der Headless-CMS-Systeme die wir am häufigsten für unsere Kunden einsetzen. Nicht weil es die "beste" Lösung ist, sondern weil es für bestimmte Use Cases einfach passt. Besonders der Visual Editor macht es zum echten Vorteil für Teams bei denen Marketing und Entwicklung nicht zusammen im selben Slack-Channel sitzen.
Wir haben mit Storyblok über 20 Projekte umgesetzt. Mit ARMEDANGELS, Fischer Sports, und anderen Kunden die Content-Management auf Enterprise-Level brauchten, aber nicht in einer gigantischen selbstgehostetem Komplexität versinken wollten. Hier ist, was wir gelernt haben.
Inhalt
- Was ist Storyblok eigentlich?
- Der Visual Editor: Das Killer-Feature
- Storyblok plus Shopware: So funktioniert die Integration
- Storyblok plus Shopify Hydrogen: Alternative Kombination
- Performance und SEO: Headless-Vorteile richtig nutzen
- Wann Storyblok Sinn macht und wann nicht
- Was kostet Storyblok?
- Fazit
Was ist Storyblok eigentlich?
Storyblok ist ein Headless CMS aus Österreich. Das heißt: Content-Management getrennt vom Frontend. Nicht wie WordPress wo CMS und Website zusammengewachsen sind. Storyblok verwaltet nur den Content. Was damit passiert, bestimmst du.
Das Backend ist ein REST und GraphQL API. Du baust ein Frontend (Nuxt, Next.js, React, Vue, whatever) und fragst Storyblok über die API ab wann du einen Content-Block brauchst. Storyblok liefert die Daten, dein Frontend rendert sie.
Das hört sich umständlich an. Ist es aber nicht. Was Headless Commerce grundsätzlich bedeutet und wann es sich lohnt, erklären wir in unserem separaten Artikel. Weil Storyblok zwei Dinge besonders gut macht:
- Einfache Content-Modellierung. Du definierst Content-Blöcke (Components heißen die bei Storyblok) und Storyblok generiert dir automatisch die API-Struktur. Nicht wie bei API-first-Systemen wo du erst ein gigantisches Schema designen musst bevor du überhaupt eine Seite schreiben kannst.
- Echtzeit-Vorschau. Jede Änderung im Visual Editor siehst du sofort im Frontend. Nicht ein Warten auf Build-Prozesse, nicht eine Produktionsumgebung-Änderung. Edit. Siehe das Ergebnis. Publish.
Das ist nicht das Modell klassischer Headless CMS wie Contentful oder Sanity. Die sind mehr für API-first-Workflows. Storyblok ist eher das CMS das zwischen klassischen CMSs und echten Headless-Systemen sitzt. Das beste aus beiden Welten? Manchmal ja, manchmal auch die Kompromisse aus beiden.
Der Visual Editor: Das Killer-Feature
Der Visual Editor ist der Grund warum viele unserer Kunden sich für Storyblok entscheiden.
Klassisches Szenario: Du hast eine E-Commerce-Site mit individuellen Landingpages. Jede Landingpage ist anders aufgebaut. Headers, Text-Blöcke, Product-Teasers, Testimonials, verschiedene Layouts. Bisher musste jede Änderung durch einen Entwickler gehen. "Kannst du den Hero-Text groß machen und eine Testimonial-Section hinzufügen?"
Mit Storyblok: Der Marketing-Manager öffnet die Seite im Visual Editor, sieht genau wie sie aussieht, und klickt zusammen. Neue Block hinzufügen, existierende Blöcke verschieben, Text editieren, Bilder hochladen. Das funktioniert wirklich intuitiv. Es ist nicht "wir haben ein CMS" sondern "wir haben ein Werkzeug das Marketing-Leute ohne Developer verstehen".
Das spart Zeit. Viel Zeit. Und es ist nicht nur schneller. Es ist auch billiger. Weil dein Developer nicht auf jede Content-Anfrage reagieren muss.
Bei ARMEDANGELS haben wir genau das implementiert. Campaign-Landingpages, Saison-Kampagnen, Product-Story-Seiten. Alles über Storyblok. Der Content-Manager der Marke hat Zugriff auf den Visual Editor. Die meisten Änderungen laufen ohne Developer.
Das ist das echte Argument für Storyblok. Nicht die Technologie (andere Headless CMS sind technisch genauso gut). Sondern dass Marketing-Teams damit arbeiten können wie mit einem modernen Design-Tool, nicht wie mit einem Code-Editor.
Storyblok plus Shopware: So funktioniert die Integration
Das klassische Setup bei uns: Shopware als Commerce-Engine. Storyblok als Content-Management. Dazwischen ein Nuxt 3 Frontend (oder Next.js, je nach Anforderung).
Die Architektur sieht so aus:
- Storyblok verwaltet die Landingpages, Kampagnen-Content, SEO-Texte, alles was nicht direkt Produkt-Katalog ist.
- Shopware verwaltet Produkte, Kategorien, Preise, Bestände, Shopping-Cart, Checkout.
- Das Frontend fragt Storyblok über die API ab was auf der Seite sein soll. Und fragt Shopware über die Storefront API ab welche Produkte wo gehören.
Das Gute: Beide Systeme wissen nichts voneinander. Shopware ändert seine Struktur. Storyblok weiß nix davon, muss nix angepasst werden. Storyblok bekommt ein neues Feature. Shopware ist nicht betroffen.
Konkret funktioniert das so. Der Marketing-Manager erstellt eine Landingpage für eine Sommer-Kampagne in Storyblok:
- Visual Editor: "Ich brauche einen Hero mit Background-Bild"
- "Darunter eine 4er-Grid von Produkten"
- "Und am Ende eine CTA zum Newsletter"
Der Developer hat vorher die Komponenten definiert. Was heißt "4er-Grid von Produkten"? Das ist ein Storyblok-Component mit einem relationalen Link zu Shopware-Produkten. Der Editor klickt die vier Produkte zusammen, speichert.
Das Frontend rendert die Seite:
- "Hol mir von Storyblok diese Seite"
- Storyblok: "Hier, die Seite hat folgende Struktur und diese Komponenten"
- Frontend sieht "4er-Grid, Produkt-IDs: 123, 456, 789, 1011"
- Frontend sagt zu Shopware: "Gib mir die Daten zu diesen Produkt-IDs"
- Shopware liefert Produktname, Bild, Preis, Verfügbarkeit
- Frontend rendert die finale Seite
Das ist nicht überkompliziert, aber es ist auch nicht "Seite editieren und gut". Es braucht ein Team das diese Struktur versteht. Frontend-Developer der die Komponenten schreibt. Und jemand der Storyblok-Blöcke mit Shopware-Datenquellen verknüpft.
Wir haben das bei Fischer Sports gemacht. Eine Sport-Ausrüstungs-Marke mit 30+ Kampagnen-Landingpages pro Jahr. Storyblok für die Kampagnen-Struktur, Shopware für die Produkte. Das läuft seit 3 Jahren ohne dass Marketing und Tech sich in den Haaren liegen.
Storyblok plus Shopify Hydrogen: Alternative Kombination
Storyblok funktioniert genauso gut mit Shopify. Und genauso gut mit Shopify Hydrogen (Shopifys neuem Headless-Framework).
Die Logik ist identisch. Nur dass statt Shopware Storefront API jetzt Shopify GraphQL API kommt. Die Unterschiede sind marginal wenn man es übergeordnet betrachtet.
Wo das interessant wird: Wenn du ein relativ einfaches Shopify-Setup hast, aber Content-Management auf Enterprise-Level brauchst. Sagen wir, du betreibst einen Beauty-Shop mit Standard-Shopify, aber du hast monatliche Kampagnen mit individuellen Landing-Pages, komplexem SEO-Fokus, verschiedenen Zielgruppen-Versionen.
Shopify Blog ist für sowas nicht ausgelegt. Du könntest das mit Custom-Sections lösen. Oder du kombinierst Shopify mit Storyblok. Shopify kümmert sich um den Shop. Storyblok um die Content-Strategie.
Das ist nicht das Standard-Shopify-Playbook. Aber für Marken die Shopify's Einfachheit brauchen und trotzdem komplexes Content-Management wollen, ist es elegant.
Performance und SEO: Headless-Vorteile richtig nutzen
Headless hat theoretisch Performance-Vorteile. Praktisch nur wenn man's richtig macht.
Die Theorie: Frontend und Backend getrennt. Frontend kann auf separaten Servern leben, näher beim User. Backend kann zentralisiert sein. Content liefert schneller, Seite rendert schneller.
Die Praxis sieht oft anders aus. Viele Headless-Setups sind langsamer als monolithische Lösungen, weil sie zu viele API-Calls machen. Seite lädt, fragt Storyblok, fragt Shopware, fragt vielleicht noch 2-3 andere Services. Das summiert sich.
Das Trick ist: Caching und Prerendering.
Storyblok liefert einen Webhook. Immer wenn Content geändert wird, sagt Storyblok Bescheid. Dein Frontend kann dann statisch neu bauen (Incremental Static Regeneration oder Static Generation). Die Seite ist dann nicht dynamisch, sondern es ist ein schneller Static HTML File.
Das ist ein echter Vorteil für SEO. Google crawlt statische Seiten schneller. Lighthouse-Scores sind besser. Konversionsraten steigen (schnelle Seiten konvertieren besser).
Bei unseren Storyblok-Projekten sehen wir durchschnittlich:
- Core Web Vitals über 90 Punkte
- Seitenload unter 1.5 Sekunden (bei guten Internets)
- First Contentful Paint unter 800ms
Das ist möglich weil wir nicht naiv bei jedem Seitenaufruf APIs abfragen, sondern wir Seiten vorbauen und am Edge-CDN (Vercel, Netlify) deployen.
SEO-technisch: Storyblok-Seiten sind wie statische Seiten schnell. Das mögen Google und auch User. Im Vergleich zu klassischen CMS-Systemen ist das deutlich schneller.
Wann Storyblok Sinn macht und wann nicht
Die ehrliche Einschätzung: Storyblok ist nicht für alle Projekte richtig.
Storyblok macht Sinn wenn:
- Shopware/Shopify CMS reicht NICHT. Das ist die erste Frage. Shopware hat ein CMS. Wenn das ausreichend ist, brauchst du nicht Storyblok. Aber wenn dein Content-Bedarf über 30% liegt und du echte redaktionelle Workflows brauchst (Freigabeprozesse, mehrere Redakteure), wird es eng.
- Dein Team soll ohne Developer arbeiten können. Der Visual Editor ist das Killer-Feature. Content Manager, Designer, Marketing, alle können damit arbeiten. Das zahlt sich aus nur wenn wirklich Leute damit arbeiten (nicht "irgendwann mal schön wäre").
- Dein Content ist strukturiert und komponentenbasiert. Landing-Pages, Kampagnen, Product-Stories. Kombinationen aus wiederverwendbaren Blöcken.
- Du hast mehrere Frontends. Ein Storyblok-Setup für Web, App, Email. Ein CMS, mehrere Konsumenten.
- Du planst langfristig (5+ Jahre) und regelmäßige Content-Updates. Sonst zahlt sich die Komplexität nicht aus.
Storyblok macht NICHT Sinn wenn:
- Shopware/Shopify CMS reicht für deine Anforderungen. Dann sparen wir Komplexität.
- Dein Team ist technisch und will Content per API/Code managen. Dann ist Strapi oder ein selbstgehostetes CMS besser.
- Content ändert sich selten (weniger als 1x pro Monat). Dann zahlt sich der Visual Editor nicht aus.
- Dein Budget ist unter 30.000+ EUR total. Storyblok braucht Custom-Entwicklung und lohnt sich nicht bei kleinem Budget.
- Du brauchst "alles in einem System" (Commerce + Content). Dann ist Shopware/Shopify Standard besser.
Das ehrliche Fazit: Storyblok ist richtig für Organisationen die echte Content-Anforderungen haben und investieren wollen. Nicht für jeden Shop.
Was kostet Storyblok?
Storyblok selbst hat ein Abo-Modell:
- Free Plan: Für kleine Projekte oder Tests. Kostenlos, mit Einschränkungen bei Benutzern und API-Calls.
- Bezahlte Pläne: Staffelung nach Benutzern und API-Calls, vom Basis-Plan bis Enterprise. Aktuelle Preise direkt bei Storyblok.
- Enterprise: Custom Pricing für unbegrenzte Anforderungen.
Das ist moderat im Vergleich zu anderen Headless CMS. Contentful kostet mehr. Sanity ähnlich.
Der eigentliche Kostentreiber ist nicht Storyblok selbst, sondern die Umsetzung. Ein Storyblok-Projekt braucht:
- Frontend-Entwicklung. Das Framework (Nuxt, Next.js, etc.) das mit Storyblok spricht. Das ist nicht billig. 30.000+ EUR für ein gutes Setup.
- Content-Modellierung. Jemand der die Blöcke definiert. Was ist eine "Hero Section"? Welche Felder braucht sie? Das ist ein Analyse-Schritt.
- Integrationen. Wenn Storyblok mit Shopware/Shopify sprechen soll, braucht es Custom-Code der die APIs verknüpft.
- Hosting. Das Frontend muss gehostet werden. Vercel oder Netlify haben gute Headless-Pläne. Zum aktuellen Zeitpunkt ab 50+ EUR/Monat je nach Traffic.
Die typischen Kosten für ein Storyblok-Projekt bei uns:
- Einfaches Setup: 30.000+ EUR. Ein paar Standard-Komponenten, einfache Shopware-Integration.
- Komplettes Setup: 80.000+ EUR. Multi-Komponenten, komplexe Regeln, tiefe Shopware/Shopify-Integration, mehrere Benutzer mit individuellen Workflows.
Das ist nicht günstig. Aber für Marken die damit wirklich arbeiten (nicht nur mal eine Page editieren wollen), ist es die Investition wert weil es Zeit für Marketing freisetzt.
Bei dasistweb liegen unsere Storyblok-Projekte durchschnittlich bei 100.000 EUR initial. Dazu kommen 3.000+ EUR/Monat Betrieb, Hosting und Wartung. Das zahlt sich aus wenn der Marketing-Manager pro Monat 40 Stunden Zeit spart die sonst der Developer brauchte.
Fazit
Storyblok ist nicht das "beste Headless CMS". Es ist ein sehr gutes Headless CMS für ein konkretes Problem: Enterprise-Content-Management ohne die Komplexität eines vollständig selbstgehosteten Systems.
Die Stärke ist nicht Technologie. Es sind 100 andere Headless CMS die technisch vergleichbar sind. Die Stärke ist der Visual Editor. Ein Tool wo Nicht-Techniker einfach Content zusammenklicken können ohne Code zu schreiben.
Ob das für dein Projekt richtig ist, hängt von drei Fragen ab:
- Brauchst du wirklich Enterprise-Content-Management oder ist einfach auch OK?
- Hast du ein Development-Team das Headless-Architektur umsetzen kann?
- Spielt sich die Zeitersparnis in der Content-Verwaltung aus oder ist es nur Mehraufwand?
Wenn alle drei mit "ja" beantwortet sind, dann ist Storyblok richtig. Wenn nicht, brauchst du vielleicht etwas anderes.