Headless CMS für E-Commerce im Vergleich: Contentful, Storyblok, Sanity, und wo der Frontend-Layer sitzt

Wer heute ein Headless CMS für einen E-Commerce-Auftritt auswählt, steht fast immer vor derselben Kurzliste: Contentful, Storyblok, Sanity. Alle drei sind API-first, alle drei werben mit Composable Commerce, und alle drei lösen im Kern doch unterschiedliche Probleme. Die Entscheidung wird selten durch ein einzelnes Killer-Feature getroffen, sondern durch die Passung zwischen Content-Modeling-Philosophie, Team-Setup und dem, was die Redaktion täglich selbst erledigen können soll. Dazu kommt: Ein CMS-Wechsel ist kein Wochenend-Projekt, sondern eine mehrmonatige Migration mit Auswirkungen auf Redaktion, Entwicklung und Frontend-Rendering gleichzeitig. In diesem Beitrag vergleichen wir die drei Systeme entlang der Kriterien, die im E-Commerce-Kontext tatsächlich zählen, ohne Sieger-Krönung und ohne verdeckten Pitch. Im zweiten Teil ordnen wir ein, warum die Wahl des CMS eine andere Entscheidung ist als die Wahl der Storefront, und wo der Frontend-Layer dazwischen sitzt.

Content-Modeling-Philosophie: starre Types, flexible Blöcke, Schema-as-Code

Contentful arbeitet mit klar definierten Content-Types: Ihr modelliert Felder, Referenzen und Validierungen in einem zentralen Content-Model, das für alle Einträge eines Typs gilt. Das erzeugt Konsistenz und macht große Content-Mengen vorhersagbar, verlangt aber Disziplin bei Änderungen, weil ein Type-Update potenziell viele bestehende Einträge betrifft und in größeren Teams einen Freigabeprozess braucht. Storyblok denkt in Blöcken: Redakteure setzen Komponenten frei zusammen, ähnlich einem Page-Builder-Prinzip, was für variantenreiche Landingpages und Kampagnenseiten praktisch ist, aber die Modellierungsverantwortung stärker in Richtung Redaktion verschiebt und ohne klare Guidelines schnell zu inkonsistenten Seiten führen kann. Sanity nutzt Schema-as-Code: Das Content-Model wird in JavaScript beziehungsweise TypeScript definiert und versioniert, was Entwicklerteams sehr nahe an klassische Softwareentwicklung bringt, inklusive Code-Review und Git-Historie für Schema-Änderungen, aber auch bedeutet, dass Redaktionen ohne Entwicklerbeteiligung kaum neue Feldtypen anlegen können. Wer viel wiederkehrende, stark strukturierte Produktkommunikation hat, etwa Produktbeschreibungen, technische Datenblätter oder Vergleichstabellen in großer Zahl, tendiert zu Contentful oder Sanity. Wer viele einmalige Kampagnenseiten baut, etwa saisonale Landingpages oder Markenkooperationen, findet in Storyblok mehr gestalterische Freiheit auf Redaktionsebene, ohne für jede Variante ein neues Entwicklerticket zu brauchen.

Visual Editing: was die Redaktion tatsächlich selbst kann

Ein oft unterschätzter Punkt: Wie nah kommt das Editing-Erlebnis an "ich sehe, was ich tue" heran? Storyblok hat Visual Editing von Anfang an zum Kernversprechen gemacht, mit einer Live-Vorschau, in der Redakteure Blöcke direkt im gerenderten Kontext verschieben, ohne dabei den Code oder die zugrunde liegende Rendering-Logik anfassen zu müssen. Contentful bietet mit seinem visuellen Editor eine ähnliche Erfahrung, allerdings historisch stärker an bestimmte Frontend-Frameworks gekoppelt und mit mehr Integrationsaufwand verbunden als bei Storyblok, was bedeutet, dass die Qualität der Live-Vorschau stark von der eigenen Implementierung abhängt. Sanity setzt traditionell auf ein sehr flexibles, aber eher formularbasiertes Studio-Interface; visuelle Vorschauen sind möglich, erfordern jedoch meist zusätzliche Konfiguration über das Presentation-Tooling und ein eigenes Setup für Live-Preview-Verbindungen zum Frontend. Für Teams, bei denen Marketing und Content-Ownership stark bei Nicht-Entwicklern liegt, ist die Nähe zum visuellen Ergebnis oft ein stärkeres Kriterium als die Eleganz des Datenmodells dahinter, weil tägliche Änderungen sonst immer über die Entwicklung laufen müssen und Release-Zyklen verlangsamen.

Lokalisierung und Multi-Market-Fähigkeit

Bei internationalen Shops mit mehreren Sprachen und Märkten unterscheiden sich die Systeme in der Tiefe ihres Lokalisierungsmodells. Contentful bietet granulare Locale-Steuerung pro Feld, was präzise ist und einzelne Felder gezielt übersetzen lässt, bei sehr vielen Locales aber konfigurationsintensiv werden kann und eine klare Governance für Übersetzungsworkflows voraussetzt. Storyblok arbeitet mit Sprachordnern und einem Fallback-Mechanismus, der für viele Multi-Market-Setups pragmatisch funktioniert und schnell aufgesetzt ist, aber weniger feingranular ist als Contentfuls Feld-Ebene und bei sehr unterschiedlichen Marktanforderungen an Grenzen stossen kann. Sanity überlässt die Lokalisierungsstrategie weitgehend dem Schema-Design: Ihr könnt Locale-Handling selbst modellieren, etwa als eigenes Dokument pro Sprache oder als lokalisierte Felder innerhalb eines Dokuments, was Flexibilität bedeutet, aber auch, dass Ihr die Architektur-Entscheidung selbst treffen müsst, statt eine vorgegebene Lösung zu übernehmen. Keines der drei Systeme löst Multi-Market-Komplexität automatisch, sie bieten unterschiedliche Bausteine dafür an, und die eigentliche Herausforderung bleibt meist die organisatorische Frage, wer Übersetzungen freigibt und wie Content-Drift zwischen Märkten vermieden wird.

Developer-Experience und API-Charakter

Contentful stellt eine REST-API sowie eine GraphQL-Content-API bereit, beide gut dokumentiert, mit SDKs für die gängigen Stacks und einer breiten Auswahl an Community-Beispielen. Storyblok setzt primär auf eine REST-Schnittstelle mit gut kuratierten Client-Bibliotheken und legt Wert auf schnellen Einstieg für Frontend-Teams, was sich besonders bei kleineren Teams ohne dedizierte Backend-Expertise auszahlt. Sanity geht mit GROQ einen eigenen Weg: eine deklarative Abfragesprache, die sehr präzise, teils komplexe Datenabfragen in einem einzigen Request erlaubt, etwa verschachtelte Referenzen und bedingte Projektionen, dafür aber eine gewisse Lernkurve mitbringt, die über SQL- oder GraphQL-Erfahrung hinausgeht. Für Teams mit starkem GraphQL-Hintergrund ist Contentful oft der naheliegendste Einstieg, weil sich viele Konzepte direkt übertragen lassen. Teams, die maximale Abfrage-Flexibilität wollen und bereit sind, GROQ zu lernen, profitieren von Sanity, gerade bei komplexen Datenmodellen mit vielen Querverweisen. Storyblok punktet dort, wo schneller Time-to-Value vor maximaler Abfragetiefe steht und die Frontend-Anbindung möglichst einfach bleiben soll.

Preis- und Skalierungslogik

Ohne uns auf konkrete Zahlen festzulegen, die sich ohnehin regelmäßig ändern: Alle drei Anbieter folgen einer nutzungsbasierten Logik, bei der API-Calls, Nutzeranzahl im Studio, Assets und teilweise Umgebungen die Kostenstruktur treiben. Contentful positioniert sich historisch eher im Enterprise-Segment mit entsprechend gestaffelten Plänen und zusätzlichen Kosten für Umgebungen und Rollen. Storyblok adressiert explizit auch kleinere und mittlere Teams mit niedrigerer Einstiegshürde und einem Plan-Modell, das sich stufenweise mit dem Wachstum des Shops erweitern lässt. Sanity kombiniert ein großzügiges kostenloses Kontingent mit nutzungsbasierter Skalierung für Datasets und Bandbreite, was für Proof-of-Concepts und kleinere Projekte attraktiv ist, bei sehr hohem Traffic aber genau kalkuliert werden sollte. Für eine belastbare Kosteneinschätzung für Euren konkreten Traffic und Euer Content-Volumen empfehlen wir, aktuelle Angebote direkt bei den Anbietern einzuholen, statt sich auf Zahlen zu verlassen, die schnell veralten und je nach Vertragsmodell stark variieren können.

Ecosystem und Migrationsaufwand

Contentful hat durch seine Marktposition ein breites Partner- und Agentur-Ökosystem sowie viele fertige Integrationen in Richtung Commerce-Plattformen und DAM-Systeme, was die Einbindung in bestehende Enterprise-Landschaften erleichtert. Storyblok hat in den letzten Jahren stark in Plugins und einen Marktplatz für Feld-Typen investiert, was die Anpassung an spezifische Redaktionsbedürfnisse erleichtert, ohne dass jede Erweiterung selbst entwickelt werden muss. Sanity punktet mit einem aktiven Open-Source-Umfeld und einer Community, die viele eigene Tools und Erweiterungen für das Studio baut, was für Teams mit eigener Entwicklungskapazität ein Vorteil ist, für reine Redaktionsteams aber weniger unmittelbar nutzbar. Beim Migrationsaufwand gilt für alle drei Systeme: Die Datenmodellierung ist der eigentliche Aufwandstreiber, nicht die reine API-Anbindung. Ein sauberes Content-Modell aus einem alten System 1:1 in ein neues zu übertragen ist selten sinnvoll, meist lohnt sich eine bewusste Neumodellierung entlang der Stärken des Zielsystems, inklusive einer Bestandsaufnahme, welche Content-Typen im alten System überhaupt noch aktiv genutzt werden und welche historischer Ballast sind.

CMS ist nicht Storefront: wo der Frontend-Layer ansetzt

Alle drei Systeme liefern Content über eine API aus, sie rendern aber keine Storefront und kennen in der Regel weder Warenkorb-Logik noch Preisberechnung noch Produktverfügbarkeit in Echtzeit. Genau an dieser Stelle setzt eine Frontend Management Platform (FMP) an: Sie führt Content aus dem CMS, Commerce-Daten aus dem Backend und das eigentliche Rendering der Storefront zusammen. Laioutr ist eine solche FMP, kein CMS und kein CMS-Ersatz. Wenn Ihr Euch für Contentful, Storyblok oder Sanity entscheidet, bleibt die Frage offen, wie Content-Blöcke, Produktdaten und Personalisierung im gerenderten Frontend zusammenkommen, wie AB-Tests darauf laufen und wie das Ganze performant und barrierefrei ausgeliefert wird. Das ist eine andere Ebene der Architektur als die CMS-Wahl, und beide Entscheidungen lassen sich unabhängig voneinander treffen, das eine ersetzt das andere nicht. Mehr zur Rolle dieser Ebene findet Ihr im Beitrag zu unserer composable visuellen Page-Builder-Architektur, in dem wir zeigen, wie sich CMS-Content und Commerce-Daten in einem gemeinsamen Rendering-Layer zusammenführen lassen, ohne dass Redaktion und Entwicklung sich gegenseitig blockieren.

Entscheidungs-Matrix nach Team-Setup

Wenn Eure Redaktion viel eigenständig gestalten und Kampagnenseiten in hoher Frequenz bauen soll, ist Storyblok mit seinem block-basierten Modell und dem starken Visual Editing oft der pragmatischste Startpunkt, siehe auch unseren Contentful-Page-Builder-Hub zum Vergleich der Integrationstiefe. Wenn Ihr ein großes, stark strukturiertes Content-Modell mit vielen Redakteuren und Enterprise-Governance-Anforderungen habt, ist Contentful mit seinen klar definierten Content-Types häufig die robustere Wahl, siehe unseren Storyblok-Page-Builder-Hub für die Gegenperspektive. Wenn Euer Entwicklerteam ohnehin in einem Code-first-Workflow denkt und maximale Abfrage-Flexibilität über GROQ schätzt, ist Sanity die konsequenteste Option, mehr dazu im Sanity-Page-Builder-Hub. Keine dieser drei Antworten ist grundsätzlich falsch, sie spiegeln unterschiedliche Prioritäten zwischen Redaktionsfreiheit, Struktur-Governance und Entwickler-Kontrolle wider, und in der Praxis entscheidet oft das Team, das täglich damit arbeitet, mehr als die reine Feature-Liste. Unabhängig davon, für welches CMS Ihr Euch entscheidet, lohnt sich ein separater Blick auf das Content-Management auf Frontend-Seite, dazu mehr unter Content Management bei Laioutr. Wer schon eine Content-Modeling-Entscheidung im eigenen Team diskutiert hat, findet ergänzend unseren Beitrag zu Composable Commerce Grundlagen hilfreich für die Einordnung in die Gesamtarchitektur. Am Ende gilt: Das CMS entscheidet, wie Content entsteht und gepflegt wird, nicht, wie er beim Kunden ankommt, und genau diese zweite Frage sollte unabhängig von der CMS-Wahl beantwortet werden.