Claude Code के साथ Sanity CMS

Sanity CMS क्या है

Sanity CMS एक headless CMS है जिसमें लेख, product pages, FAQ, author profile और campaign टेक्स्ट को संरचित (structured) रूप में संभाला जाता है। Headless CMS का मतलब है कि management screen और display screen अलग होते हैं, और एक ही content को website, app, newsletter तथा internal tools जैसे कई output स्थानों पर भेजा जा सकता है। Sanity में content का type TypeScript जैसी schema में परिभाषित होता है, और GROQ नामक query भाषा से सिर्फ़ ज़रूरी data निकाला जाता है।

CMS को केवल “लेख रखने की जगह” मानने पर monetization मुश्किल हो जाता है। content ops के पाठक के लिए असली सवाल यह है कि search traffic, lead capture, product path, update कार्य और audit log — सब एक ही operational flow में आ पाते हैं या नहीं। Sanity की schema बारीकी से design की जा सकती है, इसलिए Claude Code के साथ “लेख का type”, “CTA का type”, “review item” और “publish condition” को code की तरह संभालना इसकी ताक़त है।

2026 में production में लाते समय पहले CMS की screen नहीं, बल्कि revenue से जुड़ी content इकाई तय करें। उदाहरण के लिए, blog लेख में search keyword, अपेक्षित पाठक, internal link, CTA और verification note रखें। product LP में price, audience, comparison table, buy button और FAQ रखें। training या consultation page में वे लेख रखें जो पूछताछ से पहले पढ़े जाने चाहिए।

Sanity का type परिभाषा आधिकारिक Schema Types में देखी जा सकती है। GROQ का syntax आधिकारिक GROQ syntax देखते हुए, Claude Code से “इस list screen के लिए सिर्फ़ ज़रूरी fields लौटाने वाली query लिखो” कहने से implementation तेज़ होता है। पर Claude Code पर सब कुछ न छोड़ें — publish condition, slug की uniqueness, draft exclusion, image alt और CTA की मौजूदगी की समीक्षा इंसान करे, यही production का आधार है।

2026 का production architecture

Sanity CMS को monetization site पर इस्तेमाल करते समय editing screen, Content Lake, frontend, analytics और sales path को अलग-अलग सोचें। नीचे की table छोटे media, course-selling site और B2B content marketing के लिए उपयोगी न्यूनतम संरचना है।

Layer	भूमिका	production में देखने वाला संकेत	Claude Code को सौंपने का कार्य
Sanity Studio	editor जहाँ लेख, product, CTA डालते हैं	draft ढेर, ख़ाली अनिवार्य fields, review वापसी	schemaTypes, preview setup, validation
Content Lake	publish content को API से रखने की जगह	query speed, बेकार fields, dataset अलगाव	GROQ query, draft exclusion, locale fetch
Next.js/Astro	SEO page, LP, list, detail दिखाने की परत	Core Web Vitals, index count, CVR	fetch function, types, list UI, internal link
Analytics/CRM	search से पूछताछ तक देखने की परत	CTA click, lead, purchase, consultation booking	event names, measurement spec, checklist
Monetization	Gumroad, Stripe, consultation form, mail	sales, free PDF signup, deal rate	CTA copy, comparison table, FAQ, test plan

इस संरचना में CMS बदलने पर भी पूरा frontend टूटता नहीं। सिर्फ़ लेख-body नहीं, CTA और related links भी structured रखें तो बाद में “API वाला लेख पढ़ने वाले को consultation दिखाओ” जैसे paths बनाना आसान होता है।

internal links भी शुरू से design में रखें। Sanity को blog CMS के रूप में देखने का पूरा चित्र Claude Code blog CMS, Contentful से तुलना और migration दृष्टि Claude Code Contentful CMS, और CMS से API निकालने का विचार Claude Code API development के साथ देखें।

असल में काम आने वाले use cases

पहला use case multilingual SEO media है। जापानी में बना लेख अंग्रेज़ी, चीनी, कोरियाई में फैलाते समय सिर्फ़ body अनुवाद से नतीजा नहीं मिलता। Sanity में locale, canonicalSlug, targetKeyword, searchIntent, localizedCta अलग रखें तो हर भाषा में search intent और CTA समायोजित हो सकते हैं।

दूसरा use case course या template selling LP संचालन है। हर लेख के अंत में वही buy link चिपकाना पाठक की मनोदशा से मेल नहीं खाता। Sanity में offerType, priceNote, proofPoint, audience, nextAction वाला CTA document बनाएँ तो “शुरुआती को free PDF”, “implementer को template”, “team lead को consultation” का बँटवारा हो सकता है।

तीसरा use case CMS migration और content audit है। Notion, Markdown, Contentful या WordPress से Sanity में लाते समय सादा migration का मूल्य कम होता है। उस समय पुराने, duplicate, revenue-path-रहित और पुराने official link वाले लेख वर्गीकृत करें। schema में contentScore, lastReviewedAt, reviewOwner, monetizationStatus रखें तो publish के बाद सुधार-कार्य दिखने लगते हैं।

चौथा use case sales material और public लेख का एकीकरण है। B2B में sales team की व्याख्या और public site के लेख अक्सर अलग हो जाते हैं। Sanity में “feature विवरण”, “case study”, “FAQ”, “objection handling” structured रखें तो public page, proposal और mail template एक ही मसौदे का संदर्भ ले सकते हैं।

Project setup

npm create sanity@latest -- --project-id=xxxxx --dataset=production

# Next.js project में Sanity client जोड़ें
npm install next-sanity @sanity/image-url

Schema परिभाषा

नीचे blog लेख और author की schema है। rich text, image और reference field शामिल हैं।

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

export const postType = defineType({
  name: 'post',
  title: 'Post',
  type: 'document',
  fields: [
    defineField({
      name: 'title',
      title: 'Title',
      type: 'string',
      validation: (rule) => rule.required().max(100),
    }),
    defineField({
      name: 'slug',
      title: 'Slug',
      type: 'slug',
      options: { source: 'title', maxLength: 96 },
      validation: (rule) => rule.required(),
    }),
    defineField({
      name: 'author',
      title: 'Author',
      type: 'reference',
      to: [{ type: 'author' }],
    }),
    defineField({
      name: 'mainImage',
      title: 'Main Image',
      type: 'image',
      options: { hotspot: true },
      fields: [
        defineField({
          name: 'alt',
          title: 'Alt Text',
          type: 'string',
        }),
      ],
    }),
    defineField({
      name: 'publishedAt',
      title: 'Published At',
      type: 'datetime',
    }),
    defineField({
      name: 'categories',
      title: 'Categories',
      type: 'array',
      of: [{ type: 'reference', to: [{ type: 'category' }] }],
    }),
    defineField({
      name: 'body',
      title: 'Body',
      type: 'blockContent',
    }),
  ],
  preview: {
    select: {
      title: 'title',
      author: 'author.name',
      media: 'mainImage',
    },
    prepare({ title, author, media }) {
      return { title, subtitle: author, media };
    },
  },
});

GROQ query का design

list page और detail page के लिए GROQ अलग रखें। list में body न लौटाएँ, सिर्फ़ card के लिए ज़रूरी title, slug, image, author और category लौटाएँ। query जितनी छोटी होगी, frontend और cache रणनीति उतनी पठनीय रहेगी।

// src/lib/sanity/queries.ts
import { groq } from 'next-sanity';

// लेख सूची
export const postsQuery = groq`
  *[_type == "post" && defined(slug.current)] | order(publishedAt desc) {
    _id,
    title,
    "slug": slug.current,
    publishedAt,
    excerpt,
    mainImage {
      asset-> {
        _id,
        url,
        metadata { dimensions, lqip }
      },
      alt
    },
    author-> {
      name,
      "slug": slug.current,
      image { asset-> { url } }
    },
    categories[]-> {
      title,
      "slug": slug.current
    }
  }[0...$limit]
`;

// एकल लेख
export const postBySlugQuery = groq`
  *[_type == "post" && slug.current == $slug][0] {
    _id,
    title,
    "slug": slug.current,
    publishedAt,
    body[] {
      ...,
      _type == "image" => {
        ...,
        asset-> { url, metadata { dimensions } }
      }
    },
    mainImage {
      asset-> { url, metadata { dimensions, lqip } },
      alt
    },
    author-> {
      name,
      bio,
      image { asset-> { url } }
    },
    categories[]-> {
      title,
      "slug": slug.current
    },
    "relatedPosts": *[
      _type == "post" &&
      slug.current != $slug &&
      count(categories[@._ref in ^.^.categories[]._ref]) > 0
    ] | order(publishedAt desc) [0...3] {
      title,
      "slug": slug.current,
      publishedAt,
      mainImage { asset-> { url } }
    }
  }
`;

Next.js में data fetch

// src/lib/sanity/client.ts
import { createClient } from 'next-sanity';

export const client = createClient({
  projectId: process.env.NEXT_PUBLIC_SANITY_PROJECT_ID!,
  dataset: process.env.NEXT_PUBLIC_SANITY_DATASET!,
  apiVersion: '2024-01-01',
  useCdn: process.env.NODE_ENV === 'production',
});

// app/blog/page.tsx
import { client } from '@/lib/sanity/client';
import { postsQuery } from '@/lib/sanity/queries';

export default async function BlogPage() {
  const posts = await client.fetch(postsQuery, { limit: 20 });

  return (
    <div className="max-w-4xl mx-auto p-6">
      <h1 className="text-3xl font-bold mb-8">Blog</h1>
      {posts.map((post: any) => (
        <article key={post._id} className="mb-8 border-b pb-6">
          <h2 className="text-xl font-bold">{post.title}</h2>
          <p className="text-gray-500 text-sm">{post.author?.name}</p>
        </article>
      ))}
    </div>
  );
}

असफलता के उदाहरण और pitfalls

सबसे आम ग़लती schema को सिर्फ़ “आज के लेख के लिए ज़रूरी fields” से बनाना है। पहले तेज़ लगता है, पर बाद में multilingual, CTA replacement, review date, author profile और product link जोड़ते समय हर बार migration करना पड़ता है। शुरू से perfect होना ज़रूरी नहीं, पर revenue से जुड़े fields body से अलग रखें।

दूसरी ग़लती GROQ से list में body और image metadata बहुत ज़्यादा लौटाना है। list page पर पूरा body fetch करने से build समय, transfer और cache बिगड़ते हैं। list, detail, related और sitemap के लिए query अलग करें।

तीसरी ग़लती draft या बिना-review लेख को publish पक्ष में मिला देना है। सिर्फ़ publishedAt होना कभी-कभी पर्याप्त नहीं। publish review स्थिति को reviewStatus के रूप में रखें, या publish और draft dataset अलग रखें। Claude Code से “draft मिलावट पकड़ने वाला test” बनवाना सुरक्षित है।

चौथी ग़लती CMS तो लगाया पर revenue path सिर्फ़ एक fixed banner रह जाए। हर लेख की पाठक-मंशा से बेमेल CTA click नहीं होता। CTA को content type की तरह संभालें।

Rollout checklist

• production से पहले title, description, slug, heroImage.alt, publishedAt अनिवार्य करें।
• लेख, product LP, FAQ, CTA अलग document में रखें, body में सीधे बहुत न लिखें।
• list-GROQ और detail-GROQ अलग रखें, list में body न लें।
• multilingual में locale और canonicalSlug रखें, अनुवाद-चूक और canonical duplication जाँचें।
• official link, internal link, CTA, verification note की मौजूदगी publish-पूर्व जाँच में डालें।
• GA4, Search Console, sales page, contact form के event नाम एकरूप करें।

Summary

Sanity की GROQ query और customizable studio लचीला content management देती है। Claude Code का लाभ उठाकर schema design और GROQ लेखन भी efficiently आगे बढ़ता है। Blog CMS construction guide और Next.js full-stack development भी reference के लिए देखें।

Sanity के विवरण के लिए Sanity official documentation देखें।

इस लेख में बताई बातों को असल में आज़माने पर

verification note के रूप में: इस लेख की schema, GROQ और @sanity/client fetch function Sanity v3 की सामान्य संरचना में न टूटने वाले रूप तक सीमित रखे गए हैं। असली project में अक्सर यहाँ reviewStatus, canonicalSlug, author, relatedOffer जोड़े जाते हैं। शुरू से जटिल workflow बनाने के बजाय लेख, CTA और verification note अलग रखकर हर 30 दिन में revenue संकेतों से सुधारना — यही संचालन टिकाऊ बनाता है।