Warum wir Sanity.io als CMS einsetzen

Die Wahl des Content Management Systems entscheidet, wie effizient eine Website langfristig gepflegt werden kann. Zu viele CMS sind entweder entwicklerfreundlich aber für Redakteure mühsam — oder benutzerfreundlich aber technisch eingeschränkt.

Sanity.io macht diesen Kompromiss nicht. Es ist das CMS, das wir einsetzen, wenn es darum geht, strukturierte Inhalte professionell zu verwalten und nahtlos in moderne Web-Frontends zu integrieren.

Was Sanity.io ist

Sanity.io ist ein Headless CMS. Das bedeutet: Es liefert Inhalte über eine API — es kümmert sich nicht darum, wie diese Inhalte am Ende aussehen. Das Frontend (zum Beispiel SvelteKit, Next.js, oder eine mobile App) konsumiert die Daten über APIs und rendert sie nach eigenen Regeln.

Im Gegensatz zu klassischen Systemen wie WordPress hat Sanity kein eingebettetes Theme-System, keine enge Kopplung von Backend und Frontend. Das ist der Kern des Headless-Ansatzes: Inhalte und Präsentation sind getrennt.

Das Sanity-Ökosystem besteht aus:

• **Sanity Studio:** Die Editor-Oberfläche, vollständig konfigurierbar und in React gebaut
• **Content Lake:** Die gehostete Datenschicht von Sanity — skalierbar, ausfallsicher, global verteilt
• **GROQ:** Die eigene Query-Sprache von Sanity für präzise Abfragen der Inhalte
• **APIs:** REST- und Real-time-APIs für alle Anwendungsfälle

Schema-as-Code: Kontrolle über die Datenstruktur

Der stärkste technische Vorteil von Sanity: Das Datenmodell wird in Code definiert. Jedes Inhaltsfeld, jede Beziehung, jede Validierungsregel wird in TypeScript geschrieben — nicht in einem GUI-Dialog konfiguriert.

Das klingt technisch, hat aber einen direkten Einfluss auf Qualität und Wartbarkeit: Das Schema ist unter Versionskontrolle (Git), Änderungen sind nachvollziehbar, und das Datenmodell kann zwischen Projekten geteilt werden.

Bei einem Projekt für einen Verband mit komplexer Hierarchie (Mitglieder, Gruppen, Events, Dokumente) haben wir ein Datenmodell gebaut, das alle Relationen sauber abbildet — ohne Hacks oder Workarounds. Das wäre mit einem GUI-basierten CMS nicht möglich gewesen.

Was wir in Sanity-Schemas typischerweise definieren:

• Dokumenttypen mit Feldern und Validierungsregeln
• Referenzen zwischen Dokumenten (z.B. Case → Insight)
• Wiederverwendbare Objekte und Content Blocks
• Gruppen und bedingte Felder für klare Editor-UX

Sanity Studio: Die Redakteursoberfläche

Sanity Studio ist die Benutzeroberfläche für Content-Redakteurinnen und -redakteure. Was es besonders macht: Es ist vollständig anpassbar.

Wir konfigurieren das Studio für jedes Projekt so, dass es genau zur Arbeitsweise der Redaktion passt: Welche Dokumenttypen sind sichtbar? In welcher Reihenfolge? Welche Felder sind pflicht, welche optional? Welche Vorschau-URLs zeigt das Studio an?

Sanity Studio wird als React-App deployt — entweder auf Sanity-eigener Infrastruktur oder self-hosted. Das bedeutet: Redakteurinnen und Redakteure arbeiten in einer Web-App im Browser, ohne Software zu installieren.

Der visuelle Editor von Sanity (Presentation Tool) erlaubt Live-Previews: Änderungen in Studio erscheinen sofort in einer Vorschau des echten Frontends. Das reduziert Rückfragen und Missverständnisse zwischen Redaktion und Entwicklung.

GROQ: Abfragen, die genau das liefern, was man braucht

GROQ (Graph-Relational Object Queries) ist die Abfragesprache von Sanity. Sie erlaubt präzise, verschachtelte Abfragen mit eingebetteten Filtern und Projektionen.

Was das bedeutet in der Praxis: Das Frontend holt genau die Daten, die es braucht — nicht mehr, nicht weniger. Bei grossen Datensätzen ist das ein Performance-Gewinn. Keine übertragenen Felder, die nicht verwendet werden.

GROQ ist gut dokumentiert und verhältnismässig einfach zu lernen. Nach ein paar Stunden kann jeder Entwickler produktive Abfragen schreiben.

Beispiel: `*[_type == "case" && status == "published"]{title, slug, "categories": categories[]->{title}}` liefert nur Titel, Slug und Kategorientitel aller publizierten Cases — ohne andere Felder.

Real-time und Preview: Für moderne Workflows

Sanity hat eine Real-time-API: Änderungen im CMS sind sofort über die API sichtbar. Das ermöglicht Live-Previews ohne Caching-Probleme und Workflows, bei denen Staging-Umgebungen den Produktionsstand widerspiegeln.

Für Redakteurinnen und Redakteure, die Änderungen sofort sehen wollen, bevor sie publizieren, ist das ein greifbarer Komfortgewinn.

Bei einem Projekt mit täglich mehreren Inhaltsaktualisierungen war die Real-time-Funktion entscheidend: Das Redaktionsteam konnte Änderungen in Echtzeit reviewen, ohne Build-Pipelines zu triggern.

Wann Sanity die richtige Wahl ist

Sanity ist nicht das günstigste oder einfachste CMS — aber es ist das richtige, wenn:

• **Inhaltsstruktur komplex ist:** Viele Dokumenttypen, Relationen, wiederverwendbare Objekte
• **Redakteure professionell arbeiten:** Team mit klaren Rollen, Workflows, Review-Prozessen
• **Frontend entkoppelt sein soll:** Headless-Architektur für multiple Channels (Web, App, etc.)
• **Langfristige Wartbarkeit zählt:** Schema-as-Code und Versionierung sind langfristig günstiger
• **Performance wichtig ist:** GROQ-Abfragen nur das holen, was gebraucht wird

Für einfache Blogs oder Marketing-Websites ohne komplexe Inhaltsanforderungen gibt es günstigere Optionen. Für strukturierte, professionell gepflegte Inhalte ist Sanity unser Standard.

Das bringt dir Sanity.io konkret

• **Vollständige Datenkontrolle:** Schema in Code = nachvollziehbar, versioniert, wartbar
• **Massgeschneiderte Editor-UX:** Das Studio wird genau für deine Redaktion konfiguriert
• **Live-Preview:** Änderungen sofort sehen — ohne Publizieren und Warten
• **Performance:** Nur benötigte Daten werden übertragen — schnellere Seiten
• **Skalierbarkeit:** Content Lake wächst mit — keine eigene Datenbankinfrastruktur nötig
• **Zukunftssicherheit:** Headless erlaubt neue Frontends, ohne Inhalte neu zu erfassen