Wenn du deine Headless-CMS-Wahl auf Sanity gegenüber der Payload-oder-Storyblok-Fraktion eingegrenzt hast, hast du bereits 80 Prozent des Lärms eliminiert, den der Rest dieser Kategorie ausstößt. Die verbleibende Entscheidung ist die interessante: Optimierst du für das Editorial-Team-Erlebnis oder für das Engineering-Team-Ownership? Wenn du diese Frage richtig beantwortest, ist der Rest der Wahl zumeist erzwungen.
Sanity ist die Antwort, wenn das Editorial-Team die Hauptfigur ist. Nach dem Ausführen von über 12.000 Client-Builds bei Seahawk Media und dem direkten Ausliefern einer Handvoll auf Sanity in den letzten 18 Monaten, hier ist die ehrliche Einschätzung zu wo es gewinnt, wo Payload es schlägt und wo Storyblok es tut. Preisgestaltung, Funktionalität, Migrationspfad und die Trade-offs, die dir niemand auf den Vendor-Sales-Seiten sagen wird.
Was Sanity 2026 wirklich ist
Sanity ist ein gehostetes Headless CMS, in dem du das Schema in TypeScript oder JavaScript schreibst, eine anpassbare React-basierte Admin-App namens Sanity Studio (typischerweise auf deiner eigenen Domain bereitgestellt) ausführst und den Content über GROQ abfragst — eine graphähnliche Abfragesprache, die GraphQL ähnelt, aber bei Document-Beziehungen ausdrucksstärker ist. Content ist über Editoren hinweg in Echtzeit sofort einsatzbereit: zwei Editoren im selben Document sehen die Cursor-Positionen des anderen live, wie bei Figma.
Die Plattform ist ausgereift: Sanity v3 ist seit zwei Jahren die stabile Major-Version, das Studio ist bis hin zu einzelnen Input-Komponenten genuinely anpassbar, und die Live Content API streamt Document-Änderungen an dein Front End ohne Polling. Sanity ist eine der wenigen Headless-CMS-Optionen in 2026, die sich nicht wie ein Early-Stage-Produkt an einem Dienstagnachmittag anfühlen.
Sanity-Preisgestaltung 2026 — die echte Kostenkurve
Drei Pläne. Der kostenlose Plan wirkt großzügig, bis Sie auf die harten Limits stoßen; der Growth-Plan startet bei $15 pro Benutzer pro Monat; Enterprise ist maßgeschneidert und beginnt dort, wo der Growth-Plan nicht mehr skaliert.
Kostenloser Plan
- $0/Monat, 20 enthaltene Benutzer ohne Überschussgebühren.
- Beschränkt auf Administrator- und Viewer-Rollen — keine Editor-, Developer- oder Contributor-Rollen.
- Harte Limits für Dokumente, Assets, API-Anfragen, CDN-Bandbreite. Wenn Sie ein Kontingent erreichen, wird die betroffene Funktionalität blockiert, bis sich das Kontingent zurückgesetzt hat oder Sie upgraden.
- Realistisch für: Prototypen, interne Tools oder Content-Websites mit unter 5.000 Dokumenten und einem kleinen Redaktionsteam.
Growth-Plan
- $15 pro Benutzer pro Monat, bis zu 50 Benutzer.
- Alle fünf Rollen freigeschaltet: Admin, Viewer, Editor, Developer, Contributor.
- 250.000 API-Anfragen pro Monat inbegriffen, 1 Million API-CDN-Anfragen, danach Pay-as-you-go.
- 25.000 Dokumente Hard Cap — kein Pay-as-you-go darüber hinaus im Growth-Plan, Sie müssen zu Enterprise wechseln.
- Geplante Entwürfe, Kollaborationsfunktionen, Single-Sign-On, wenn Sie das SSO-Add-on hinzufügen (mehr dazu weiter unten).
- Realistisch für: die meisten produktiven Content-Seiten mit 1 bis 10 Editoren und unter 25.000 Dokumenten.
Enterprise-Plan
- Individuelle Preisgestaltung, Sales-verwaltet.
- Höhere Dokumentenlimits, benutzerdefinierte Aufbewahrung, erweiterte Sicherheit, dedizierter Support, SLA-gestützte Performance.
- Realistisch für: Seiten mit 50.000+ Dokumenten, regulierte Branchen, Unternehmen mit Beschaffungsanforderungen.
Das SSO-Add-on, das Growth teurer macht, als es aussieht
SAML SSO im Growth-Plan ist ein Add-on für 1.399 USD pro Monat. Für ein 5-köpfiges Team, das sonst 75 USD pro Monat zahlt, multipliziert das Hinzufügen von SSO die Kosten um das 19-fache. Wenn Ihre Sicherheitsrichtlinie SSO vom ersten Tag an verlangt, ist der Growth-Plan ein falsches Sparmodell und Sie zahlen effektiv Enterprise-Preise ohne Enterprise-Funktionsumfang. Das sollte man vor dem Commitment wissen.
Wo Sanity gewinnt (und welche Briefs es wählen)
Echtzeit-Redaktion über verteilte Teams hinweg
Sanitys Kollaborationsmodell ist das nächste, was es in headless CMS dem Arbeiten in einem Google Doc gleichkommt. Zwei Redakteure im selben Dokument sehen die Cursor des anderen. Kommentare werden in einzelnen Feldern gefädelt. Die Dokumentpräsenz ist in der Navigation sichtbar. Für Brand-Teams, Content-Marketing-Teams und alle, bei denen zwei oder mehr Personen regelmäßig im selben Dokument in derselben Stunde arbeiten, ist dies wirklich ein kategorieprägendes Feature.
Schema-Anpassung, die sich nicht wie eine CMS-Vorlage anfühlt
Das Studio ist eine React-App, die du auslieferst. Custom Input-Komponenten, Custom Previews, Custom Workflow-Buttons, Custom Validation, Custom Asset Pipelines — alles lebt in deinem Repo. Wenn dein Redaktionsteam spezielle Anforderungen hat (eine Custom Date-and-Timezone-Picker, die Feiertage ablehnt, ein Slug-Feld, das gegen eine Konkurrentenliste validiert, eine Custom Image Crop UI), ist Sanity Studio das einzige headless CMS, in dem du das bauen kannst, ohne gegen die Plattform anzukämpfen.
GROQ als Query-Sprache
GROQ ist ausdrucksvoller als GraphQL für Document-Graph-Queries. Du kannst über Referenzen hinweg joinen, verschachtelte Felder projizieren, auf berechnete Werte filtern und Listen in einer einzigen Query slicen. Der Trade-off ist, dass GROQ Sanity-spezifisch ist — du kannst deine Queries nicht anderswo verwenden. Für Teams, die komplexe Content Surfaces ausliefern (facettierte Verzeichnisse, Related-Content-Widgets, Multi-Locale-Fallback-Ketten), ist GROQ schneller zu schreiben und schneller zu iterieren als die äquivalente GraphQL-Query plus Frontend-Logik.
Visual Editing auf Next.js Front Ends
Sanitys Visual Editing Feature, seit 2025 allgemein verfügbar, ermöglicht es Redakteuren, direkt auf einer Next.js oder Nuxt Seite im Preview-Modus zu klicken und das zugrundeliegende Feld im Studio zu bearbeiten. Es ist die sauberste Visual-Editing-Geschichte im headless CMS Raum außerhalb von Storyblok. Wenn dein redaktioneller Workflow überwiegend Preview-First ist, ist dies ein echter Produktivitätsgewinn.
Wo Payload Sanity schlägt
Payload ist die richtige Wahl, wenn das Engineering-Team die Hauptrolle beim Build spielt und das Editor-Team in eine etwas stärker entwickler-orientierte Admin-Oberfläche eingearbeitet werden kann.
TypeScript-First-Schemas als kanonische Quelle
Payload-Schemas leben in deinen TypeScript-Dateien neben deinem Anwendungscode. Type Safety ist End-to-End: das Schema, der API-Client und deine Next.js-App teilen sich dieselben Typen ohne Code-Generierungsschritte. Sanitys Schema ist ebenfalls Code-definiert, aber der Type-Generierungsfluss ist aufwendiger und die TypeScript-Story ist weniger nativ.
Self-Hosted, deine Postgres-Datenbank, dein S3-Bucket
Payload ist die bessere Antwort, wenn Dateneigentum nicht verhandelbar ist. Das CMS läuft auf deiner Infrastruktur, die Datenbank ist deine Postgres- oder MongoDB-Instanz, die Assets sitzen in deinem S3-(oder kompatiblen) Bucket. Sanity speichert Dokumente auf Sanitys gehosteter Infrastruktur — in Ordnung für die meisten Teams, ein Dealbreaker für regulierte Branchen oder jedes Team mit einer „Keine Third-Party-Datenspeicher"-Richtlinie.
Local API ohne HTTP-Overhead
Sanitys Local API ermöglicht es dir, CMS-Funktionen direkt aus deinem Next.js-Code aufzurufen, ohne einen HTTP-Request zu senden. Für eng integrierte Apps, bei denen das CMS nur eine von mehreren Datenquellen ist, performed das messbar besser als Sanitys Netzwerk-Only-Zugriffsmuster.
Ich habe die Payload-versus-Strapi-Entscheidung ausführlich hier behandelt: Payload vs Strapi in 2026. Die Kurzversion hat die gleiche Form: Payload für TypeScript-lastige Teams, die Ownership wollen, Strapi für Teams, die ein reicheres Plugin-Ökosystem möchten.Payload vs Strapi in 2026. The short version is the same shape: Payload for TypeScript-heavy teams that want ownership, Strapi for teams that want a richer plugin ecosystem.
Wo Storyblok Sanity schlägt (ein spezifischer Fall)
Storyblok schlägt Sanity auf einer einzigen Dimension und nur einer: dem Visual Editor für Marketing-Teams, die Seiten Komponente-für-Komponente gestalten wollen, ohne Code anzufassen. Storybloks Visual Editor ermöglicht es einem nicht-technischen Marketing-Manager, einen Hero, Hero-with-CTA, Three-Column-Feature-Grid-Layout aus vordefinierten Komponenten-Blöcken zu bauen und die Live-Vorschau dabei zu sehen. Sanitys Visual Editing ist gut, aber es ist nicht um dieselbe Person herum designt.
Wenn Dein Editorial-Team von Marketing-First-Nutzern ohne technischen Hintergrund dominiert wird, die Seiten zusammenstellen möchten, ist Storyblok die richtige Wahl. Wenn Dein Editorial-Team Content-First arbeitet (Schreiber, Redakteure, Journalisten, Knowledge Manager), ist Sanitys Document-First-Editor die bessere Experience.
Migration zu Sanity: der realistische Weg
Aus WordPress
Standard-Pattern: WordPress-Inhalte via WP All Export exportieren, ins NDJSON-Format von Sanity transformieren, via Sanity CLI importieren. Das Schema-Mapping ist die eigentliche Arbeit — Pages, Posts, Custom Post Types, ACF-Felder brauchen alle ein Sanity-Äquivalent. Das WordPress-to-Next.js-Migration-Playbook deckt die SEO-Transport-Seite ab, die unabhängig vom CMS-Ziel relevant ist. Zeitaufwand bei einer 5.000-Seiten-Website: 4 bis 8 Wochen konzentrierte Arbeit für die Migration allein, länger wenn das Schema komplexe relationale Inhalte enthält.The WordPress to Next.js migration playbook covers the SEO transport side that applies regardless of CMS target. Time on a 5,000-page site: 4 to 8 weeks of focused work for the migration alone, longer if the schema includes complex relational content.
Aus Contentful
Einfacher als WordPress, weil Contentfuls Content-Modell sich sauber auf Sanitys Document-and-Reference-Struktur abbildet. Die Sanity-Migrations-Tools haben dedizierte Importer für Contentful-Exports. Realistischer Zeitrahmen bei einer ähnlich großen Website: 2 bis 4 Wochen.
Aus Drupal
Das schwierigste der drei, weil Drupals Entity-and-Bundle-Modell strukturell unterschiedlich ist. Die meisten Teams bauen das Schema in Sanity von Grund auf neu auf, anstatt automatisch zu migrieren. 6 bis 12 Wochen für eine komplexe mehrsprachige Drupal-Website.
FAQ
Ist Sanity HIPAA-konform?
Sanity veröffentlicht in seinem Growth-Plan keine HIPAA Business Associate Agreement, daher ist Sanity standardmäßig nicht HIPAA-berechtigt zur Speicherung von PHI. Enterprise-Kunden mit Healthcare-Workflows können eine benutzerdefinierte Datenschutzvereinbarung verhandeln, aber das ist nicht die Voreinstellung. Wenn deine Healthcare-App ein CMS benötigt, das PHI direkt speichert, ist Supabase mit dem HIPAA Add-on oder eine selbst gehostete Payload-Bereitstellung auf einem HIPAA-berechtigten Host ein defensiblerer Weg.
Ist Sanity besser als Contentful?
Für die meisten Teams im Jahr 2026 ja — Sanity bietet mehr Schema-Flexibilität, bessere Echtzeit-Zusammenarbeit, eine leistungsfähigere Query-Sprache (GROQ) und einen bedeutend niedrigeren Preis für vergleichbare Feature-Sets. Contentfuls Stärke liegt in Enterprise-Beschaffung und Integrationen mit Legacy-Marketing-Stacks. Wenn dein Team technisch versiert ist und der Editorial-Workflow Priorität hat, ist Sanity die bessere Wahl. Wenn deine Stakeholder einen beschaffungsfreundlichen Enterprise-Vertrag fordern, ist Contentful die sicherere Wahl.
Wie viel kostet Sanity für ein 5er-Team?
Im Growth-Plan 75 USD pro Monat für 5 Seats à 15 USD pro Seat. Wenn du SAML SSO benötigst, addiere 1.399 USD pro Monat — was das gleiche Team auf 1.474 USD monatlich bringt. Der kostenlose Plan deckt 20 Seats mit harten Limits ab, also wenn dein Team klein ist und deine Nutzung niedrig ist, könnte der kostenlose Tier dich im ersten Jahr durchbringen.
Kann ich Sanity mit Next.js verwenden?
Ja — Next.js ist 2026 das häufigste Frontend für Sanity. Das offizielle @sanity/client-Paket verwaltet die API-Aufrufe, GROQ-Abfragen laufen serverseitig in Server Components oder über API-Routen, und Visual Editing wird im Preview-Modus unterstützt. Sanity hat eine gepflegte Next.js-Starter-Vorlage; diese zu klonen ist der schnellste Weg zu einem funktionierenden Projekt.
Was ist GROQ und warum ist es wichtig?
GROQ ist Sanitys Content-Query-Sprache — eine graphen-förmige, projektionsbasierte Query-Sprache, die für die Art von Joins und Filtern entworfen ist, die Headless-CMS-Inhalte benötigen. Sie ist ausdrucksstärker als GraphQL für Document-Graph-Abfragen. Der Nachteil ist, dass GROQ Sanity-spezifisch ist, also bedeutet eine zukünftige Migration weg von Sanity das Umschreiben jeder Abfrage. Für die meisten Teams überwiegt der Produktivitätsgewinn kurzfristig das Lock-in-Risiko.
Verwandte Lektüre
WordPress-Alternativen 2026: wenn No-Code nicht die Antwort ist — der übergeordnete Beitrag zum Stack von Alternativen, einschließlich des Abschnitts zu Headless-CMS-Optionen. — the parent post on stack alternatives, including the section on headless CMS choices.
WordPress zu Next.js Migration ohne Ranking-Verluste — gilt unabhängig davon, ob dein CMS-Ziel Sanity, Payload oder etwas anderes ist. Der SEO-Transfer ist unabhängig vom CMS gleich. — applies whether your CMS target is Sanity, Payload, or anything else. The SEO transport is the same regardless of CMS.
Vor- und Nachteile von Headless-Architektur — ehrliche Kompromisse des Headless-Modells selbst, nützlich als Entscheidungsrahmen-Vorspiel. — honest tradeoffs of the headless model itself, useful as the decision framework prequel.
WordPress Stack Advisor — gib deine URL ein, erhalte eine maßgeschneiderte Empfehlung, die auch einschließt, ob Sanity das richtige CMS für dein spezifisches Projekt ist. — paste your URL, get a tailored recommendation that includes whether Sanity is the right CMS for your specific brief.
Die CMS-Wahl ist selten der Engpass. Der Engpass ist der erste Monat deines Editor-Teams mit dem neuen Tool. Wähle Sanity, wenn dein Editor-Team begeistert ist; wähle Payload, wenn dein Engineering-Team begeistert ist.
Buche einen 30-Minuten-CMS-Pick-Call — beschreibe das Projekt, das Team, die Timeline, die Integrationen, und geh mit einer ehrlichen Sanity-vs-Payload-vs-Storyblok-Entscheidung hinaus, die die Trade-offs transparent darstellt. — describe the brief, the team, the timeline, the integrations, and walk away with a Sanity-vs-Payload-vs-Storyblok decision that is honest about the trade-offs.