Claude Code und Sanity CMS: Produktionsguide für Content Ops

Was Sanity CMS ist

Sanity CMS ist ein Headless CMS für strukturierten Content: Artikel, Landingpages, Produktangebote, Autoren, FAQ, Case Studies, Kampagnentexte und wiederverwendbare CTA. Headless CMS bedeutet, dass Redaktion und Darstellung getrennt sind. Das Team pflegt Inhalte in Sanity Studio, die Inhalte liegen im Content Lake, und die Website oder App ruft über eine API genau die Felder ab, die gebraucht werden.

Für CMS- und Content-Ops-Teams ist das Entscheidende nicht der schönere Editor. Entscheidend ist, dass Inhalte als operative Assets geführt werden: Ziel-Keyword, Suchintention, interne Links, CTA, Review Owner, Verification Note, Aktualisierungsdatum. Wenn diese Daten strukturiert sind, kann Claude Code Schemas, GROQ-Abfragen, Fetch-Helper, Komponenten und Prüfskripte erstellen.

Die offiziellen Feldtypen stehen in Sanity Schema Types. Die Abfragesprache ist in GROQ syntax dokumentiert. Claude Code kann daraus schnell lauffähige Entwürfe bauen. Produktionsqualität entsteht aber erst durch klare Regeln: eindeutige Slugs, keine Draft-Leaks, verpflichtender Alt-Text, passende CTA und Analytics-Events, die bis zum Kauf oder zur Beratung messbar sind.

2026 sollte Sanity nicht nur als CMS eingeführt werden, sondern als Teil der Monetarisierungsarchitektur. Ein Tutorial führt vielleicht zu einem kostenlosen PDF. Ein Vergleich zwischen Sanity und Contentful führt eher zu einer Migrationsberatung. Ein Artikel über Governance kann zu Team-Training führen. Sanity strukturiert diese Wege, Claude Code setzt sie in Code, Queries und Review-Checks um.

Produktionsarchitektur 2026

Eine belastbare Architektur trennt Redaktion, API-Quelle, Frontend, Analyse und Monetarisierung. So wird verhindert, dass CTA, FAQ und Review-Regeln als unprüfbarer Text im Artikelkörper verschwinden.

Ebene	Rolle in Produktion	Wichtige Metrik	Aufgabe für Claude Code
Sanity Studio	Posts, Angebote, FAQ, CTA und Review Notes bearbeiten	fehlende Felder, Review-Stau, alte Drafts	schemaTypes, Preview, Validierung
Content Lake	Strukturierte Inhalte per API liefern	Query-Größe, Cache, Dataset-Trennung	GROQ, Draft-Filter, Locale-Filter
Frontend	SEO-Seiten, Listen, Detailseiten und Landingpages rendern	Indexierung, Performance, CTA-Klicks	Fetch-Helper, Typen, Komponenten
Analytics/CRM	Lesen, Kaufen und Anfragen verbinden	Events, Formularstarts, Käufe, Leads	Eventnamen, QA-Checklist
Monetarisierung	Free PDF, Gumroad, Stripe, Training oder Beratung	Umsatz, Lead-Qualität, Refunds	CTA-Varianten, Tabellen, FAQ, Routing

Die wichtigste Regel: Alles, was Conversion oder Governance beeinflusst, sollte strukturiert sein. Ein CTA im Fließtext lässt sich schlecht testen. Eine FAQ in zehn Artikeln lässt sich schlecht aktualisieren. Ein Review-Status in einer externen Tabelle wird vergessen. Sanity gibt dem Content ein Modell; Claude Code macht daraus wiederholbare Implementierung.

Als Ergänzung: Claude Code blog CMS erklärt das Blog-Grundmuster, Claude Code Contentful CMS hilft beim CMS-Vergleich, und Claude Code API development zeigt, wie Content in Apps oder APIs fließt. Für Team-Einführung und Revenue-Workflow passt training / consultation.

Reale use cases

Erster use case: eine mehrsprachige SEO-Bibliothek. Ein Team startet mit einem Hauptartikel und lokalisiert ihn in weitere Sprachen. Wenn jede Version nur eine kopierte Markdown-Datei ist, entstehen schnell Lücken: fehlende interne Links, zu lange Descriptions, nicht lokalisierte CTA, veraltete Quellen. In Sanity können locale, canonicalSlug, targetKeyword, searchIntent und localizedCta eigene Felder sein. Claude Code kann diese Felder auditieren und eine Liste unvollständiger Artikel erzeugen.

Zweiter use case: Content-to-Product-Funnel. Nicht jeder Leser sollte dieselbe CTA sehen. Anfänger brauchen vielleicht eine kostenlose Checkliste. Implementierer möchten ein Template Pack. Team Leads brauchen eine Einführung oder Beratung. Ein strukturierter CTA mit intent, label und href macht diese Zuordnung testbar, ohne jeden Artikel händisch umzuschreiben.

Dritter use case: CMS-Migration mit Content-Audit. Beim Wechsel von WordPress, Contentful, Notion oder Markdown zu Sanity sollte nicht nur alter Content umgezogen werden. Die Migration ist der beste Zeitpunkt, Traffic, Suchintention, Frische, Beweise und Monetarisierungsstatus zu prüfen. Felder wie contentScore, lastReviewedAt, reviewOwner und monetizationStatus machen daraus eine echte Roadmap.

Vierter use case: eine Quelle für Marketing und Sales. In B2B-Teams weichen Website, Sales Deck, Support-Antworten und FAQ oft voneinander ab. Sanity kann Erklärungen, Einwände, Proof Points und Antworten als wiederverwendbare Dokumente speichern. Die Website rendert sie öffentlich; ein internes Tool nutzt dieselben Daten. Claude Code baut Fetch-Schicht, Komponenten und API.

Kopierbares Schema

Dieses Sanity-v3-Schema kann als schemaTypes/post.ts verwendet werden. Es enthält Felder für SEO, Redaktion und Monetarisierung: Locale, Description, Hero Image mit Alt-Text, Body, CTA, Verification Note und Veröffentlichungsdatum.

// schemaTypes/post.ts
import {defineField, defineType} from 'sanity'

export const post = defineType({
  name: 'post',
  title: 'Post',
  type: 'document',
  fields: [
    defineField({
      name: 'title',
      title: 'Title',
      type: 'string',
      validation: (rule) => rule.required().max(90),
    }),
    defineField({
      name: 'slug',
      title: 'Slug',
      type: 'slug',
      options: {source: 'title', maxLength: 96},
      validation: (rule) => rule.required(),
    }),
    defineField({
      name: 'locale',
      title: 'Locale',
      type: 'string',
      options: {
        list: [
          {title: 'English', value: 'en'},
          {title: 'German', value: 'de'},
          {title: 'Japanese', value: 'ja'},
        ],
      },
      validation: (rule) => rule.required(),
    }),
    defineField({
      name: 'description',
      title: 'SEO description',
      type: 'text',
      rows: 3,
      validation: (rule) => rule.required().max(120),
    }),
    defineField({
      name: 'heroImage',
      title: 'Hero image',
      type: 'image',
      options: {hotspot: true},
      fields: [
        defineField({
          name: 'alt',
          title: 'Alt text',
          type: 'string',
          validation: (rule) => rule.required(),
        }),
      ],
      validation: (rule) => rule.required(),
    }),
    defineField({
      name: 'body',
      title: 'Body',
      type: 'array',
      of: [{type: 'block'}, {type: 'image'}],
      validation: (rule) => rule.required(),
    }),
    defineField({
      name: 'cta',
      title: 'Monetization CTA',
      type: 'object',
      fields: [
        defineField({name: 'label', title: 'Label', type: 'string'}),
        defineField({name: 'href', title: 'URL', type: 'url'}),
        defineField({name: 'intent', title: 'Intent', type: 'string'}),
      ],
    }),
    defineField({
      name: 'verificationNote',
      title: 'Verification note',
      type: 'text',
      rows: 4,
    }),
    defineField({
      name: 'publishedAt',
      title: 'Published at',
      type: 'datetime',
      validation: (rule) => rule.required(),
    }),
  ],
  preview: {
    select: {title: 'title', subtitle: 'locale', media: 'heroImage'},
  },
})

// schemaTypes/index.ts
import {post} from './post'

export const schemaTypes = [post]

GROQ und Client-Fetch

Listen und Detailseiten brauchen unterschiedliche Abfragen. Die Liste holt keine kompletten Bodies. Die Detailseite holt Body, Verification Note und CTA.

// src/lib/sanity/queries.ts
export const postsByLocaleQuery = `
  *[
    _type == "post" &&
    locale == $locale &&
    defined(slug.current) &&
    defined(publishedAt)
  ] | order(publishedAt desc) [0...$limit] {
    _id,
    title,
    description,
    "slug": slug.current,
    publishedAt,
    "heroImageUrl": heroImage.asset->url,
    "heroImageAlt": heroImage.alt,
    cta
  }
`

export const postBySlugQuery = `
  *[
    _type == "post" &&
    locale == $locale &&
    slug.current == $slug
  ][0] {
    _id,
    title,
    description,
    "slug": slug.current,
    publishedAt,
    body,
    verificationNote,
    cta,
    "heroImageUrl": heroImage.asset->url,
    "heroImageAlt": heroImage.alt
  }
`

// src/lib/sanity/client.ts
import {createClient} from '@sanity/client'
import {postBySlugQuery, postsByLocaleQuery} from './queries'

export const sanityClient = createClient({
  projectId: process.env.NEXT_PUBLIC_SANITY_PROJECT_ID || '',
  dataset: process.env.NEXT_PUBLIC_SANITY_DATASET || 'production',
  apiVersion: '2026-06-02',
  useCdn: process.env.NODE_ENV === 'production',
})

export async function getPosts(locale: string, limit = 12) {
  return sanityClient.fetch(postsByLocaleQuery, {locale, limit})
}

export async function getPostBySlug(locale: string, slug: string) {
  return sanityClient.fetch(postBySlugQuery, {locale, slug})
}

npm install sanity @sanity/client @sanity/image-url
set NEXT_PUBLIC_SANITY_PROJECT_ID=your_project_id
set NEXT_PUBLIC_SANITY_DATASET=production

Pitfalls und Fehler

Erster pitfall: Das Schema wird nur für die aktuelle Vorlage gebaut. Später kommen Sprachen, Autoren, CTA und Reviews hinzu, und jede Ergänzung wird zur Migration.

Zweiter pitfall: Over-fetching. Eine Übersichtsseite sollte nicht den kompletten Body vieler Artikel laden. Trenne Card-, Detail-, Sitemap- und Related-Queries.

Dritter pitfall: Drafts gelangen in die Produktion. publishedAt reicht nicht immer. Prüfe reviewStatus oder trenne Preview und Production-Dataset.

Vierter pitfall: Monetarisierung wird als Universal-Banner verstanden. Ein Vergleichsartikel, ein Tutorial und ein Governance-Artikel brauchen unterschiedliche nächste Schritte.

Rollout-Checklist

• title, description, slug, heroImage.alt und publishedAt verpflichtend machen.
• Posts, FAQ, Autoren, Offers und CTA trennen, wenn sie wiederverwendet werden.
• GROQ für Liste, Detail, Sitemap und Related Content separat schreiben.
• Für Mehrsprachigkeit locale und canonical Informationen speichern.
• Offizielle Links, interne Links, CTA und Verification Note vor Veröffentlichung prüfen.
• Analytics-Events mit Kauf- und Beratungsfunnel abgleichen.
• Nach 30 Tagen Traffic, Klicks, Käufe und Anfragen auswerten.

Monetarisierungs-CTA

Sanity CMS lohnt sich, wenn Inhalte, Beweise und Angebote gemeinsam steuerbar werden. ClaudeCodeLab kann ein bestehendes Markdown-, Contentful-, WordPress- oder Sanity-Setup in ein sauberes Schema, GROQ, Review-Checks und Revenue-Routing überführen. Wenn SEO-Artikel zu Templates, Training oder Implementierungsberatung führen sollen, starte über training / consultation mit echten Inhalten und einem konkreten Umsatzziel.