Sanity ist ein schoenes Stueck Infrastruktur fuer strukturierten Content. Fuer einen Blog ist es auch ein erheblicher Aufwand. Du definierst jeden Content-Typ als Code, du betreibst Sanity Studio als React-App, die du hosten und warten musst, du lernst GROQ, um irgendetwas abzufragen, und in dem Moment, in dem du eine zweite Sprache willst, entdeckst du, dass Mehrsprachigkeit etwas ist, das du selbst implementierst. Wenn das Lieferobjekt ein Marketing-Blog ist, ist das die falsche Art von Aufwand. Dieser Artikel zeigt, wann Sanity das richtige Werkzeug ist, wann es das nicht mehr ist und wie eine No-Config-Alternative aussieht.
Schnelluebersicht
- Sanity ist exzellent fuer strukturierten Content (Produktkataloge, Redaktionssysteme mit individuellen Workflows) und ueberzogen fuer einen Blog.
- Schema-as-code heisst, dass jeder Content-Typ in einer TypeScript-aehnlichen Konfigurationsdatei lebt, die du committest, reviewst und migrierst.
- Sanity Studio ist eine React-Anwendung, die du hostest, deployst und aktualisierst.
- Mehrsprachiger Content ist Bring-your-own: Plugin waehlen, Felder pro Locale modellieren, Routing bauen.
- Kamaan ist ein Blog-First-CMS ohne Schema-Konfiguration, ohne Studio zum Warten und mit 99+ Sprachen beim Veroeffentlichen.
Die Reibung mit Sanity, fuer einen Blog
Wenn du Sanity zum ersten Mal fuer einen Blog einrichtest, ist die Erfahrung in Ordnung. Du installierst das CLI, fuehrst sanity init aus, bekommst ein Starter-Schema, deployst Studio. Nach zwei Monaten zeigt sich die Reibung.
Jedes neue Feld ist eine Code-Aenderung. Willst du eine zweite Autorenzeile, einen FAQ-Block, ein Lesezeit-Feld, eine Kategorien-Taxonomie mit Eltern-Kategorien? Jede dieser Aenderungen ist eine Bearbeitung einer Schema-Datei, ein Pull Request, ein Studio-Deploy und oft ein Content-Migrationsskript, um bestehende Dokumente nachzufuellen. Fuer ein Team, in dem Redakteur und Entwickler dieselbe Person sind, ist das in Ordnung. Fuer ein Marketing-Team, das einfach Posts veroeffentlichen will, ist das Reibung an der falschen Stelle.
GROQ ist die naechste Ueberraschung. Es ist eine gute Abfragesprache. Es ist auch eine Abfragesprache, die niemand in deinem Team kennt. Jedes "zeige drei verwandte Posts" oder "liste Posts nach Tag, ohne Drafts" verlangt, dass jemand GROQ schreibt, es im Vision-Tool testet und die Abfrage ins Frontend bringt. Im Vergleich zu einem CMS, das dir einen REST-Endpunkt liefert, der posts?tag=launch zurueckgibt, ist GROQ eine Lernsteuer, die du fuer immer zahlst.
Mehrsprachigkeit ist der Punkt, an dem die meisten Teams an die Wand fahren. Sanity liefert Mehrsprachigkeit nicht out of the box. Du entscheidest zwischen Uebersetzung auf Feld-Ebene (ein Dokument, locale-suffixierte Felder) und auf Dokument-Ebene (ein Dokument pro Sprache, ueber Referenzen verbunden). Dann installierst du ein Plugin, modellierst dein Schema entsprechend, baust den Sprachumschalter, konfigurierst den Router und entscheidest, was passiert, wenn eine Uebersetzung fehlt. Nichts davon ist schwer. Alles davon ist Arbeit, die nichts mit dem Veroeffentlichen eines Blogposts zu tun hat.
Sanity Studio ist das letzte Stueck. Es ist eine React-App. Du hostest sie. Du aktualisierst sie. Wenn neue Sanity-Pakete erscheinen, aktualisierst du. Wenn ein Content-Modellierer ein Schema aendert, deployst du neu. Fuer einen Blog betreibst du ein kleines Frontend-Projekt fuer das Privileg, Text zu editieren.
Wo Sanity wirklich die richtige Wahl ist
Bevor wir weitergehen, der ehrliche Fall fuer Sanity. Wenn dein Content strukturell reich ist und ueber viele Oberflaechen wiederverwendet wird (ein Produktkatalog mit Varianten, eine Lernplattform mit Lektionen, Modulen und Tracks, eine Redaktion mit individuellen Workflows und Freigabe-Gates), ist Sanity aussergewoehnlich. Portable Text, Referenzen, eigene Eingabekomponenten, Echtzeit-Zusammenarbeit in Studio und die Faehigkeit, denselben Content aus Web, App und E-Mail-Templates per GROQ abzufragen, zahlen den Konfigurationsaufwand zurueck.
Fuer einen Blog ist nichts davon der Engpass. Der Engpass ist "wir wollen einen Post veroeffentlichen und ihn, gerankt, in fuenf Sprachen erscheinen sehen." Darauf optimiert Sanity nicht. Kamaan schon.
Hier ist die Kurzfassung der Alternative auf einer einzigen Karte.
Wie Kamaan dieselbe Aufgabe loest
Kamaan ist ein Blog-CMS. Die Meinungen sind bewusst gesetzt. Posts haben Titel, Body, Featured Image, Tags, Autor, SEO-Felder und Uebersetzungen. Du konfigurierst dieses Schema nicht. Es ist das Produkt.
Einen Post zu veroeffentlichen ist eine einzige Aktion. Kamaans automatische mehrsprachige Auslieferung erzeugt Uebersetzungen in 99+ Sprachen innerhalb von Sekunden nach dem Veroeffentlichen, mit korrekt verdrahtetem hreflang, Eltern- und Kind-Artikel-Links automatisch gehandhabt und ohne Plugin zur Installation. REST API Delivery stellt denselben Content als reines JSON bereit, mit Query-Parametern fuer Tag, Sprache und Pagination. Keine neue Query-Sprache zu lernen. Kamaans Multi-Site-Management laesst einen Workspace mehrere Markenseiten bedienen, mit geteilten Medien und SEO pro Site. AI-Publishing ueber den MCP Server und ChatGPT Actions bedeutet, dass du aus Claude oder ChatGPT direkt ins CMS schreiben und veroeffentlichen kannst.
Das Preismodell ist ein einziger Flat-Preis von 19 $ pro Monat, mit dem ersten Monat gratis und einem Lifetime-Plan, falls du lieber einmal zahlst. AI-Uebersetzungs-Credits werden nur verbraucht, wenn du Kamaan bittest, fuer dich zu uebersetzen; bring Uebersetzungen aus Claude oder ChatGPT mit und du gibst nichts zusaetzlich aus. Kamaan ist derzeit in Private Beta und oeffnet 50 Founder-Plaetze im dritten Quartal 2026.
Der Kompromiss ist ehrlich. Du gibst die Faehigkeit auf, beliebigen strukturierten Content zu modellieren. Du bekommst die Faehigkeit zurueck, heute zu veroeffentlichen, in jeder Sprache, in der du verkaufst, ohne Entwickler im Loop.
Sanity vs Kamaan vs Contentful, fuer einen Blog
| Faehigkeit | Sanity | Kamaan | Contentful |
|---|---|---|---|
| Schema-Setup | Code-definiert, pro Content-Typ | Nicht noetig, Blog-Modell eingebaut | UI-Builder mit Content-Typen |
| Editier-UI | Sanity Studio (React-App, die du hostest) | Gehostetes Editor, keine Installation | Gehostete Web-App |
| Abfragesprache | GROQ | REST mit Query-Parametern | REST und GraphQL |
| Mehrsprachig beim Veroeffentlichen | Bring-your-own Plugin und Modellierung | Auto-Multilingual Delivery, 99+ Sprachen | Locale-Felder, manuelle Uebersetzung |
| Multi-Site-Modell | Ein Projekt pro Site oder Shared-Dataset-Muster | Multi-Site Management eingebaut | Spaces, mit Sitzkosten |
| KI-Publishing | Plugin-Arbeit noetig | MCP Server und ChatGPT Actions nativ | Drittanbieter-Integrationen |
| Zeit bis zum ersten veroeffentlichten Post | Tage, mit Entwicklerzeit | Selber Tag, ohne Entwickler | Tage |
| Preis-Ueberraschungs-Risiko | API-Call-Limits auf Wachstumsstufen | Flat-Plaene, kein Per-Call-Zaehler | Per-Sitz- und Per-Record-Limits |
Ein echtes Publishing-Szenario
Ein Zwei-Personen-Gruenderteam waehlt Sanity, weil es ein Freund empfohlen hat. Woche eins: ein Starter-Blog laeuft. Woche zwei: sie wollen Kategorien, eine Autorenbio und einen Related-Posts-Block. Zwei Pull Requests, ein Studio-Redeploy, eine kleine Migration, um fehlende Felder in bestehenden Posts zu fuellen. Woche drei: sie wollen spanische und deutsche Versionen, weil ihre ersten Kunden in Madrid und Berlin sitzen. Sie evaluieren zwei i18n-Plugins, waehlen eines aus, refaktorieren das Schema, ueberarbeiten das Routing in ihrer Next.js-App und schreiben eine Fallback-Strategie fuer fehlende Uebersetzungen. Woche vier: sie haben eine spanische Version von drei der neun Posts.
Dasselbe Team auf Kamaan haette an Tag eins neun Posts auf Englisch veroeffentlicht, Spanisch und Deutsch beim Veroeffentlichen erzeugt und Woche zwei damit verbracht, weitere Posts zu schreiben statt i18n zu bauen. Der strukturelle Unterschied ist nicht der Aufwand. Es ist, was dieser Aufwand erkauft.
Ein anderes Szenario. Eine E-Commerce-Marke hat einen Produktkatalog mit dreihundert SKUs, eigenen Merchandising-Regeln, regionsspezifischen Beschreibungen und einem Marketing-Blog. Fuer den Katalog ist Sanity das richtige Werkzeug. Fuer den Blog lass ihn auf Kamaan laufen und gib dem Katalog sein eigenes Zuhause. Zwei Systeme sind keine Niederlage; es ist eine ehrliche Trennung der Verantwortlichkeiten. Das Produkt-Team bekommt Portable Text und Studio-Erweiterungen fuer den Katalog; das Marketing-Team bekommt ein CMS, das Posts in fuenf Sprachen veroeffentlicht, ohne ein Ticket an die Entwicklung.
Ein drittes Szenario. Ein Solo-Gruender, der ein SaaS betreibt, will einen Post pro Woche veroeffentlichen, auf Englisch plus die vier Sprachen, in denen Kunden tatsaechlich kaufen. Auf Sanity sind das mehrere Wochen Setup, bevor der erste Post live geht. Auf Kamaan ist es eine Anmeldung, ein Post und ein Publish. Der Gruender nutzt die gesparte Woche, um die naechsten drei Posts zu schreiben, statt ein i18n-Plugin zu konfigurieren.
Eine Seite-an-Seite-Ansicht, wie sich die beiden Systeme in den Dimensionen unterscheiden, die fuer einen Blog wichtig sind, ist unten.
FAQ
Ist Kamaan ein Fork von Sanity oder ein Wrapper darum?
Nein. Kamaan ist sein eigenes CMS. Es ist nicht auf Sanity gebaut, nutzt kein GROQ und braucht kein Sanity Studio. Das Content-Modell, die API-Form und der Editor sind unabhaengig.
Was ist mit Sanitys Echtzeit-Zusammenarbeit?
Echtzeit-Multi-Cursor-Editieren in Studio ist eine echte Staerke von Sanity fuer Redaktionen, die gleichzeitig am selben Dokument arbeiten. Kamaan fokussiert auf Solo- und Klein-Team-Blog-Workflows, in denen Konflikte selten sind und das Autosave-plus-History-Modell ausreicht.
Kann ich von Sanity zu Kamaan exportieren?
Ja. Kamaan unterstuetzt Imports aus gaengigen CMS-Export-Formaten und aus einem JSON-Dump deines Sanity-Datasets. Das Migrationsskript mappt Felder, bringt Bilder mit und erhaelt Slugs, damit bestehende URLs weiter funktionieren.
Verliere ich Portable-Text-Funktionen beim Umzug?
Einige. Portable Text ist grossartig fuer eigene Block-Typen (Inline-Referenzen, Callouts, eigene Embeds). Kamaan nutzt ein einfacheres Block-Modell, fokussiert auf Blog-Content: Absaetze, Ueberschriften, Listen, Bilder, Zitate, Code und Embeds. Wenn dein Blog auf einer langen Liste eigener Block-Typen aufbaut, ist das ein Punkt, den du vor dem Umzug pruefen solltest.
Wie behandelt Kamaan SEO im Vergleich zu Sanity?
Sanity gibt dir die Felder, wenn du sie modellierst. Kamaan liefert sie: Meta-Titel, Meta-Description, Focus-Keyword, Slug, OG-Felder, Twitter-Card-Felder, Canonical-URL und hreflang ueber Locales hinweg. Sitemap und Robots werden auf Site-Ebene verwaltet. Der Punkt ist nicht, dass Sanity es nicht koennte; es ist, dass du es nicht bauen musst.
Was ist der Preisunterschied in der Praxis?
Sanitys Free-Tier ist grosszuegig fuer Prototypen; die Kostenkurve erscheint, wenn deine API-Requests, die Dataset-Groesse und die Sitze wachsen. Kamaan nutzt Flat-Per-Site-Plaene ohne Per-API-Call-Zaehler. Fuer einen High-Traffic-Blog mit haeufigen Re-Fetches summiert sich der Unterschied.
Kann ich Kamaan mit Next.js, Nuxt, SvelteKit oder Astro nutzen?
Ja. Kamaans REST API Delivery liefert JSON; das Frontend-Framework ist deine Wahl. Beispielintegrationen existieren fuer Next.js, Nuxt, SvelteKit und Astro.
Was, wenn ich aus Kamaan herauswachse?
Du exportierst. Kamaan bietet einen vollstaendigen Content-Export nach JSON, inklusive Uebersetzungen und Medien-URLs. Das ist eine bewusste Zusage: wenn der Fit sich aendert, ist die Tuer offen.
Verwandtes auf Kamaan
- Bestes Headless-CMS fuer Startups
- Contentful-Alternativen
- Was ist ein Headless-CMS
- Wie du einen Blog zu deinem SaaS hinzufuegst
Mit Kamaan starten
Wenn dein Job ein Blog ist und dein Team klein, zahlt der Schema-as-code-Pfad eine Entwicklersteuer, die nichts kauft, was du brauchst. Kamaan liefert das Blog-Modell, die mehrsprachige Pipeline und die KI-Publishing-Integrationen als Produkt. Starte eine Site, fueg einen Post ein und sieh, wie er in 99+ Sprachen in einem Publish erscheint.
