Markus Steiner 7 min LesezeitWarum ich auf Storyblok setze – und welche CMS-Alternativen es gibt
Eine Entscheidung die ich immer wieder treffe
Jedes neue Projekt beginnt mit derselben Frage: Welches CMS? Ich könnte jedes Mal neu evaluieren, Vergleiche anstellen, Trends folgen. Ich tue es nicht. Nicht weil ich bequem bin – sondern weil ich nach Jahren in der Praxis weiß was funktioniert. Und was nicht.
Meine Antwort ist meistens Storyblok. Was mich dahin geführt hat, warum ich dabei bleibe – und wo ich auch ehrlich über die Grenzen bin.
Was Storyblok grundlegend anders macht
Der entscheidende Unterschied liegt nicht in einer Feature-Liste. Er liegt in einem konzeptionellen Ansatz der alles andere beeinflusst: Storyblok denkt Inhalte als Komponenten, nicht als Seiten.
Das klingt nach einem technischen Detail. Es ist keines.
Wenn Inhalte als wiederverwendbare Blöcke strukturiert sind, verändert sich wie Redakteure arbeiten und wie Entwickler bauen. Redakteure können Blöcke kombinieren ohne Entwickler anzurufen. Entwickler können Komponenten bauen die unabhängig voneinander gepflegt werden. Beides zum Besseren.
Der zweite fundamentale Unterschied: Storyblok ist API-first by Design. Das ist kein CMS dem man nachträglich eine API angebaut hat. Es wurde von Grund auf so gebaut dass Inhalte über eine saubere Schnittstelle ausgeliefert werden – unabhängig davon was das Frontend macht. SvelteKit heute, etwas anderes in zwei Jahren – das CMS steht davon unabhängig. Kein Lock-in auf eine Rendering-Technologie.
Der Visual Editor: das Feature das in der Praxis am meisten zählt
Wenn ich Kunden erkläre warum ich Storyblok wähle, fängt das Gespräch meist hier an.
Der Visual Editor zeigt Änderungen live im Kontext der echten Website – nicht in einem abstrakten Backend mit Formularfeldern die niemand versteht. Redakteure sehen was sie ändern, während sie es ändern. Das klingt selbstverständlich, ist es aber bei weitem nicht.
Die meisten CMS die ich kenne trennen Backend und Frontend so konsequent, dass Redakteure im Grunde blind arbeiten. Sie füllen Felder aus und hoffen dass das Ergebnis so aussieht wie erwartet. Bei Storyblok entfällt dieses Raten.
Was das in der Praxis bedeutet: weniger Schulungsaufwand, weniger Support-Anfragen nach Projektabschluss, mehr Selbstständigkeit auf Kundenseite. Ich habe Projekte übergeben wo Kunden nach einer einzigen Einschulung eigenständig Inhalte pflegen – Monate später, ohne Rückfragen.
Genau das ist das Ziel. Kunden die nach Projektabschluss unabhängig sind.
Was Entwickler zu schätzen lernen
Neben dem Visual Editor gibt es einige Eigenschaften die in der täglichen Entwicklungsarbeit den Unterschied machen:
Versionierung von Inhalten. Änderungen können rükgängig gemacht werden – auch durch Redakteure. Das nimmt Angst vor Fehlern und reduziert den Druck auf Entwickler als letzte Instanz.
Staging Environments. Content kann in einer Testumgebung vorbereitet und geprüft werden bevor er live geht. Für Kunden die regelmäßig größere Content-Updates ausrollen: unverzichtbar.
TypeScript SDK. Passt direkt in den modernen Frontend-Stack. Typen für Storyblok-Inhalte können automatisch generiert werden – das spart Zeit und reduziert Fehlerquellen.
Internationalisierung im Kern. Mehrsprachigkeit ist keine Erweiterung, kein Plugin, kein Workaround. Sie ist Teil des Datenmodells. Für Projekte die heute einsprachig starten aber morgen skalieren: das ist der Unterschied zwischen sauber und nachträglich zusammengebaut.
API-Schnittstellen. Storyblok liefert eine REST API als primäre Schnittstelle – feature-reich, gut dokumentiert, praxiserprobt. Zusätzlich gibt es eine GraphQL API für Anwendungsfälle wo stark typisierte, selektive Abfragen Sinn machen. Wichtig zu wissen: die GraphQL API ist read-only und weniger feature-reich als die REST API. Für die meisten Projekte ist REST die richtige Wahl – GraphQL ist eine Option, keine Standardempfehlung.
Wartungsfreies Backend – der Vorteil der selten erwähnt wird
Wer jemals eine TYPO3- oder WordPress-Installation über Jahre betrieben hat, kennt das Szenario: Ein Sicherheitsupdate steht an, ein Plugin ist inkompatibel, der Entwickler muss ran und verursacht Kosten – und das alles für etwas das mit dem eigentlichen Inhalt nichts zu tun hat.
Bei Storyblok entfällt das vollständig.
Storyblok ist ein SaaS-CMS. Das bedeutet: die Infrastruktur, Sicherheitsupdates, Server-Wartung und Plattform-Updates werden von Storyblok betrieben – nicht vom Kunden, nicht von mir. Es gibt kein Backend das geupdatet werden muss, keine Plugin-Konflikte, keine PHP-Versionen die geprüft werden müssen.
Was tatsächlich gewartet werden muss ist das Frontend – also die eigentliche Website. Und das ist überschaubar: ein regelmäßiges Update der Abhängigkeiten, gelegentliche Anpassungen wenn sich die Storyblok API ändert. Kein Notfall-Update um 23 Uhr weil eine Sicherheitslücke in einem CMS-Plugin bekannt geworden ist.
Für KMU die kein internes IT-Team haben ist das kein Randaspekt – es ist einer der stärksten praktischen Argumente für ein Headless CMS. Weniger Abhängigkeit von Dienstleistern für Routine-Wartung. Weniger ungeplante Kosten. Mehr Stabilität im Alltag.
Die ehrlichen Nachteile
Pricing. Für sehr kleine Projekte mit minimalem Redaktionsbedarf kann Storyblok ausserhalb der Starter-Lizenz überdimensioniert sein. Starter mach für kleine, wartungsarme Websites aber durchaus Sinn, wenn man auf Premium-Features verzichten kann. Man bekommt auch im günstigsten Pricing ein sehr kompetentes CMS.
Abhängigkeit von der Plattform. Wie bei jedem SaaS-CMS: man vertraut darauf dass Storyblok als Unternehmen stabil bleibt. Das ist ein legitimes Risiko. Storyblok ist gut finanziert und gut positioniert – aber ein Restrisiko bleibt und sollte in einer ehrlichen Beratung erwähnt werden.
Meine drei Fragen vor jedem CMS-Entscheid
Bevor ich Storyblok empfehle – oder davon abrate – stelle ich immer dieselben drei Fragen:
1. Wer pflegt die Inhalte – und wie technisch ist diese Person?
Ein technisches Team kann mit jedem CMS umgehen. Eine Marketingmitarbeiterin die nebenbei Inhalte pflegt braucht etwas das sie wirklich versteht.
2. Wie oft und wie komplex ändern sich die Inhalte?
Wer einmal im Jahr eine Seite ändert braucht kein Headless CMS. Wer regelmäßig Kampagnenseiten aufsetzt, Inhalte in mehreren Sprachen pflegt oder strukturierte Daten verwaltet – der profitiert.
3. Wie wahrscheinlich ist es dass das Projekt in zwei Jahren anders aussieht?
Technologien ändern sich. Anforderungen ändern sich. Ein CMS das heute passt aber in zwei Jahren den Stack blockiert ist keine gute Investition.
Die Antworten auf diese drei Fragen bestimmen die Empfehlung – nicht meine Präferenz.
Wo es mein Standard bleibt und wo ich Alternativen empfehle
Storyblok trifft den Sweet Spot zwischen Redakteursfreundlichkeit und Entwicklerfreiheit besser als jedes andere CMS das ich kenne. Content zu kreieren und zu pflegen ist intuitiv und schnell möglich. Durch die Loslösung vom Frontend bietet sich dem Entwickler und Kunden völlige Technologiefreiheit. Verschieden Kanäle können bespielt werden.
Wenn ein Projekt die Anforderungen hat die Storyblok erfüllt – werde ich es empfehlen. Natürlich ist es aber nicht für alles grenzenlos gut geeignet. Ist ein ausgedehnter Login-Bereich geplant? Dann kann man über TYPO3 nachdenken. Geht die Reise in Richtung PIM oder DAM? Dann ist möglicherweise Pimcore das richtige.
