Was ist Sanity? Das Headless CMS aus der Praxis erklärt

Sanity ist ein Headless CMS: ein Content-Management-System, das Inhalte von ihrer Darstellung trennt. Deine Texte, Bilder und Produktdaten liegen als strukturierte JSON-Dokumente im Content Lake, Sanitys gehostetem Datenspeicher. Von dort holt sich jeder Kanal die Inhalte per API: Website, App, Newsletter oder Datenfeed. Sanity ist API-first gedacht — die Schnittstelle ist der Kern des Produkts, kein nachgerüsteter Seiteneingang.

«Headless» meint genau diese Trennung von Inhalt und Ausgabe. Ein klassisches CMS wie WordPress liefert Inhalt und fertige HTML-Seite aus einem Guss; Sanity liefert nur Daten. Wie daraus Seiten werden, entscheidet dein Frontend. Bei uns ist das Next.js, es könnte aber ebenso eine native App, ein Bildschirm im Ladengeschäft oder ein Print-Export sein.

Kurz zur Benennung, weil sie oft verwirrt: Du findest das Produkt unter sanity.io, gesprochen wird von «Sanity», «Sanity CMS» oder vom «Sanity Studio». Gemeint ist immer dasselbe System; das Studio ist lediglich die Redaktionsoberfläche darin. Ich bleibe in diesem Artikel bei Sanity.

Der zweite Schlüsselbegriff heißt Structured Content: Inhalte werden nicht als fertige Seiten gespeichert, sondern als sauber getypte Datenfelder. Ein Blogartikel ist bei Sanity kein HTML-Klumpen, sondern ein Dokument mit Titel, Slug, Autoren-Referenz und Textblöcken. Diese Struktur ist der Grund, warum sich Inhalte später abfragen, umbauen und mehrfach verwenden lassen.

Ein Beispiel macht das greifbar: Angenommen, du pflegst 80 Produkte mit Datenblättern. Als strukturierte Dokumente speisen sie die Website, den Katalog-Export und die Preisliste; als klassische Seiten wären sie 80-mal Layout mit eingebackenem Text. Der Unterschied klingt akademisch und kostet im zweiten Jahr echtes Geld, nämlich dann, wenn der Katalog neu erscheinen soll.

Für dich als Entscheider ist damit die wichtigste Einordnung gesetzt: Sanity ist kein Website-Baukasten, sondern eine Content-Plattform. Die Investition steckt weniger in Lizenzen als in der sauberen Modellierung deiner Inhalte. Dafür bekommst du ein System, das Kanäle überdauert: Die Website von heute ist nur der erste Abnehmer der Daten.

Warum ich das beurteilen kann: Wir setzen Sanity selbst ein. happycoding.agency läuft darauf, samt diesem Blog, und wir bauen Kundenprojekte damit. Dieser Artikel ist deshalb keine Nacherzählung der Produktseite, sondern eine Einordnung aus der Praxis: wie Sanity arbeitet, was es von WordPress, Contentful und Strapi unterscheidet, was es kostet und für wen es passt.

Vorab die Landkarte: Sanity besteht aus einem gehosteten Datenspeicher (Content Lake), einer Abfragesprache (GROQ), einem anpassbaren Redaktionswerkzeug (Sanity Studio) und einem JSON-Format für Fließtext (Portable Text). Wer diese vier Bausteine verstanden hat, hat Sanity verstanden. Ich gehe sie der Reihe nach durch.

Der Content Lake ist der Kern des Systems: Sanitys gehosteter Datastore, in dem jedes Stück Inhalt als JSON-Dokument liegt. Die Sanity-Dokumentation beschreibt ihn als Speicher, der Inhalte strukturiert hält: abfragbar, referenzierbar und bereit zur Auslieferung in jeden Kanal. Genau diese drei Eigenschaften machen im Alltag den Unterschied.

Referenzen sind der unterschätzte Teil davon. Eine Autorin existiert genau einmal und wird von 40 Artikeln referenziert; ändert sich ihre Bio, ändert sie sich überall. In einem seitenbasierten CMS kopierst du solche Informationen von Seite zu Seite, und irgendwann laufen die Kopien auseinander. Strukturierte Referenzen beenden dieses stille Auseinanderdriften.

Organisiert wird der Bestand in Projekten und Datasets. Ein Dataset ist ein abgeschlossener Datenbestand, typischerweise einer für Produktion und einer für Tests; der Free-Plan enthält zwei öffentliche Datasets, ab dem Growth-Plan dürfen sie privat sein. Dokumente, Attribute und Requests sind je Plan limitiert, die Zahlen dazu kommen weiter unten.

Für die Auslieferung gibt es zwei Wege. Das API-CDN ist eine weltweit verteilte, gecachte Version der Sanity-API; es trägt den Löwenanteil des Traffics einer normalen Website. Die Live Content API liefert Änderungen in Echtzeit aus, etwa für Vorschauen oder Live-Dashboards. Betrieben wird das Ganze als SaaS: Die Datenhaltung liegt auf Google Cloud in der EU (Belgien).

GROQ steht für Graph-Relational Object Queries: eine bei Sanity entwickelte Sprache zum Filtern und Projizieren von JSON-Dokumenten. Eine Abfrage beschreibt in einer Zeile, welche Dokumente du brauchst und welche Felder zurückkommen sollen. *[_type == "blogPost" && language == "de"]{title, slug} liefert Titel und Slug aller deutschen Artikel — nicht mehr, nicht weniger.

Aus unserer Projektpraxis: GROQ ersetzt das, wofür wir andernorts eigene REST-Endpunkte bauen oder GraphQL-Schemata pflegen. Die Abfrage hinter unserer Blogübersicht holt Artikel, Kategorien und Autor in einem einzigen Request, inklusive aufgelöster Referenzen. Das ist Backend-Code, den niemand schreiben und später niemand warten muss. Genau daher kommt ein guter Teil der Geschwindigkeit in Sanity-Projekten.

Für Redakteure bleibt GROQ übrigens unsichtbar: Im Studio arbeiten sie mit Formularen und Vorschauen. Die Abfragesprache ist Werkzeug der Entwickler, so wie SQL in einer Fachanwendung.

Wichtig für die Bindungsfrage: GROQ ist als offener Standard unter dem Open Web Foundation Agreement (OWFa 1.0) veröffentlicht, die Spezifikation ist öffentlich einsehbar. Es existieren quelloffene Implementierungen wie groq-js oder go-groq, die GROQ auch außerhalb des Content Lake ausführen — beide allerdings von Sanity selbst entwickelt. Du lernst also eine dokumentierte Sprache, keine Blackbox eines einzelnen Anbieters.

Das Studio ist die Oberfläche, in der Redakteure arbeiten, und der Punkt, an dem Sanity sich am deutlichsten von anderen Systemen absetzt. Es ist Open Source unter MIT-Lizenz: im Kern eine React-Anwendung, die du mit JavaScript an deine Abläufe anpasst. Mehrere Personen arbeiten dabei gleichzeitig am selben Dokument, Änderungen erscheinen in Echtzeit.

Die Inhaltsstruktur definierst du als Code. Jedes Feld, jede Validierung, jede Vorschau liegt im Git-Repository und durchläuft dieselbe Review wie der Rest des Projekts. Für dich als Entscheider heißt das: Die Redaktionsumgebung ist Teil deiner Software, kein gemietetes Formular, das du nehmen musst, wie es kommt.

Was «anpassen» konkret heißt: eigene Eingabemasken für wiederkehrende Bausteine, Validierungen wie «metaTitle höchstens 60 Zeichen», Vorschaukarten mit Bild und Status. Solche Leitplanken fangen Fehler vor der Publikation ab, nicht danach. Das erspart dem Team Korrekturschleifen nach dem Livegang.

Beim Hosting hast du die Wahl. Sanity hostet das Studio auf Wunsch unter deinprojekt.sanity.studio, ein Befehl genügt (npx sanity@latest deploy). Alternativ liegt es als statische Single-Page-App auf Vercel, Netlify, Cloudflare Pages oder deinem eigenen Server; dafür brauchst du SPA-Routing und trägst die Domain in den CORS-Einstellungen des Projekts ein.

Auch KI-Unterstützung steckt inzwischen im Studio: AI Assist hilft Redakteuren direkt im Editor, die Pläne enthalten dafür monatliche AI-Credits. Was das im Redaktionsalltag bringt, habe ich im Artikel über AI Assist in Sanity aufgeschrieben.

Rich Text ist die Achillesferse vieler CMS: Was der Editor als HTML speichert, klebt für immer an einer Darstellungsform. Sanity löst das mit Portable Text, einer JSON-basierten Spezifikation für Rich Text unter MIT-Lizenz. Absätze sind Blöcke, Auszeichnungen sind Spans mit Annotationen — alles bleibt Daten.

Beim Rendern entscheidest du, was daraus wird: HTML für die Website, Markdown für die Doku, SSML für Sprachausgabe oder XML für ein Drittsystem. Für diesen Blog heißt das konkret: Die Artikel liegen als Portable Text im Content Lake, die Website macht daraus React-Komponenten mit eigenen Bausteinen für Tabellen, Zitate und Code. Kein HTML-Parsing, kein Nachformatieren.

Der Kontrast zeigt sich spätestens beim Redesign: Portable Text übersteht den Wechsel des Frontends unverändert, während im HTML gespeicherte Inhalte Handarbeit bedeuten. Aus Migrationsprojekten kenne ich beide Seiten dieser Rechnung.

Zur Einordnung: Headless CMS ist eine Kategorie, kein Alleinstellungsmerkmal. Die drei Systeme, gegen die Sanity in unseren Projektanfragen am häufigsten antritt, sind WordPress, Contentful und Strapi. Erst die Kurzfassung als Tabelle, danach die Bewertung im Einzelnen. Alle Preise sind Listenpreise in US-Dollar, Stand September 2026; ein Systemvergleich ist dabei immer auch ein Vergleich der Betriebsmodelle, nicht nur der Funktionen.

WordPress zuerst, weil es der Standardvergleich ist. WordPress ist ein Monolith: Inhalte, Templates und Auslieferung stecken in einem System, erweitert über Themes und Plugins. Für eine überschaubare Marketing-Website mit einem Redakteur ist das oft die richtige Antwort, und genau das sage ich Interessenten auch.

Die Grenze kommt an zwei Stellen: wenn Inhalte in mehrere Kanäle sollen und wenn das Plugin-Geflecht zur Wartungslast wird. WordPress-Betrieb heißt laufende Updates für Core, Themes und Plugins; wer sie vernachlässigt, riskiert Sicherheitslücken. Das ist kein Argument gegen WordPress, aber ein Kostenposten, den viele Rechnungen unterschlagen.

Die ausführliche Gegenüberstellung findest du im Vergleich WordPress vs. Sanity; die Kostenseite über drei Jahre rechnet der TCO-Vergleich WordPress vs. Sanity + Next.js durch.

Contentful ist der direkteste Konkurrent: ebenfalls headless, ebenfalls SaaS. Der erste Unterschied ist das Preismodell. Contentfuls Einstiegsplan «Lite» kostet pauschal 300 $ pro Monat (Stand September 2026, laut übereinstimmenden Preisübersichten); bei Sanity beginnt der bezahlte Growth-Plan bei 15 $ pro Nutzer und Monat. Zwischen 0 $ und 300 $ liegt für kleinere Teams eine breite Lücke, die Sanity mit Free- und Growth-Plan feiner abstuft.

Der zweite Unterschied betrifft die Redaktionsoberfläche: Contentful vermietet dir eine fertige SaaS-Oberfläche, das Sanity Studio gehört dir als Open-Source-Code. Für ein Team mit gewachsenen Abläufen ist das mehr als ein Detail — es entscheidet, ob sich das Werkzeug dem Team anpasst oder das Team dem Werkzeug.

Strapi geht den umgekehrten Weg: Das System ist Open Source und läuft auf deinem Server, mit Datenbank in deiner Hoheit. Wer nicht selbst betreiben will, bucht Strapi Cloud; der Starter-Plan kostet dort 35 $ pro Projekt und Monat. Der Kernunterschied zu Sanity: Bei Strapi betreibst und skalierst du das Backend selbst, bei Sanity ist der Content Lake immer gehostet.

Auch die Abrechnungslogik unterscheidet sich: Strapi Cloud rechnet pro Projekt ab, Sanity pro Nutzer. Meine Faustregel daraus: Wer strikte On-Premise-Vorgaben hat, fährt mit Strapi besser. Wer den Betrieb abgeben will und Wert auf die anpassbare Redaktionsumgebung legt, landet bei Sanity.

Zum Frontend: Sanity schreibt dir keines vor, jede Technologie mit HTTP-Client funktioniert. In der Praxis sehen wir ein Gespann besonders häufig, auch bei uns selbst: Sanity plus Next.js, gehostet auf Vercel. Drei Gründe sprechen für diese Kombination.

Vorschau im echten Layout: Redakteure sehen Entwürfe in der realen Website, bevor irgendetwas live geht. Next.js blendet dafür die Draft-Inhalte aus dem Content Lake in die reguläre Seite ein. Das beendet die Blindflug-Freigaben, bei denen ein Text erst nach dem Livegang zum ersten Mal im Layout zu sehen ist.

Statische Seiten mit gezielter Auffrischung: Next.js rendert Seiten statisch vor und erneuert sie bei Bedarf, das Verfahren heißt Incremental Static Regeneration. Ein GROQ-Webhook aus Sanity meldet jede Publikation, und nur die betroffene Seite wird neu gebaut; schon der Free-Plan enthält zwei solcher Webhooks. Wie sich das bei Lastspitzen verhält, zeigt der Artikel Wie skaliert Sanity bei hohem Traffic?.

Ein Sprach-Stack für alles: Schema, Studio-Anpassungen und Frontend sind TypeScript und React. Ein Team, eine Sprache, ein Repository — das senkt die Übergabekosten zwischen den Gewerken spürbar. Genau solche Setups bauen wir für Kunden; was dazugehört, liest du auf unserer Leistungsseite Sanity Headless CMS.

Zur Einordnung: Das Duo ist eine Empfehlung, kein Zwang. Sanity funktioniert ebenso mit Astro, SvelteKit oder einer nativen App, die API bleibt dieselbe. Wenn dein Team bereits einen Frontend-Stack beherrscht, spricht wenig dagegen, ihn zu behalten.

Vorab die gute Nachricht: Der Einstieg kostet nichts. Der Free-Plan ist dauerhaft kostenlos und großzügig geschnitten: 20 Nutzer, 10.000 Dokumente, 1 Million CDN-Requests pro Monat, dazu je 100 GB Asset-Speicher und Bandbreite. Für viele Firmenwebsites reicht das über Jahre. Alle Preise sind in US-Dollar angegeben; maßgeblich ist die offizielle Preisseite.

Der Growth-Plan kostet 15 $ pro Nutzer und Monat, bis zu 50 Nutzer. Er bringt fünf Rollen statt zwei, private Datasets und 25.000 Dokumente. Ein Rechenbeispiel: Fünf Redakteure plus zwei Entwickler ergeben 105 $ pro Monat. Überschreitest du ein Limit, zahlst du nutzungsbasiert nach, etwa 1 $ je zusätzliche 250.000 CDN-Requests oder 0,50 $ pro GB Asset-Speicher.

Darüber liegt der Enterprise-Plan mit individuellen Limits, SSO, Uptime-SLA und dediziertem Support zu Custom Pricing. Dazwischen bietet Sanity Add-ons für den Growth-Plan an, zum Beispiel erweiterte Quotas für 299 $ pro Monat oder zusätzliche Datasets für 999 $ pro Dataset und Monat. Wichtig fürs Budget: Sanity deckelt nicht hart, sondern rechnet Überschreitungen nutzungsbasiert ab — planbar, solange jemand die Verbrauchswerte im Blick behält.

Die ehrliche Kostenrechnung endet allerdings nicht bei den Lizenzkosten: Entwicklung, Betrieb des Frontends und gelegentliche Overages gehören dazu. Die vollständige Rechnung mit Beispielszenarien findest du im Detailartikel Was kostet Sanity?.

Radikale Ehrlichkeit gehört zum Handwerk: Sanity ist ein Werkzeug für bestimmte Aufgaben, keine Universalempfehlung. Hier meine Abgrenzung, destilliert aus den Projekten und Anfragen der letzten Jahre. Die Liste ist bewusst zugespitzt: Sie soll dir eine Entscheidung ermöglichen, keine Feature-Parade liefern.

… Inhalte mehrere Kanäle bedienen. Website, App, Newsletter und Datenfeeds aus einer Quelle: Genau dafür ist Structured Content gebaut. Jeder Kanal fragt per GROQ exakt die Felder ab, die er braucht.

… ein Entwicklerteam vorhanden ist. Schema, Studio und Frontend sind Code. Wer diesen Code pflegen kann, bekommt eine Redaktionsumgebung, die exakt zu den eigenen Abläufen passt, statt sich fremden Abläufen beugen zu müssen.

… Inhalte eigentlich Daten sind. Produktkataloge, Team-Verzeichnisse, Standorte, Kursprogramme: Überall dort, wo Referenzen und Feldtypen wichtiger sind als Seitenlayouts, spielt der Content Lake seine Stärke aus.

… mehrere Redakteure zusammenarbeiten. Das Studio ist auf Echtzeit-Zusammenarbeit gebaut, mehrere Personen bearbeiten gleichzeitig denselben Bestand. Ab dem Growth-Plan trennen fünf Rollen sauber, wer strukturieren, schreiben oder nur lesen darf.

… du eine Marketing-Site ohne Entwickler betreibst. Ohne Team, das Schema und Frontend pflegt, wird jede Strukturänderung zum Agenturauftrag. Dann fährst du mit WordPress samt gutem Theme meist günstiger und schneller.

… alles auf eigenen Servern laufen muss. Der Content Lake ist immer SaaS, eine On-Premise-Variante existiert nicht. Bei strikten Infrastruktur-Vorgaben ist Strapi auf eigener Hardware die sauberere Antwort. Immerhin: Die Datenhaltung liegt bei Sanity auf Google Cloud in der EU.

… das Budget nur eine Website hergibt. Headless bedeutet zwei Gewerke, CMS und Frontend. Wenn absehbar nie ein zweiter Kanal dazukommt, kauft dir der Aufpreis wenig Nutzen ein.

Die Reduktion aufs Einfachste: Sanity lohnt sich, wenn deine Inhalte länger leben als dein aktuelles Frontend. Wenn nicht, nimm das einfachere Werkzeug.

Du überlegst, ob Sanity zu deinem Projekt passt? Dann prüfe drei Fragen: Bedienen deine Inhalte in den nächsten drei Jahren mehr als einen Kanal? Gibt es ein Team, das Schema und Frontend pflegen kann? Und rechnet sich der Umstieg gegen die laufenden Kosten deines heutigen Systems? Diese Antworten wiegen schwerer als jedes Feature-Datenblatt.

Wenn du sie nicht allein beantworten willst: Ich schaue mir dein Setup an und sage dir auch dann meine Einschätzung, wenn Sanity die falsche Wahl ist. Buch dir ein kostenloses Erstgespräch — 30 Minuten, danach weißt du, ob sich der Weg lohnt und wie die ersten Schritte aussehen.