Storyblok mit Astro: Setup, Visual Editor und Kosten
Astro ist schnell, weil es im Normalfall fertige HTML-Dateien ausliefert. Der Haken steckt selten in der Technik. Er kommt im ersten Redaktionsmeeting nach dem Launch: Inhalte liegen als Markdown-Dateien im Repository. Für ein Entwicklerteam ist das komfortabel. Für eine Marketing-Abteilung, die zwischen zwei Terminen eine Headline ändern will, ist es eine Zumutung.
Storyblok ist eine Antwort darauf. Was der Anbieter neben Astro leistet und wo es hakt, steht unten. Vorab die Offenlegung: Wir haben Storyblok evaluiert und für Angebote durchgerechnet, setzen es aber in keinem Kundenprojekt produktiv ein. Das hier ist also eine Einschätzung, keine Erfolgsgeschichte.
Warum Storyblok neben Astro
Kurz zur Einordnung, falls der Begriff neu ist: Ein Headless CMS verwaltet Inhalte und gibt sie über eine Schnittstelle aus, statt selbst eine Website auszuliefern. Das sichtbare Frontend baut ein separates Werkzeug, hier Astro. Ausführlicher steht das in Was ist ein Headless CMS?; welche Kategorien es gibt und welche zu welchem Team passt, klärt der Headless CMS Vergleich.
Storyblok gehört zur Kategorie der dedizierten SaaS-Systeme. Was es von Contentful, Sanity oder Hygraph abhebt:
Der Visual Editor. Redakteure bearbeiten Inhalte nicht in einer Formularmaske, sondern in einer Vorschau der echten Seite. Das klingt nach Detail, entscheidet aber häufig über die Akzeptanz im Team.
Der Firmensitz. Storyblok ist ein Wiener Unternehmen. Für deutsche Mittelständler und öffentliche Auftraggeber verkürzt das die Diskussion über Auftragsverarbeitung und Drittlandtransfer erheblich, auch wenn der tatsächliche Speicherort separat zu prüfen bleibt.
Dazu kommt die Kombination mit Astro selbst: Astro hat eine offiziell gepflegte Storyblok-Integration, und Storyblok pflegt umgekehrt ein Astro-SDK. Beide Seiten haben ein Interesse daran, dass die Verbindung funktioniert, was bei Nischenkombinationen keine Selbstverständlichkeit ist.
Der Visual Editor, und was er nicht ist
Ohne diesen Editor gäbe es wenig Grund, Storyblok gegenüber Contentful oder Sanity zu bevorzugen. Die Redaktion öffnet einen Eintrag und sieht die Seite so, wie Besucher sie später sehen. Ein Klick auf eine Überschrift öffnet das passende Eingabefeld, Änderungen erscheinen sofort in der Vorschau.
Verglichen mit einem klassischen Headless-CMS-Formular, in dem man Felder ausfüllt und auf das Ergebnis hofft, ist das ein spürbarer Unterschied. Der übliche Einwand gegen Headless lautet: „Unsere Leute sehen ja gar nicht mehr, was sie tun.” Dagegen hilft der Visual Editor.
Eine Grenze muss man aber von Anfang an klar benennen, sonst wird sie später zum Streitpunkt: Der Visual Editor ist kein Page Builder. Redakteure können Bausteine anlegen, füllen, umsortieren und entfernen. Sie können nicht frei Spalten ziehen, Abstände verändern oder ein neues Layout erfinden. Welche Bausteine es gibt und wie sie aussehen, legt die Entwicklung fest.
Das ist eine bewusste Entscheidung und in der Regel die richtige, weil sie das Design über Jahre stabil hält. Wer aus einem WordPress mit Elementor kommt und dort gewohnt war, jede Seite frei zusammenzuklicken, empfindet es trotzdem erst einmal als Einschränkung. Diese Erwartung gehört ins erste Gespräch, nicht in die Abnahme.
Inhaltsmodell: Bausteine statt Seiten
Storyblok nennt seine Inhaltsbausteine „Bloks”. Ein Blok ist ein wiederverwendbarer Baustein mit definierten Feldern, etwa ein Teaser mit Überschrift, Text, Bild und Link. Bloks lassen sich ineinander verschachteln, sodass eine Seite aus einer Liste von Bausteinen besteht statt aus einem großen Textfeld.
Diese Modellierung ist der eigentliche Kern des Projekts. Sie bestimmt, wie angenehm sich die Seite in zwei Jahren pflegen lässt, und sie ist schwerer zu ändern als das Design. Falsch machen kann man es in beide Richtungen:
- Zu grobe Bausteine. Ein einziger Blok „Landingpage” mit vierzig Feldern ist nichts anderes als ein Formular mit Extraschritten. Der Visual Editor bringt dann keinen Vorteil.
- Zu feine Bausteine. Wenn Redakteure aus zwanzig fast identischen Bausteinen wählen müssen, wählen sie falsch. Weniger und dafür klar benannte Bloks funktionieren besser.
Ein brauchbarer Ausgangspunkt liegt bei acht bis fünfzehn Bausteinen für eine typische Firmenwebsite. Wichtiger als die Zahl ist, dass jeder Baustein einen erkennbaren Zweck hat, den man in einem Satz erklären kann.
So läuft die Umsetzung
Technisch ist die Verbindung überschaubar. In der Astro-Konfiguration wird die Integration registriert, und dort entsteht die Zuordnung zwischen den Bloks aus Storyblok und den Astro-Komponenten im Projekt:
// astro.config.mjs
import { defineConfig } from 'astro/config';
import { storyblok } from '@storyblok/astro';
export default defineConfig({
integrations: [
storyblok({
accessToken: STORYBLOK_DELIVERY_API_TOKEN,
components: {
page: 'storyblok/Page',
teaser: 'storyblok/Teaser',
grid: 'storyblok/Grid',
},
}),
],
});
Ein Hinweis, weil viele ältere Anleitungen im Netz es anders zeigen: Die Integration wird als benannter Export importiert, also import { storyblok }, nicht als Default-Import.
Jede Astro-Komponente bekommt anschließend den passenden Blok als Prop. Damit ein Element im Visual Editor anklickbar wird, markiert storyblokEditable es im Markup:
---
// src/storyblok/Teaser.astro
import { storyblokEditable } from '@storyblok/astro';
const { blok } = Astro.props;
---
<h2 {...storyblokEditable(blok)}>{blok.headline}</h2>
Mehr braucht es für den Grundaufbau nicht. Der Aufwand liegt nicht in dieser Verkabelung, sondern davor: im Inhaltsmodell und in den Komponenten selbst.
Eine Sache, über die beim ersten Projekt fast jeder stolpert: Storyblok unterscheidet zwischen Entwurf und veröffentlichter Fassung. Der Visual Editor arbeitet mit draft, der Produktivbuild holt sich published. Wer beides verwechselt, veröffentlicht ungeprüfte Inhalte oder wundert sich, warum Änderungen nicht ankommen. Die Live-Vorschau im Editor lässt sich zusätzlich aktivieren, verlangt dann aber serverseitiges Rendering statt eines rein statischen Builds.
Veröffentlichen: Webhook statt Klick-und-live
Hier gehen die Erwartungen am weitesten auseinander. Bei WordPress ist eine Änderung nach dem Speichern sofort online. Bei einer statisch gebauten Astro-Seite nicht.
Der Ablauf sieht stattdessen so aus: Die Redaktion veröffentlicht in Storyblok, Storyblok ruft einen Webhook auf, der Webhook stößt einen neuen Build an, das Ergebnis wird ausgeliefert. Wie lange das dauert, hängt vom Seitenumfang und der Build-Umgebung ab und liegt bei überschaubaren Firmenseiten meist im Minutenbereich.
Für die meisten Inhalte ist das völlig unproblematisch. Ein Blogbeitrag muss nicht in derselben Sekunde erscheinen. Kritisch wird es bei Daten, die sich häufig und kurzfristig ändern, etwa Preise, Verfügbarkeiten oder Termine. Solche Bereiche gehören serverseitig gerendert und nicht in den statischen Build.
Dafür bekommst du fertiges HTML ohne Datenbankabfrage beim Seitenaufruf. Was das für die Core Web Vitals bedeutet, haben wir separat beschrieben.
Kosten und Datenstandort
Storyblok rechnet nach Nutzern, Traffic und Funktionsumfang ab. Es gibt einen kostenlosen Einstieg, der für kleine Seiten mit ein oder zwei Redakteuren tatsächlich reicht. Darüber staffelt sich der Preis über Team- und Enterprise-Stufen, wobei Funktionen wie Freigabe-Workflows, feingranulare Rollen und garantiertes EU-Hosting üblicherweise erst weiter oben liegen. Die konkreten Zahlen ändern sich zu oft, um sie hier festzuschreiben; sie gehören vor dem Angebot beim Anbieter geprüft.
Für die Kalkulation ist ohnehin eine andere Zahl relevant: Die Lizenz ist selten der größte Posten. Den Aufwand macht der einmalige Aufbau, also Inhaltsmodell, Komponenten, Migration bestehender Inhalte und die Einarbeitung der Redaktion. Wer nur die Monatsgebühr vergleicht, vergleicht die falsche Größe.
Beim Thema Datenschutz gilt: Ein Wiener Firmensitz ist ein guter Ausgangspunkt, aber kein Nachweis. Wo deine Inhalte tatsächlich gespeichert werden, hängt von Tarif und gewählter Region ab, und das gehört vor Vertragsschluss geklärt, zusammen mit Auftragsverarbeitungsvertrag und eingesetzten Subunternehmern. Immerhin entspannt die statische Auslieferung die Lage: Besucher deiner Website sprechen nie mit Storyblok, die Verbindung besteht nur beim Build. Die vollständige Prüfliste steht in DSGVO-konformes Headless CMS.
Wann Storyblok nicht passt
Wir würden in diesen Fällen abraten:
- Wenige Inhalte, technisches Team. Wenn eine Handvoll Seiten selten geändert wird und die Änderungen ohnehin von Entwicklern kommen, reichen Astros eigene Content Collections. Kein zusätzliches System, keine Lizenz, alles versioniert im Repository.
- Eingespieltes WordPress-Team. Wenn die Redaktion WordPress kennt und mag, ist der Umstieg auf ein neues CMS unnötige Reibung. Dann lässt sich WordPress als Backend behalten und trotzdem Astro ausliefern, beschrieben in Headless WordPress mit Astro.
- Kein Budget für laufende Kosten. Ein SaaS-CMS ist eine dauerhafte Position im Budget. Wer das vermeiden will, ist mit einem selbst gehosteten System oder einem dateibasierten Ansatz besser bedient.
- Anspruch auf freies Layout. Wenn die Redaktion erwartet, jede Seite frei zusammenbauen zu können, wird der Visual Editor sie enttäuschen. Diese Erwartung sollte vorher geklärt sein, nicht nach dem Launch.
Fazit
Storyblok neben Astro ergibt Sinn, wenn zwei Bedingungen zusammenkommen: Deine Redaktion pflegt regelmäßig selbst Inhalte, und sie braucht dafür eine Oberfläche, die zeigt, was sie tut. Trifft nur die erste Bedingung zu, gibt es günstigere Wege. Trifft keine zu, sind Content Collections die einfachere Antwort.
Was uns bei der Evaluation am deutlichsten aufgefallen ist: Die technische Anbindung ist an einem Tag erledigt. Das Inhaltsmodell beschäftigt einen wochenlang. Genau umgekehrt zu dem, was man erwartet, wenn man in die Dokumentation schaut.
Du überlegst, ein CMS hinter deine Astro-Seite zu hängen? Sag uns, wer die Inhalte pflegt, wie oft sich etwas ändert und wie strukturiert eure Inhalte heute sind. Wir sagen dir ehrlich, ob Storyblok, WordPress als Backend oder gar kein CMS der passende Weg ist. Schreib uns kurz.
Häufige Fragen
Was kostet Storyblok?
Storyblok staffelt nach Nutzerzahl, Traffic und Funktionsumfang. Für kleine Projekte gibt es einen kostenlosen Einstiegstarif, der für eine einfache Firmenseite mit ein bis zwei Redakteuren oft ausreicht. Darüber wird nach Team- und Enterprise-Stufen abgerechnet, wobei Dinge wie garantiertes EU-Hosting, feingranulare Rollen und Freigabe-Workflows typischerweise erst in höheren Stufen enthalten sind. Prüfe die aktuellen Konditionen direkt beim Anbieter, sie ändern sich regelmäßig. Wichtiger für die Kalkulation: Die Lizenz ist selten der größte Posten. Der Aufwand steckt im einmaligen Aufbau des Inhaltsmodells und des Astro-Frontends.
Ist Storyblok DSGVO-konform?
Storyblok ist ein österreichisches Unternehmen mit Sitz in Wien, was die Vertragslage gegenüber US-Anbietern deutlich vereinfacht. Ein europäischer Firmensitz bedeutet aber nicht automatisch, dass deine Inhalte auch auf europäischen Servern liegen: Der Speicherort hängt vom gebuchten Tarif und der gewählten Region ab. Kläre vor dem Vertrag drei Dinge: den tatsächlichen Datenstandort, den Auftragsverarbeitungsvertrag und die eingesetzten Subunternehmer. Bei einer statisch ausgelieferten Astro-Seite ist die Lage ohnehin entspannter als bei einem SaaS-CMS im Live-Betrieb, weil die Besucher deiner Website nie mit Storyblok sprechen.
Storyblok oder WordPress als Backend für Astro?
Das hängt vor allem an deinem Team, nicht an der Technik. Wenn deine Redaktion WordPress kennt und gerne damit arbeitet, ist WordPress als Backend der kürzere Weg: Die Arbeitsweise bleibt gleich, nur die Auslieferung ändert sich. Storyblok lohnt sich, wenn Inhalte sauber strukturiert über mehrere Kanäle laufen sollen, wenn mehrere Sprachen im Spiel sind oder wenn dich der Pflegeaufwand eines WordPress-Backends stört. Storyblok kostet Lizenzgebühr und bringt eine Lernkurve mit, dafür entfallen Plugin-Updates und Sicherheits-Patches.
Wie lange dauert es, bis eine Änderung live ist?
Bei einer statisch gebauten Astro-Seite liegt zwischen dem Klick auf Veröffentlichen und der sichtbaren Änderung ein Rebuild. Wie lange der dauert, hängt vom Umfang der Seite und der Build-Umgebung ab; bei überschaubaren Firmenseiten bewegt es sich meist im Bereich weniger Minuten. Im Visual Editor sieht die Redaktion ihre Änderung sofort, nur die öffentliche Seite zieht verzögert nach. Wer wirklich sekundengenaue Aktualisierung braucht, etwa für Preise oder Verfügbarkeiten, sollte diese Bereiche serverseitig rendern statt sie in den statischen Build zu legen.
Passende Leistungen
Sr. Full-Stack Developer
Frontend & Backend. Entwickelt skalierbare Webanwendungen mit Fokus auf saubere Architektur und Wartbarkeit.