Sanity statt Contentful: Eine Entscheidung jenseits der Technik

Wer heute moderne Webprojekte mit Next.js plant, stößt bei der Wahl des passenden Redaktionssystems fast zwangsläufig auf zwei Namen: Contentful und Sanity. Beide Plattformen zählen zu den etablierten Vertretern moderner Headless-Architekturen. Sie trennen die Pflege der Inhalte strikt von der visuellen Ausgabe im Browser, stellen strukturierte Daten über APIs bereit und versprechen Entwicklern maximale gestalterische Freiheit.

Auf den ersten Blick ähneln sich die Systeme stark. Wer die Feature-Listen der beiden Anbieter vergleicht, findet vertraute Punkte: GraphQL- und REST-Schnittstellen, Webhooks für automatische Builds, programmierbare Bildtransformationen und rollenbasierte Zugriffsrechte. Ein Entwickler, der rein nach der Dokumentation auswählt, könnte folgern, dass beide Werkzeuge die gleiche Aufgabe gleichermaßen gut erfüllen.

In der Praxis greift dieser Vergleich zu kurz. Die gravierenden Unterschiede zeigen sich selten beim ersten Prototyp, sondern Monate nach dem Go-Live: wenn Redaktionsteams im Arbeitsalltag komplexe Kampagnen einpflegen, wenn das Datenmodell erweitert wird, wenn Kosten für zusätzliche Rollen steigen oder wenn die Rechtsabteilung die genauen Serverstandorte für den Auftragsverarbeitungsvertrag anfordert.

In meinen Projekten im Bereich Web-Engineering setze ich konsequent auf Sanity mit europäischen Datensätzen. Diese Entscheidung basiert nicht darauf, dass Contentful ein schlechtes System wäre. Sie gründet auf vier strukturellen Faktoren, die über den langfristigen Erfolg einer Webplattform entscheiden.

Schema as Code statt Klickarbeit im Browser

Der grundlegendste Unterschied betrifft die Art und Weise, wie Datenstrukturen definiert und gepflegt werden.

Bei Contentful entstehen Inhaltsmodelle primär durch Klicks in einer Weboberfläche. Man legt Inhaltstypen an, wählt Feldtypen und konfiguriert Validierungen in Formularen. In professionellen Entwicklungsprozessen erzeugt dieser Ansatz spürbare Reibung: Das Datenmodell liegt isoliert in der Cloud des Anbieters, getrennt vom Quellcode der Website. Arbeiten mehrere Entwickler an Funktionen oder wird eine Testumgebung mit neuen Feldern aufgebaut, müssen Änderungen über manuelle Migrationsskripte oder CLI-Werkzeuge synchronisiert werden. Weicht der Stand im CMS vom Code im Git-Repository ab, kommt es im Frontend zu Fehlern.

Sanity wählt das entgegengesetzte Paradigma: Schema as Code. Jedes Dokument, jedes Objekt und jedes einzelne Textfeld wird als TypeScript- oder JavaScript-Code direkt im Projekt-Repository definiert. Das Datenmodell ist fester Bestandteil des Quellcodes. Es unterliegt den gleichen Regeln wie jede andere Codezeile: Es wird versioniert, in Git-Branches entwickelt, im Pull Request begutachtet und über automatisierte Tests geprüft.

Wenn ein neues Seitenmodul entsteht, enthält der entsprechende Branch sowohl die visuelle React-Komponente als auch die exakte Schemadefinition für das Redaktionssystem. Wird der Branch auf dem Produktivserver ausgerollt, aktualisiert sich das Redaktionssystem synchron mit dem Frontend. Muss ein Release zurückgerollt werden, kehrt auch die Schemadefinition im Studio in den vorherigen Zustand zurück. Diese Kopplung verhindert, dass Schema im CMS und Code im Repository auseinanderlaufen. Bereits gespeicherte Dokumente passt sie nicht an: Ändert sich ihre Struktur, braucht es weiterhin ein Migrationsskript.

Das Studio als passgenaues Werkzeug für Redaktionsteams

Headless-Systeme wurden ursprünglich von Entwicklern für Entwickler konzipiert. Manche Redaktionsteams empfinden den Umstieg von klassischen Systemen wie WordPress auf ein Headless CMS deshalb als Rückschritt. Statt einer visuellen Seitenvorschau sehen sie oft nur Formulare mit isolierten Eingabefeldern, deren Wirkung auf der fertigen Seite unklar bleibt.

Hier offenbart sich der zweite große Vorteil von Sanity: Das Sanity Studio ist kein geschlossenes SaaS-Portal, sondern eine quelloffene React-Applikation. Entwickler können das Studio vollständig an die Arbeitsweisen des jeweiligen Unternehmens anpassen und direkt in die eigene Next.js-Anwendung einbinden.

Statt starrer Standardformulare erhalten Redaktionsteams eine strukturierte Arbeitsumgebung mit zielgerichteten Eingabemasken. Eine der wichtigsten Funktionen in der täglichen Praxis ist die geteilte Echtzeit-Vorschau: Redakteure sehen auf der linken Bildschirmhälfte ihre Eingabefelder und auf der rechten Seite unmittelbar das gerenderte Frontend. Jede getippte Zeile und jedes hochgeladene Bild aktualisieren die Vorschau ohne Verzögerung.

Ebenso wichtig ist kollaboratives Arbeiten. Sanity basiert auf einer echtzeitfähigen Dokumentendatenbank: Mehrere Personen können gleichzeitig am selben Dokument arbeiten, ohne sich zu blockieren oder Änderungen zu überschreiben. Das System erfasst die Versionshistorie lückenlos, sodass sich frühere Fassungen einzelner Absätze jederzeit vergleichen und wiederherstellen lassen.

Für Entwickler bietet Sanity mit GROQ (Graph-Relational Object Queries) eine offene und flexible Abfragesprache. Während REST-Schnittstellen oft zu viele Daten übertragen und GraphQL für einfache Anfragen sperrig sein kann, erlaubt GROQ das gezielte Filtern, Transformieren und Zusammenführen von Inhalten direkt bei der Abfrage. Das minimiert die übertragene Datenmenge und beschleunigt die Ladezeiten der Website.

Berechenbare Kosten ohne künstliche Tarifklippen

Jedes Softwareprojekt benötigt ein kalkulierbares Budget. Viele Unternehmen erleben bei SaaS-Plattformen jedoch Überraschungen, wenn der Erfolg des Projekts einsetzt.

Contentful staffelt seine Tarife traditionell so, dass zwischen kleineren Paketen und individuellen Enterprise-Verträgen ein deutlicher Preissprung liegt. In den Basis- und Team-Plänen existieren oft strikte Obergrenzen für fundamentale Anforderungen: die maximale Anzahl an Inhaltstypen, die Zahl der verwaltbaren Sprachen oder die Zuweisung granularer Benutzerrollen. Wächst ein mittelständisches Unternehmen und benötigt beispielsweise eine vierte Inhaltsebene oder eine zusätzliche Sprachversion, greift das Standardmodell nicht mehr. Der Wechsel in die Enterprise-Klasse bedeutet dann häufig einen Sprung von wenigen hundert Euro im Monat auf fünfstellige Jahresbeträge.

Sanity verfolgt ein deutlich faireres Preismodell. Kernfunktionen für inhaltliche Strukturierung, Mehrsprachigkeit und die Definition eigener Schemas stehen unabhängig von der Tarifstufe zur Verfügung. Die Abrechnung orientiert sich primär am realen Verbrauch: der Anzahl der API-Anfragen, dem Datentransfer für Medien und der Anzahl der aktiven Redaktionskonten.

Für wachsende Unternehmen bedeutet das wirtschaftliche Sicherheit: Ein Projekt kann klein starten, ohne bei der ersten Erweiterung an künstliche Lizenzgrenzen zu stoßen. Die Betriebskosten wachsen proportional zur tatsächlichen Nutzung der Plattform.

Serverstandorte, EWR und der Auftragsverarbeitungsvertrag

Der vierte und in der Praxis oft ausschlaggebende Punkt betrifft den Datenschutz und die rechtliche Verantwortlichkeit.

Verwaltet ein Content-Management-System neben statischen Texten auch Kontaktformulare, Nutzerprofile, Redaktionsdaten oder vertrauliche Vorab-Informationen, verarbeitet es personenbezogene Daten. Nach Art. 28 der Datenschutz-Grundverordnung (DSGVO) müssen Unternehmen mit jedem externen Dienstleister, der Zugriff auf diese Daten hat, einen Auftragsverarbeitungsvertrag (AVV) schließen.

Contentful wurde zwar 2013 in Berlin gegründet, die oberste Muttergesellschaft ist jedoch die Contentful Inc. mit Sitz in den USA. Selbst wenn europäische Serverstandorte gewählt werden, unterliegen US-amerikanische Konzerne und deren Tochtergesellschaften dem US CLOUD Act. Diese US-Gesetzgebung verpflichtet amerikanische Anbieter unter bestimmten Voraussetzungen dazu, US-Behörden Zugriff auf gespeicherte Daten zu gewähren, selbst wenn diese Daten physisch auf Servern in Europa liegen. Für Datenschutzbeauftragte in europäischen Unternehmen und Kanzleien erfordert die Einbindung von US-Anbietern deshalb aufwendige Risikoanalysen, sogenannte Transfer Impact Assessments, und den Abschluss von EU-Standardvertragsklauseln.

Sanity wird von der Sanity AS betrieben, einem Unternehmen mit Sitz in Oslo, Norwegen. Norwegen ist Mitglied des Europäischen Wirtschaftsraums (EWR). Durch den Beschluss des Gemeinsamen EWR-Ausschusses gilt die europäische Datenschutz-Grundverordnung in Norwegen unmittelbar. Eine Datenübermittlung zwischen Deutschland und Norwegen gilt datenschutzrechtlich nicht als Drittlandtransfer im Sinne von Kapitel V der DSGVO. Es gelten die gleichen strengen Schutzstandards wie innerhalb der Europäischen Union.

Sanity ermöglicht bei der Einrichtung von Projekten die explizite Auswahl des Speicherorts. Für europäische Datasets werden Cloud-Regionen innerhalb der Europäischen Union genutzt, etwa in Frankfurt oder Belgien. Die Daten ruhen physisch und vertraglich gesichert auf europäischem Boden. Für meine Kunden bedeutet das: Der Auftragsverarbeitungsvertrag bleibt übersichtlich, weil kein Drittlandtransfer im Sinne von Kapitel V der DSGVO anfällt.

Eine Architekturentscheidung mit langfristiger Wirkung

Technische Softwarearchitektur muss immer der Organisation dienen, die sie betreibt. Dieser Grundsatz aus den drei Fragen vor jedem Web-Projekt gilt bei Content-Systemen ganz besonders. Die Wahl eines Content-Management-Systems ist keine flüchtige Entscheidung. Das CMS verzahnt sich über Jahre hinweg tief mit den internen Arbeitsabläufen der Redaktion und der Struktur der Frontend-Komponenten.

In früheren Beiträgen zur europäischen Datensouveränität habe ich beschrieben, warum die bewusste Entscheidung für europäische Infrastruktur kein theoretisches Ideal ist, sondern konkrete operative Stabilität schafft. Bei der Auswahl von Werkzeugen für das Web-Engineering gilt das gleiche Prinzip.

Entwickler pflegen das Schema als Code mit voller Git-Integration, während Redaktionsteams jede Eingabe sofort in der Seitenvorschau des Studios sehen. Unternehmen profitieren von planbaren Betriebskosten und einem verlässlichen europäischen Rechtsrahmen.

Strukturierte Inhalte als Basis für erfolgreiche Plattformen

Wer ein neues digitales Projekt aufbaut oder eine bestehende Website modernisiert, sollte die Entscheidung für ein CMS nicht allein den Software-Katalogen überlassen. Sprechen Sie mit den Menschen, die wöchentlich Texte pflegen müssen, prüfen Sie die Skalierbarkeit der Lizenzkosten und klären Sie die rechtlichen Rahmenbedingungen vor Beginn der ersten Codezeile.

Planen Sie den Umstieg auf ein Headless CMS oder möchten Sie Ihre Redaktion von starren Formularen befreien? Als Web-Engineer unterstütze ich Sie von der Datenmodellierung bis zur Integration in Next.js, verlässlich kalkuliert zu transparenten Festpreisen. Schildern Sie mir Ihr Redaktions-Setup gern über das Kontaktformular.