Sanity CMS: Wie Wir Damit in 10 Sprachen Veröffentlichen

Sanity CMS: Wie Wir Damit in 10 Sprachen Veröffentlichen

Über 400 Inhaltsbeiträge haben wir auf 4 Websites und in 10 Sprachen über Sanity CMS veröffentlicht. Was wir dabei gelernt haben -- vom Schema-Design bis zur automatisierten mehrsprachigen Veröffentlichung.

Sanity CMS ist eine Headless-Content-Plattform, die auf strukturiertem Content, einem echtzeitfähigen Content Lake und einem anpassbaren React-basierten Editor namens Sanity Studio aufgebaut ist. Für Abfragen wird GROQ verwendet, für Rich Content Portable Text und für das Content-Modeling Schema-as-Code. Dieser Leitfaden behandelt Einrichtung, Schema-Design, GROQ, Portable Text, mehrsprachige Architektur und Preise.

Was Ist Sanity CMS?

Sanity ist eine strukturierte Content-Plattform -- das Team von Sanity.io bezeichnet sie als "Content Operating System." Anders als traditionelle CMS-Systeme, die HTML-Blöcke in einer Datenbank speichern, legt Sanity jeden Inhalt als strukturiertes JSON in einem verwalteten Backend namens Content Lake ab. Sie fragen ihn mit GROQ oder GraphQL ab und rendern den Content in jedem beliebigen Frontend: Next.js, React Native, Svelte, einer mobilen App, einem CLI-Tool -- was auch immer Sie brauchen.

Die Unternehmen, die Sanity einsetzen, sind äußerst vielfältig. Nike, Figma, Puma und Cloudflare betreiben Sanity im Enterprise-Maßstab. Startups nutzen es, weil der kostenlose Tarif wirklich brauchbar ist (mehr zu den Preisen weiter unten). Wir nutzen es, weil nichts anderes uns die Flexibilität gegeben hat, eine vollautomatische 10-Sprachen-Publishing-Pipeline aufzubauen.

Content-Lake-Architektur

Der Content Lake ist Sanitys verwaltetes Backend. Stellen Sie sich ihn als einen gehosteten Dokumentenspeicher vor, der in Echtzeit zwischen allen verbundenen Clients synchronisiert wird. Wenn ein Redakteur einen Absatz in Sanity Studio ändert, sieht ein anderer Redakteur das sofort -- kein Speichern-Button, keine Merge-Konflikte, keine Datenbankmigrationen.

Intern werden Dokumente als strukturiertes JSON mit typisierten Feldern gespeichert. Jede Mutation wird über ein Transaktionsprotokoll nachverfolgt, sodass Sie standardmäßig eine vollständige Versionshistorie erhalten. Die Echtzeitsynchronisation nutzt eine listenerbasierte Architektur (beschrieben in Sanitys GitHub-Architekturdokumentation), die Änderungen über RxJS-Observables an alle Abonnenten überträgt.

Was unterscheidet das von einer PostgreSQL-Datenbank mit REST-API? Der Content Lake übernimmt Content-Modeling, Zugriffskontrolle, CDN-Caching, Bildtransformationen und Echtzeitzusammenarbeit als einziger verwalteter Dienst. Sie führen keine Migrationen durch. Sie verwalten keine Replikate. Sie definieren einfach Schemas und fragen Content ab.

Sanity Studio: Ihr Anpassbarer Editor

Sanity Studio ist eine Open-Source-React-Anwendung, die als Bearbeitungsoberfläche dient. Es handelt sich nicht um ein gehostetes Admin-Panel -- es ist eine React-App, die in Ihrer Codebase lebt. Sie können jeden Aspekt anpassen: benutzerdefinierte Eingabekomponenten, bedingte Felder, Document Actions, Structure-Builder-Muster und Plugins.

Echtzeitzusammenarbeit ist eingebaut. Mehrere Redakteure können gleichzeitig am selben Dokument arbeiten, mit Anwesenheitsindikatoren und Live-Updates. Wer Google Docs kennt, wird die Erfahrung wiedererkennen -- Sie sehen die Cursor und Änderungen anderer in Echtzeit.

Wir deployen unser Studio mit npx sanity deploy, wodurch es auf Sanitys CDN unter einer benutzerdefinierten Subdomain gehostet wird. Da es nur eine React-App ist, können Sie es auch selbst hosten. In unserem Headless-CMS-Vergleich haben wir Sanity vor allem wegen der Flexibilität von Studio hoch bewertet.

So Richten Sie Ein Sanity-Projekt Ein

Um Sanity CMS einzurichten, installieren Sie die CLI mit npm create sanity@latest, wählen Sie eine Projektvorlage, konfigurieren Sie Ihre Schema-Dateien und starten Sie npx sanity dev, um Studio lokal zu starten. Der gesamte Vorgang dauert weniger als 5 Minuten.

Voraussetzungen und Installation

Sie benötigen Node.js 18+ und npm (oder pnpm). Das ist alles. Führen Sie den Init-Befehl aus:

npm create sanity@latest

# Sie werden nach folgenden Angaben gefragt:
# - Anmeldemethode (Google, GitHub, E-Mail)
# - Projektname
# - Dataset-Name (Standard: "production")
# - Projektvorlage (Blog, E-Commerce, leer)
# - TypeScript? (empfohlen: ja)

Die CLI erstellt ein Projekt mit allem, was Sie benötigen. So sieht die Projektstruktur aus:

Projektstruktur Erklärt

my-sanity-project/
├── schemas/              # Ihre Content-Schemas (hier verbringen Sie die meiste Zeit)
│   ├── index.ts          # Schema-Registry -- importiert und exportiert alle Typen
│   ├── post.ts           # Dokumenttyp-Definitionen
│   └── blockContent.ts   # Rich-Text-/Portable-Text-Konfiguration
├── sanity.config.ts      # Hauptkonfiguration -- Plugins, Studio-Struktur, Dataset
├── sanity.cli.ts         # CLI-Konfiguration -- Projekt-ID, Dataset
├── package.json
└── tsconfig.json

Die Datei sanity.config.ts ist Ihr Einstiegspunkt. Hier ist eine minimale Version:

// sanity.config.ts
import { defineConfig } from 'sanity'
import { structureTool } from 'sanity/structure'
import { visionTool } from '@sanity/vision'
import { schemaTypes } from './schemas'

export default defineConfig({
  name: 'default',
  title: 'My Blog',
  projectId: 'your-project-id',
  dataset: 'production',
  plugins: [structureTool(), visionTool()],
  schema: { types: schemaTypes },
})

Das Plugin visionTool() bietet Ihnen einen GROQ-Playground direkt im Studio -- den werden Sie während der Entwicklung ständig nutzen.

Ihr Studio Deployen

Starten Sie lokal mit npx sanity dev (läuft auf localhost:3333). Wenn Sie es mit Redakteuren teilen möchten, deployen Sie es auf Sanitys CDN:

npx sanity deploy
# Fragt nach einem Hostnamen, z.B. "my-blog"
# Deploys to https://my-blog.sanity.studio

Profi-Tipp: Führen Sie npx sanity@latest schema deploy nach jeder Schema-Änderung aus. Dadurch wird Ihr Schema in die Sanity-API hochgeladen, was Funktionen wie die GraphQL-API und schema-bewusstes Tooling aktiviert (einschließlich des MCP-Servers, den wir später behandeln).

Schema-Design in Sanity CMS

Sanity-Schemas werden als JavaScript- oder TypeScript-Objekte in Ihrer Codebase definiert. Jedes Schema legt einen Dokumenttyp mit Feldern, Validierungsregeln und benutzerdefinierten Eingabekomponenten fest. Änderungen an Schemas werden sofort wirksam -- keine Datenbankmigrationen erforderlich. Das ist der "Schema-as-Code"-Ansatz, und er hat uns von Sanity gegenüber Contentful überzeugt.

Feldtypen und Validierung

Sanity liefert einen umfangreichen Satz von Feldtypen mit. Hier sind die, die wir am häufigsten verwenden:

Jedes Feld unterstützt Validierung über einen validation-Callback. Sie können Pflichtfelder, Minimal-/Maximalwerte, Regex-Muster und benutzerdefinierte Regeln durchsetzen:

defineField({
  name: 'seoDescription',
  title: 'Meta Description',
  type: 'string',
  validation: (Rule) =>
    Rule.required()
      .min(145)
      .max(160)
      .warning('Meta description should be 145-160 characters'),
})

Benutzerdefinierte Blocktypen (Unsere Produktionsbeispiele)

Hier wird Sanity interessant -- und hier zeigen 0 von 6 konkurrierenden Leitfäden irgendeinen Code. In unserem Produktions-Schema definieren wir fünf benutzerdefinierte Blocktypen innerhalb des Body-Arrays: block (Standardtext), table, codeBlock, chartBlock und inlineImage.

Hier ist unsere codeBlock-Definition:

// schemas/objects/codeBlock.ts
import { defineType } from 'sanity'

export const codeBlock = defineType({
  name: 'codeBlock',
  title: 'Code Block',
  type: 'object',
  fields: [
    {
      name: 'language',
      title: 'Language',
      type: 'string',
      options: {
        list: [
          { title: 'JavaScript', value: 'javascript' },
          { title: 'TypeScript', value: 'typescript' },
          { title: 'Python', value: 'python' },
          { title: 'Bash', value: 'bash' },
          { title: 'JSON', value: 'json' },
          { title: 'GROQ', value: 'groq' },
        ],
      },
    },
    {
      name: 'code',
      title: 'Code',
      type: 'text',
    },
  ],
})

Und so referenziert das Body-Feld alle unsere benutzerdefinierten Typen gemeinsam:

// schemas/fields/body.ts
defineField({
  name: 'body',
  title: 'Body',
  type: 'array',
  of: [
    { type: 'block' },         // Standard Portable Text (Absätze, Überschriften, Listen)
    { type: 'table' },         // @sanity/table Plugin
    { type: 'codeBlock' },     // Unser benutzerdefinierter Code-Block
    { type: 'chartBlock' },    // Datenvisualisierung (Balken, Linien, Kreisdiagramm)
    { type: 'inlineImage' },   // Bilder mit Alt-Text und Bildunterschriften
  ],
})

Das gibt unseren Redakteuren ein umfangreiches Content-Toolkit, während jedes Element typisiert und abfragbar bleibt. Ein chartBlock ist keine undurchsichtige HTML-Einbettung -- er ist strukturierte Daten mit Feldern für chartType, title, dataPoints und dataLabels. Das ist wichtig, wenn Sie denselben Content über Web, E-Mail und Mobilgeräte hinweg rendern wollen.

Best Practices für die Schema-Organisation

Halten Sie Schemas modular. Wir teilen unsere nach Typ auf verschiedene Dateien auf: schemas/documents/post.ts, schemas/objects/codeBlock.ts, schemas/objects/chartBlock.ts. Importieren Sie alle in schemas/index.ts:

// schemas/index.ts
import { post } from './documents/post'
import { codeBlock } from './objects/codeBlock'
import { chartBlock } from './objects/chartBlock'
import { inlineImage } from './objects/inlineImage'

export const schemaTypes = [post, codeBlock, chartBlock, inlineImage]

Die wichtigste Erkenntnis, die wir beim Arbeiten mit strukturiertem Content gewonnen haben: Ihr Schema IST Ihr Content-Modell. Wenn Sie es als Context Engineering für Ihr Content-Team betrachten, treffen Sie bessere Designentscheidungen. Jedes Feld, das Sie hinzufügen, sollte einem Zweck dienen -- entweder für Redakteure, für das Rendering oder für Abfragen.

GROQ: Sanitys Abfragesprache

GROQ (Graph-Relational Object Queries) ist Sanitys Open-Source-Abfragesprache zum Filtern, Verknüpfen und Projizieren von JSON-Dokumenten. Die grundlegende Syntax lautet *[filter]{projection} -- alle Dokumente auswählen, die einem Filter entsprechen, und dann die Ausgabe formen. Sie ist prägnanter als GraphQL für Sanity-spezifische Abfragen und lässt sich unserer Erfahrung nach schneller erlernen.

Grundlegende Abfragen: Filter und Projektion

Die einfachste Abfrage ruft alle Dokumente eines Typs ab:

// Alle Beiträge abrufen -- nur Titel und Slug
*[_type == "post"]{
  title,
  "slug": slug.current
}

// Nach Sprache filtern, Autorreferenz auflösen
*[_type == "post" && language == "en"]{
  title,
  "slug": slug.current,
  "authorName": author->name,
  "authorImage": author->image,
  "categoryTitle": category->title,
  publishedAt
}

Der Operator -> folgt Referenzen. author->name bedeutet: "Folge der Autorreferenz und gib das Namensfeld zurück." Keine separaten Abfragen, keine N+1-Probleme, keine JOINs -- alles in einem Ausdruck.

Verknüpfungen, Sortierung und Paginierung

Für unsere Blog-Indexseiten benötigen wir sortierte, paginierte Beiträge mit aufgelösten Referenzen:

// Paginierte Beiträge mit vollständigen Metadaten
*[_type == "post" && language == "en"] | order(publishedAt desc) [0...10] {
  title,
  "slug": slug.current,
  excerpt,
  publishedAt,
  readTime,
  "author": author->{name, image},
  "category": category->{title, "slug": slug.current},
  "coverImage": coverImage{
    "src": asset->url,
    alt
  }
}

[0...10] liefert die ersten 10 Ergebnisse (0-indiziert, exklusives Ende). | order(publishedAt desc) sortiert nach dem Neuesten zuerst. Die Projektion formt die Ausgabe so, dass sie genau das enthält, was Ihr Frontend braucht -- nicht mehr.

Alle diese Abfragen können Sie interaktiv mit dem Vision-Plugin in Sanity Studio testen. Es ist während der Entwicklung unverzichtbar. Weitere Muster finden Sie im GROQ-Spickzettel.

GROQ vs. GraphQL

Sanity unterstützt sowohl GROQ als auch GraphQL. Wann sollten Sie welches verwenden?

GROQ ist Sanitys native Sprache. Es verarbeitet Verknüpfungen, Projektionen und berechnete Felder in einer einzigen Abfragezeichenfolge. Es ist das, wofür der Content Lake optimiert ist.

GraphQL ist verfügbar, nachdem Sie Ihr Schema deployen (npx sanity@latest schema deploy). Verwenden Sie es, wenn Sie standardisiertes Tooling benötigen -- zum Beispiel wenn Ihr Frontend bereits Apollo Client verwendet oder Ihr Team GraphQL kennt, aber nicht GROQ.

Wir verwenden ausschließlich GROQ. Es ist ausdrucksstärker für Sanity-Daten, und das Vision-Plugin macht das Debuggen von Abfragen trivial.

Portable Text: Rich Content Richtig Gemacht

Portable Text ist Sanitys Spezifikation für strukturierten Rich Text. Anstatt Inhalte als HTML-Zeichenfolgen zu speichern, wird ein Array aus typisierten Blöcken abgelegt -- Absätze, Überschriften, Bilder, Code-Snippets, Tabellen -- jeder als JSON-Objekt. Das macht Inhalte in jedem Framework, jeder Plattform und jedem Format renderbar.

Die Datenstruktur

So sehen ein Absatz und ein Code-Block als Portable-Text-JSON aus:

[
  {
    "_type": "block",
    "_key": "a1b2c3",
    "style": "normal",
    "markDefs": [],
    "children": [
      {
        "_type": "span",
        "_key": "d4e5f6",
        "text": "Here's an example of our pipeline config:",
        "marks": []
      }
    ]
  },
  {
    "_type": "codeBlock",
    "_key": "g7h8i9",
    "language": "typescript",
    "code": "export default defineConfig({ ... })"
  }
]

Jeder Block hat einen _type und einen _key. Standard-Textblöcke verwenden "block" mit untergeordneten Spans (die Marks wie Fett, Kursiv und Links unterstützen). Benutzerdefinierte Blöcke -- wie unser codeBlock, chartBlock, table und inlineImage -- verwenden ihren eigenen _type und tragen strukturierte Felder.

Warum ist das wichtig? HTML ist ein Rendering-Format, kein Speicherformat. Wenn Sie <h2>Title</h2><p>Some <strong>text</strong></p> in Ihrer Datenbank speichern, haben Sie sich auf Web-Rendering festgelegt. Sie können das nicht sauber für eine mobile App, einen E-Mail-Newsletter, ein PDF oder das Kontextfenster eines KI-Agenten extrahieren. Portable Text trennt Inhalt von Darstellung. Die Portable-Text-Spezifikation ist Open Source -- es ist keine Sanity-Abhängigkeit.

Benutzerdefinierte Blöcke in der Produktion

Unsere Pipeline konvertiert Markdown mithilfe eines Python-Skripts (scripts/md_to_portable_text.py) in Portable Text. Der Konverter verarbeitet Standardblöcke plus unsere vier benutzerdefinierten Typen:

• table -- verwendet das Schema des @sanity/table-Plugins. Zeilen und Zellen als strukturierte Daten gespeichert.
• codeBlock -- Sprache und Code als separate Felder, was Syntax-Highlighting beim Rendern ermöglicht.
• chartBlock -- Diagrammtyp, Titel, Achsenbeschriftungen, Seriennamen und Datenpunkte als strukturiertes JSON. Das Frontend rendert diese mit Chart.js.
• inlineImage -- Alt-Text, Quelle und optionale Bildunterschrift als separate Felder.

Diese Struktur bedeutet, dass wir alle Code-Beispiele in unserem Blog abfragen können (*[body[]._type == "codeBlock"]), Beiträge mit Diagrammen finden oder alle Bilder ohne Alt-Text extrahieren -- alles über GROQ.

Portable Text Rendern

Verwenden Sie im Frontend @portabletext/react (oder die Svelte-/Vue-Äquivalente). Sie registrieren benutzerdefinierte Komponenten für jeden Blocktyp:

import { PortableText } from '@portabletext/react'

const components = {
  types: {
    codeBlock: ({ value }) => (
      <pre className={`language-${value.language}`}>
        <code>{value.code}</code>
      </pre>
    ),
    chartBlock: ({ value }) => <Chart data={value} />,
    inlineImage: ({ value }) => (
      <figure>
        <img src={value.src} alt={value.alt} />
        {value.caption && <figcaption>{value.caption}</figcaption>}
      </figure>
    ),
  },
}

// In Ihrer Komponente:
<PortableText value={post.body} components={components} />

Das ist die vollständige Rendering-Pipeline. Die PortableText-Komponente verarbeitet Standardblöcke (Absätze, Überschriften, Listen, Marks) automatisch. Sie definieren benutzerdefinierte Komponenten nur für Ihre eigenen benutzerdefinierten Typen.

Mehrsprachige Inhalte Mit Sanity CMS

Sanity unterstützt mehrsprachige Inhalte durch dokumentbasierte Lokalisierung (separate Dokumente pro Sprache, verknüpft durch eine kanonische Referenz) oder feldbasierte Lokalisierung (übersetzte Felder innerhalb eines Dokuments). Dokumentbasierte Lokalisierung funktioniert besser für SEO und groß angelegtes Publishing -- das ist es, was wir in unserer 10-Sprachen-Pipeline verwenden.

Dokumentbasierte vs. Feldbasierte Lokalisierung

Wir haben uns für dokumentbasierte Lokalisierung entschieden, weil jede Übersetzung ihren eigenen Slug, ihre eigene URL und ihre eigenen Metadaten erhält. Die deutsche Version eines Beitrags über Supabase vs. Firebase bekommt den Slug supabase-firebase-karsilastirma -- echtes Türkisch, kein URL-Parameter-Behelf.

Unsere 10-Sprachen-Pipeline-Architektur

So funktioniert unsere automatisierte Pipeline: Wir schreiben einen Beitrag auf Englisch und übersetzen ihn dann in 9 weitere Sprachen (Deutsch, Französisch, Niederländisch, Spanisch, Türkisch, Italienisch, Schwedisch, Norwegisch, Arabisch). Jede Übersetzung durchläuft Markdown-Konvertierung, Portable-Text-Generierung und Sanity-API-Veröffentlichung.

Die Architektur sieht so aus:

1. Schreiben -- Englisches Markdown mit YAML-Frontmatter
2. Übersetzen -- KI-Übersetzung in 9 Sprachen (auf Vollständigkeit und Diakritika geprüft)
3. Konvertieren -- Python-Skript konvertiert jede .md-Datei in Portable-Text-JSON
4. Veröffentlichen -- API-Aufrufe an Sanity: Dokument erstellen, Bilder hochladen, Referenzen patchen

Jedes Dokument hat ein language-Feld und eine canonicalPost-Referenz, die auf das englische Original zeigt. Hier ist die GROQ-Abfrage, um einen Beitrag und alle seine Übersetzungen abzurufen:

// Einen Beitrag und alle seine Übersetzungen abrufen
*[_type == "post" && slug.current == "sanity-cms-guide" && language == "en"][0]{
  title,
  language,
  "translations": *[
    _type == "post" &&
    canonicalPost._ref == ^._id
  ]{
    title,
    language,
    "slug": slug.current
  }
}

Die Schema-Seite ist unkompliziert -- ein language-Feld mit einer Aufzählung der unterstützten Sprachen:

defineField({
  name: 'language',
  title: 'Language',
  type: 'string',
  options: {
    list: [
      { title: 'English', value: 'en' },
      { title: 'German', value: 'de' },
      { title: 'French', value: 'fr' },
      { title: 'Dutch', value: 'nl' },
      { title: 'Spanish', value: 'es' },
      { title: 'Turkish', value: 'tr' },
      { title: 'Italian', value: 'it' },
      { title: 'Swedish', value: 'sv' },
      { title: 'Norwegian', value: 'no' },
      { title: 'Arabic', value: 'ar' },
    ],
  },
  validation: (Rule) => Rule.required(),
})

Eine Falle, die wir auf die harte Tour gelernt haben: Veröffentlichen Sie das englische Dokument zuerst, und patchen Sie dann canonicalPost-Referenzen auf Übersetzungen mit der veröffentlichten Dokument-ID -- nicht dem drafts.-Präfix. Sanity behandelt Draft- und veröffentlichte Dokumente intern als separate Entitäten.

Weitere Details dazu, wie diese Pipeline mit dem Model Context Protocol zusammenhängt, finden Sie im nächsten Abschnitt.

Sanitys KI-Funktionen: MCP, Canvas und Agent Context

Sanity positioniert sich als Content Operating System für das KI-Zeitalter. Zu den wichtigsten KI-Funktionen gehören ein MCP-Server für KI-Agenten zum Lesen und Schreiben von Inhalten, Canvas für KI-gestützte Bearbeitung innerhalb von Studio und Agent Context für produktionsreife KI-Agenten, die strukturierten Content mit Schema-Bewusstsein abfragen können.

MCP-Server-Integration

Der Sanity-MCP-Server ermöglicht es KI-Agenten -- Claude Code, Cursor, Windsurf und anderen -- programmatisch mit Ihrem Sanity-Workspace zu interagieren. Agenten können Schemas lesen, GROQ-Abfragen ausführen, Dokumente erstellen und Inhalte verwalten, ohne benutzerdefinierte API-Wrapper.

Wir verwenden den Sanity-MCP-Server täglich in unserer Content-Pipeline. Unsere KI-Agenten fragen das Schema ab, um die Dokumentstruktur zu verstehen, rufen vorhandene Beiträge ab, um interne Verlinkungsmöglichkeiten zu finden, und veröffentlichen neue Dokumente. Das MCP-Protokoll gibt Agenten Schema-Bewusstsein -- sie wissen, welche Felder existieren, welche Typen diese erwarten und welche Validierungsregeln gelten. Wenn Sie KI-Agenten für Unternehmen einsetzen, ist das ein äußerst leistungsfähiges Muster.

Agent Context für Produktions-KI

Agent Context ist eine separate Funktion für produktionsreife KI-Integrationen. Anders als der MCP-Server (der für Entwicklungstools konzipiert ist) bietet Agent Context schreibgeschützten, bereichsbegrenzten Zugriff für KI-Agenten, die zur Laufzeit Inhalte abfragen müssen -- etwa Chatbots, Empfehlungsmaschinen oder Content-Personalisierungssysteme.

Der Unterschied ist wichtig: MCP ist für Build-Zeit- und redaktionelle Workflows (schema-bewusste Entwicklungstools), während Agent Context für den Laufzeit-Content-Zugriff mit ordnungsgemäßer Authentifizierung und Rate Limiting vorgesehen ist.

Sanitys strukturierter Content bietet hier einen echten Vorteil. Eine WordPress-Site speichert Inhalte als HTML-Blöcke -- ein KI-Agent muss HTML parsen, um den Inhalt zu verstehen. Sanity speichert typisierte JSON-Dokumente mit definierten Schemas. Ein Agent kann *[_type == "product" && category == "electronics"]{name, price, features} abfragen und saubere, strukturierte Daten zurückbekommen. Kein Scraping, kein Parsen, kein Raten.

Wie Wir Sanity Bei Techsy Einsetzen

Das ist kein hypothetischer Abschnitt. Wir betreiben Sanity CMS auf 4 Produktions-Websites und veröffentlichen in 10 Sprachen mit einer automatisierten Pipeline, die wir im letzten Jahr aufgebaut haben. Hier ist die Architektur.

Unsere Content-Pipeline-Architektur

Die Pipeline führt von der Recherche bis zum veröffentlichten Beitrag in allen 10 Sprachen:

1. Recherche -- Keyword-Analyse, Identifikation von Lücken gegenüber Wettbewerbern, SERP-Muster
2. Briefing -- strukturierte Schreibvorlage mit Abschnittsleitfaden, Wortzählungen, internen Links
3. Schreiben -- englisches Markdown mit YAML-Frontmatter produzieren
4. Konvertieren -- Python-Skript transformiert Markdown in Portable-Text-JSON mit unseren 5 benutzerdefinierten Blocktypen
5. Veröffentlichen -- API-Aufrufe an Sanity: Dokument per createOrReplace erstellen, Bilder in Sanity-CDN hochladen, Autor-/Kategoriereferenzen patchen
6. Übersetzen -- KI-Übersetzung in 9 Sprachen, auf Vollständigkeit geprüft
7. Übersetzungen veröffentlichen -- gleicher Konvertierungs-/Veröffentlichungsablauf pro Sprache, mit gepatchter canonicalPost-Referenz auf das englische Original

Das benutzerdefinierte Schema unterstützt die Typen block, table, codeBlock, chartBlock und inlineImage -- alle als Sanity-Schema-Objekte mit Validierungsregeln definiert. Unter den KI-Tools für Startups, die wir getestet haben, war diese Sanity-basierte Pipeline die zuverlässigste für strukturierten Content in großem Maßstab.

Erkenntnisse aus 400+ Veröffentlichten Beiträgen

Ein paar Dinge, von denen wir uns gewünscht hätten, dass sie uns jemand vorab gesagt hätte:

Die Reihenfolge beim Patchen von Referenzen ist entscheidend. Sanity-Referenzen können nicht auf Dokumente zeigen, die noch nicht existieren. Veröffentlichen Sie den englischen Beitrag zuerst, erstellen Sie dann Übersetzungen mit canonicalPost, das auf die veröffentlichte ID des englischen Dokuments zeigt. Wir haben das in der Anfangsphase mehrmals falsch gemacht.

Schema-Deployment erfolgt pro Workspace. Wenn Sie mehrere Sanity-Projekte betreiben (wir betreiben 4), müssen Sie Schemas für jedes separat deployen: npx sanity@latest schema deploy pro Projektkonfiguration.

Der kostenlose Tarif ist echt. Zwei unserer vier Sites haben wir monatelang im kostenlosen Tarif betrieben. 20 Nutzer, 500.000 API-Anfragen/Monat, 100.000 CDN-Anfragen -- das reicht für eine echte Produktions-Website, nicht nur für ein Spielzeugprojekt.

Die Portable-Text-Konvertierung ist der Flaschenhals. Markdown zu Portable Text ist nicht trivial. Verschachtelte Listen, Tabellen innerhalb von Blockquotes, Code-Blöcke mit Sonderzeichen -- überall Sonderfälle. Wir haben monatelang an unserem Konverter-Skript gearbeitet.

Benötigen Sie Hilfe beim Einrichten von Sanity für Ihr Projekt? Wir haben mehrsprachige Content-Pipelines für 4 Produktions-Sites aufgebaut. Kostenlose Beratung anfordern

Sanity-CMS-Preise im Überblick

Sanity bietet drei Tarife: Free (20 Nutzer, 500.000 API-Anfragen/Monat), Growth ($15/Nutzer/Monat mit erweiterten Rollen und geplanten Entwürfen) und Enterprise (individuelle Preise mit SLA und Compliance-Funktionen). Der kostenlose Tarif ist der großzügigste im Headless-CMS-Markt.

Im kostenlosen Tarif betreiben wir zwei unserer Sites, ohne an Grenzen zu stoßen. Der Growth-Tarif bei $15/Nutzer/Monat hat rollenbasierten Zugriff hinzugefügt (wichtig, sobald wir nicht-technische Redakteure hatten) und geplante Veröffentlichung. Viewer sind im Growth-Tarif kostenlos, was ein angenehmer Bonus ist -- Sie werden nicht bestraft dafür, dass Sie Stakeholdern Lesezugriff gewähren.

Wie schneidet das im Vergleich zu Wettbewerbern ab?

Sanitys 20-Nutzer-Free-Tarif ist außergewöhnlich. Contentful beschränkt Sie im kostenlosen Tarif auf 1 Nutzer und springt dann auf $300/Monat für den Team-Tarif. Wenn Sie ein Startup oder kleines Team sind, ermöglicht Sanitys kostenloser Tarif Ihnen, echte Produktions-Workloads ohne Kosten zu betreiben.

Sanity bietet außerdem ein Startup-Programm an, das berechtigten Startups ein Jahr kostenlosen Growth-Zugang gewährt. Es lohnt sich, sich zu bewerben, wenn Sie die Kriterien erfüllen.

Häufig Gestellte Fragen

Was Ist Sanity CMS und Wie Funktioniert Es?

Sanity CMS ist eine Headless-Content-Plattform, die strukturierte JSON-Dokumente in einem verwalteten Backend namens Content Lake speichert. Sie bearbeiten Inhalte über Sanity Studio (eine anpassbare React-App), fragen sie mit GROQ oder GraphQL ab und rendern sie in jedem beliebigen Frontend-Framework. Inhalte synchronisieren sich in Echtzeit zwischen allen verbundenen Clients.

Ist Sanity CMS Kostenlos?

Ja. Sanitys kostenloser Tarif umfasst 20 Nutzer, 500.000 API-Anfragen pro Monat und 100.000 CDN-Anfragen -- der großzügigste kostenlose Tarif unter den Headless-CMS-Plattformen. Der Growth-Tarif kostet $15 pro Nutzer pro Monat und fügt rollenbasierten Zugriff, geplante Veröffentlichung und höhere Limits hinzu. Enterprise-Preise sind individuell.

Was Ist Der Unterschied Zwischen Sanity und Contentful?

Sanity verwendet Schema-as-Code (Schemas leben in Ihrer Codebase), GROQ für Abfragen und ein vollständig anpassbares Open-Source-Studio. Contentful verwendet GUI-basiertes Content-Modeling, GraphQL und einen gehosteten Editor mit weniger Anpassungsmöglichkeiten. Sanitys kostenloser Tarif umfasst 20 Nutzer gegenüber Contentfuls 1. Contentful hat einen größeren Plugin-Marktplatz.

Ist Sanity CMS Für Einsteiger Geeignet?

Sanity Studio ist für Content-Redakteure intuitiv -- die Bearbeitungserfahrung erfordert keine technischen Kenntnisse. Das Einrichten von Schemas erfordert jedoch JavaScript- oder TypeScript-Kenntnisse. Sanity bietet exzellente Dokumentation, Projektvorlagen und einen Community-Slack mit aktivem Support. Beginnen Sie mit npm create sanity@latest und einer Blog-Vorlage.

Kann Ich Sanity Selbst Hosten?

Sanity Studio ist vollständig selbst hostbar, da es eine Open-Source-React-Anwendung ist. Sie können es auf Vercel, Netlify oder jedem anderen Static-Hosting-Anbieter deployen. Das Content-Lake-Backend ist ein verwalteter Dienst -- es gibt keine Selbst-Hosting-Option für die Datenschicht. Das ist ein Kompromiss: Sie erhalten null Infrastrukturverwaltung, aber keine On-Premises-Datenkontrolle.

Welche Datenbank Verwendet Sanity?

Sanitys Content Lake ist keine traditionelle SQL- oder NoSQL-Datenbank. Es handelt sich um einen verwalteten Dokumentenspeicher, der Inhalte als strukturiertes JSON mit einer GROQ-Abfrageschicht darüber speichert. Sie interagieren nicht direkt mit der zugrunde liegenden Datenbank -- Sie interagieren über Sanitys APIs. Dokumente haben standardmäßig vollständige Versionshistorie und Echtzeitsynchronisation.

Ist Sanity CMS Open Source?

Sanity Studio ist Open Source unter der MIT-Lizenz -- Sie können es forken, anpassen und selbst hosten. Das Content-Lake-Backend ist proprietäres SaaS. Die GROQ-Abfragesprachspezifikation ist ebenfalls Open Source, auf GitHub veröffentlicht. Die Portable-Text-Spezifikation ist auch Open Source und wird unter portabletext.org gepflegt.

Was Ist Portable Text in Sanity?

Portable Text ist Sanitys Spezifikation für strukturierten Rich Text. Anstatt Inhalte als HTML-Zeichenfolgen zu speichern, repräsentiert es Absätze, Überschriften, Bilder und benutzerdefinierte Blöcke als typisierte JSON-Objekte in einem Array. Das macht Inhalte über Frameworks und Plattformen hinweg portierbar. Sie können benutzerdefinierte Blocktypen wie Code-Snippets, Diagramme und Tabellen mit ihren eigenen strukturierten Feldern definieren.

Was Ist GROQ und Wie Unterscheidet Es Sich von GraphQL?

GROQ (Graph-Relational Object Queries) ist Sanitys native Abfragesprache. Ihre Syntax -- *[filter]{projection} -- ist für Sanity-Daten prägnanter als GraphQL, mit integrierter Unterstützung für Verknüpfungen über den Operator -> und berechnete Felder. GraphQL ist ebenfalls verfügbar für Teams, die standardisiertes Tooling bevorzugen oder bereits Apollo Client verwenden.

Wie Verwaltet Sanity Mehrsprachige Inhalte?

Sanity unterstützt dokumentbasierte Lokalisierung (separate Dokumente pro Sprache, verknüpft durch kanonische Referenzen) und feldbasierte Lokalisierung (übersetzte Felder innerhalb eines Dokuments). Dokumentbasierte Lokalisierung ist besser für SEO, weil jede Übersetzung ihre eigene URL und eigene Metadaten erhält. Wir verwenden dokumentbasierte Lokalisierung, um in 10 Sprachen mit automatisierten Übersetzungs- und Veröffentlichungspipelines zu publizieren.