Sanity SEO

TL;DR — Sanity is a place to store content, not a place that publishes web pages. It hands your content out as data (JSON), not as finished HTML — so a separate website built with something like Next.js or Astro has to turn that data into pages. That means none of the usual SEO stuff (titles, sitemaps, canonical tags) happens automatically the way it does on WordPress. The biggest rule: build your pages on a server or at build time, not entirely in the visitor’s browser, or search engines and AI tools may never see your content.

What Sanity actually is

People sometimes assume Sanity is “a CMS like WordPress,” and that’s where the confusion starts. Sanity is a headless CMS. It does two things: it stores your content (in something Sanity calls the Content Lake) and it gives content editors a place to write (Sanity Studio). What it does not do is produce a single line of HTML. Your content comes out as structured data — JSON — through an API.

That means a separate website — built with a framework like Next.js, Astro, or Remix — has to fetch that JSON and build the actual pages people and search engines see. Sanity stores the content; your frontend publishes it. Once you internalize that one sentence, almost everything about Sanity SEO makes sense.

The one decision that matters most: rendering

Because your frontend builds the pages, how it builds them decides your SEO. There are two safe ways and one risky way:

• At build time (SSG) — pages are pre-built into plain HTML files. Fast and search-friendly.
• On a server, per request (SSR) — the server builds the full page and sends it. Also search-friendly, always fresh.
• In the visitor’s browser (CSR) — the server sends a near-empty shell and JavaScript fills it in afterward. This is the risky one.

Google can eventually run JavaScript and read a CSR page, but it’s slower and less reliable — and today the crawlers behind ChatGPT, Claude, and Perplexity typically don’t render JavaScript at all, so they just see the empty shell. That’s not a fixed rule, though: Google’s Gemini answers reuse Googlebot’s own rendering infrastructure, so behavior already varies by provider and isn’t guaranteed to stay the same. So if you want to show up in Google and get cited by AI tools, build your HTML on the server or at build time.

The “where did my SEO settings go?” problem

On WordPress, a plugin like Yoast quietly handled your titles, meta descriptions, sitemap, and canonical tags. Sanity has no such thing. So someone has to deliberately:

• Add SEO fields (title, description, social image) to the content in Sanity.
• Wire those fields into each page’s HTML in the frontend.
• Build a sitemap, a robots.txt, and structured data — all in code.

None of this is hard. It just won’t happen on its own. A lot of “my Sanity site has no SEO” stories are really “nobody built the stuff a plugin used to do.”

Two things that quietly go wrong

• Draft pages getting into Google. Sanity can serve unpublished drafts through its API. If someone shares a preview link and a crawler finds it, that draft can get indexed. You have to actively block that.
• Body text that’s invisible. Sanity stores rich text in a special format called Portable Text — it’s data, not HTML. Your frontend has to convert it. On a CSR page, that conversion happens in the browser, so AI crawlers never see your article text.

Want the full version — the four rendering modes, the reusable SEO field setup, sitemaps, draft-mode protection, JSON-LD, and which plugins to use? Switch to the Advanced tab.

TL;DR — Sanity is content-neutral: it stores structured JSON in the Content Lake and emits zero HTML, so the frontend’s rendering mode decides everything. SSG and SSR ship complete HTML and are safe; CSR is the risky one because LLM crawlers don’t execute JavaScript, and Google deprecated dynamic rendering as a workaround. Portable Text is a JSON AST that the frontend must serialize. Build a reusable seo object in the content model with overrides (not requirements) via coalesce(), generate sitemaps and JSON-LD programmatically from existing fields, and keep drafts out of the index with an X-Robots-Tag: noindex header on every preview response. Use sanity-plugin-seo — never the deprecated Yoast pane — but remember “SEO success in Sanity comes from intentional structure, not plugins.”

Sanity is content storage, not a publisher

A useful first principle: Sanity touches your content, never your rendering. The Content Lake stores everything as structured JSON, queried with GROQ (Sanity’s query language) or REST. Sanity Studio — the editing UI — is a React single-page app that usually lives on its own .sanity.studio subdomain and isn’t something you index. Nothing in this stack produces HTML.

So the entire SEO surface lives in your frontend framework. As Webstacks put it, “Sanity handles content storage and editing, while your frontend framework handles SEO output.” That’s not a limitation — it’s the whole headless model. Sanity’s own team frames it well: “When using Sanity as a CMS, you’re doing headless SEO. Although this approach requires thoughtful technical implementation, it can liberate your content to help you reach more users across all channels.” The work is real, but it’s the same work as any headless build (see SEO for a Headless CMS).

Rendering mode is the foundation

Because the frontend builds the HTML, the rendering decision is the single most consequential SEO choice on a Sanity site. Four modes:

SSG — Static Site Generation. Content is fetched from Sanity at build time and baked into static HTML served from a CDN. Best-case SEO: fully-rendered HTML on first request, fast TTFB. Ideal for blog posts, marketing pages, and product/landing pages. The tradeoff is freshness — changed content needs a rebuild (ISR solves this).

SSR — Server-Side Rendering. Content is fetched per request and the full HTML is rendered on the server. Excellent SEO, always fresh. Use it for frequently updated content. Tradeoff is infrastructure cost and slightly higher TTFB than static files.

ISR — Incremental Static Regeneration (Vercel/Next.js). Static pages regenerate in the background, ideally triggered by a Sanity webhook on publish so the page rebuilds the moment an editor hits publish. This is the best of SSG’s speed and SSR’s freshness for content that changes on the order of hours or days.

CSR — Client-Side Rendering. An HTML shell ships, then JavaScript fetches from Sanity and builds the DOM in the browser. This is the worst SEO option: Googlebot has to queue the page for a later render wave, timing is unpredictable, and AI crawlers and many other bots see only the shell. CSR is acceptable only behind authentication for content you don’t want indexed anyway.

And don’t reach for the old shortcut: Google has deprecated dynamic rendering (serving prerendered HTML to bots, CSR to users). Officially, “dynamic rendering was a workaround and not a long-term solution,” and Google now recommends “server-side rendering, static rendering, or hydration.” For a Sanity site, that means SSG or SSR — not a bot-detection hack. (Full rendering treatment in JavaScript SEO.)

Portable Text — your body copy is a JSON AST

This is the most Sanity-specific thing on the page. Sanity stores rich text as Portable Text: a JSON abstract syntax tree, not HTML. Body copy in the Content Lake looks like an array of typed blocks, not <p> tags. Your frontend has to serialize it into HTML before any crawler can read it:

• @portabletext/react — for React/Next.js.
• @portabletext/to-html — framework-agnostic (Astro, Remix, anything).
• The old @sanity/block-content-to-react is deprecated — don’t use it.

If you render server-side or at build time, serialization happens before the page is sent and crawlers get full HTML. If you render client-side, the serialization runs in the browser. Because LLM-crawler rendering contracts vary by provider, CSR Portable Text creates a coverage risk that raw HTML avoids. There’s also a handy GROQ helper: pt::text(body) extracts all the plain text from a Portable Text field as a string, which is perfect for feeding JSON-LD descriptions without a separate editor field.

Content modeling for SEO — the reusable SEO object

The cleanest pattern, and the one Sanity’s own course teaches, is a single reusable seo object added to every document type — not SEO fields copy-pasted per type. The key design principle from Sanity Learn: “For the benefit of content authors, fields relevant to SEO should not always be required. Instead, they should be used to override some existing content, when provided.”

In practice that means SEO fields are overrides with fallbacks, implemented with GROQ’s coalesce():

"title": coalesce(seo.title, title, ""),
"description": coalesce(seo.description, excerpt, "")

A minimum viable seo object: metaTitle (≤65 chars), metaDescription (≤155 chars), canonicalUrl, openGraphImage (1200×630), and a noIndex boolean. Add Sanity validation rules to enforce those character limits before publish — so editors catch problems the platform would otherwise let through. Use a slug type with a custom generation function, and use references for internal links so URL changes propagate automatically. Add a hideFromSearch boolean and filter it out of both the sitemap GROQ query and the page’s robots metadata.

Metadata, sitemaps, and canonicals — all built in the frontend

Metadata. In Next.js App Router, use the exported generateMetadata() function (not inline <head> tags) so metadata doesn’t duplicate across nested layouts. Build one server-side helper that takes a GROQ result and returns the framework’s metadata object — implement it once, use it everywhere. Open Graph images can be generated dynamically with Next.js Edge OG generation, pulling content straight from Sanity.

Sitemaps. There’s no auto-sitemap. You build it from a GROQ query → URL array → XML (sitemap.ts in Next.js, @astrojs/sitemap in Astro). Always filter drafts and hidden pages:

*[_type in ["page", "post"] && defined(slug.current) && hideFromSearch != true]

Use _updatedAt (not _createdAt or a manual date) for lastModified, keep individual sitemap files under 50,000 URLs with an index for larger sites, and trigger regeneration via a Sanity webhook on publish/unpublish so it never goes stale.

Canonicals. Set canonical URLs from the content model, default to a self-referencing canonical, and build absolute URLs from a single SITE_URL so the canonical never drifts. (Mechanics in Canonicalization.)

Structured data — generate it, don’t author it

The right pattern is to generate JSON-LD programmatically from existing content fields at render time — never build a separate JSON-LD editor surface in Studio, which just creates drift between content and markup. Roboto Studio’s rule is blunt: “Derive JSON-LD from existing fields, at render time, in code.” Sanity agrees — “JSON-LD is a powerful way to provide structured data to search engines — fortunately structured data is what Sanity does best.”

Use pt::text(body) to pull plain text for schema descriptions, the TypeScript package schema-dts for type safety, and render it with <script type="application/ld+json">. Note that “the JSON-LD markup can be rendered anywhere in the page — it doesn’t need to be stored inside the <head>.” Priority types for content sites: Article/BlogPosting, BreadcrumbList, FAQPage, Organization, WebSite.

Keeping drafts out of Google — the real-incident pitfall

Sanity’s perspective system controls draft visibility: published returns only production content; drafts returns draft documents for preview. Always use the published perspective in production API calls. But that alone isn’t enough, because draft URLs leak. As one developer recounted, the danger is “a client panicking because an unpublished landing page showed up in Google Search Console. If a content editor shares that URL in Slack, and someone clicks it from a browser that’s then crawled (it happens), the draft content can end up indexed.”

The reliable defense is a multi-layer one:

1. Use the published perspective in production; never expose an unprotected preview endpoint.
2. Add an X-Robots-Tag: noindex HTTP header to every draft-mode/preview response — even if a draft URL leaks and gets crawled, Googlebot respects the header and won’t index it. (Don’t rely on robots.txt for this; a header is more reliable than a disallow for preview pages.)
3. Validate the preview secret server-side; never reflect it in the redirect URL, and scope the preview-enable endpoint to your Studio’s origin.

Robots, redirects, image SEO, and hreflang

robots.txt is a static frontend file (app/robots.ts in Next.js). Block Studio paths only if they’re on the same domain (Disallow: /studio/); don’t try to block preview pages with it.

Redirects are a genuine workflow win: store them as Sanity documents (from, to, statusCode) so the content team can manage redirects without a developer deploy, then implement them in Next.js middleware.ts or a CDN/Worker layer (never in Sanity itself). Add validation rules to prevent loops and invalid paths.

Image SEO: use Sanity’s image CDN with ?auto=format for automatic WebP/AVIF, manage alt text at the asset level with document-level overrides, use vanity filenames instead of hashed URLs, and set hotspot/crop so automatic crops keep the subject — which matters most for OG images.

Hreflang: model locale variants as separate Sanity documents referencing the canonical version, generate hreflang from a GROQ query returning all locale slugs, and give every locale page a self-referencing canonical — never canonical a non-English page to the English one.

Plugins — helpful, not a substitute

• sanity-plugin-seo — the primary recommendation (22k+ downloads). Live SEO score, meta/OG preview, social cards, robots control, hreflang, readability. The AI tier adds keyword suggestions and meta generation.
• sanity-plugin-seofields — an alternative: 39 schema.org types, an SEO Health Dashboard, and Next.js helper functions (buildSeoMeta()).
• sanity-plugin-seo-pane — DEPRECATED. This is the old Yoast integration, removed due to an outdated dependency. It still shows up in old tutorials. Don’t use it.

The honest framing, from Yanatiev: “SEO success in Sanity comes from intentional structure, not plugins.” Plugins surface fields and give editorial feedback — they don’t replace proper content modeling.

AI search and AEO

The 2026 wrinkle: LLM training and retrieval crawlers (Anthropic, OpenAI, Common Crawl) typically don’t execute JavaScript today, so CSR Portable Text is largely invisible to them regardless of whether Googlebot can render it — but this is provider-specific and not a guaranteed contract. Google’s Gemini pipeline is the notable exception, since it reuses Googlebot’s own rendering infrastructure, and other providers’ behavior can change. Treat “no rendering” as the safe assumption to build for, not a permanent law. Beyond rendering, two Sanity-friendly tactics: serve clean markdown via content negotiation when Accept: text/markdown is present (Sanity’s @portabletext/markdown package converts Portable Text with no extra authoring), and monitor Bing specifically since Bing’s index feeds ChatGPT’s browse responses. On llms.txt, Sanity’s own Knut Melvær is skeptical — “Probably don’t do llms.txt” for large sites, because the all-or-nothing scope and file-size limits make it impractical; per-page content negotiation is more granular. Roboto Studio’s summary is the right mindset: “AEO and SEO live on the same plumbing, so we treat them as one job.” (More in AI Search.)

The myths worth killing

• “Sanity does SEO automatically like WordPress + Yoast.” No. Zero HTML, zero automatic anything.
• “Any rendering mode is fine if the content’s in Sanity.” No. CSR breaks indexing and AI visibility; dynamic rendering is deprecated.
• “Drafts can’t be indexed.” They can, if a preview URL leaks. Use a noindex header.
• “Portable Text is HTML.” It’s a JSON AST that the frontend must serialize.
• “You need a JSON-LD editor in Studio.” No — generate it from existing fields.

AI summary

A condensed take on the Advanced version:

• Sanity is content-neutral. It stores structured JSON in the Content Lake (queried via GROQ/REST) and emits zero HTML. The frontend (Next.js, Astro, Remix) produces all SEO output. “Sanity does SEO like WordPress” is a myth.
• Rendering mode is the foundation. SSG and SSR ship complete HTML and are safe; ISR (webhook-triggered on publish) adds freshness; CSR is risky. Google deprecated dynamic rendering — use SSR/static/hydration.
• LLM-crawler rendering varies by provider — raw HTML maximizes Portable Text coverage.
• Portable Text is a JSON AST, not HTML. Serialize it with @portabletext/react or @portabletext/to-html; @sanity/block-content-to-react is deprecated. Use pt::text(body) to extract plain text for JSON-LD.
• Content modeling: one reusable seo object across all types, fields as overrides not requirements via coalesce(), validation rules enforcing limits, and a hideFromSearch flag filtered from both sitemap and robots metadata.
• Sitemaps, metadata, canonicals, robots.txt are all built in the frontend. Filter drafts from the sitemap GROQ query, use _updatedAt for lastModified, and regenerate via Sanity webhooks.
• Generate JSON-LD programmatically from existing fields at render time — never a separate Studio editor. Use schema-dts; it can render anywhere, not just <head>.
• Keep drafts out of the index: use the published perspective in production and add an X-Robots-Tag: noindex header to every preview response. A leaked draft URL has caused real indexing incidents.
• Plugins: sanity-plugin-seo (primary) or sanity-plugin-seofields. The Yoast sanity-plugin-seo-pane is deprecated. “SEO success in Sanity comes from intentional structure, not plugins.”
• AEO: monitor Bing (feeds ChatGPT browse); serve markdown via content negotiation; Sanity advises against llms.txt for large sites.

Official documentation

Primary-source documentation from the search engines and Sanity.

Google

• Understand JavaScript SEO Basics — the crawl → render → index pipeline, JS canonicals, and why blocked files don’t get rendered. The core reference for any Sanity frontend.
• Dynamic Rendering (deprecated workaround) — why Google deprecated it and what to use instead (SSR, static rendering, hydration).
• Rendering for Content-Driven Web Apps — SSR vs. SSG vs. CSR tradeoffs for exactly the kind of content sites Sanity powers.
• Robots meta tag, data-nosnippet, and X-Robots-Tag — the X-Robots-Tag: noindex HTTP header used to keep draft/preview responses out of the index.
• Intro to robots.txt — what robots.txt does and doesn’t do (it controls crawling, not indexing of leaked drafts).

Bing / Microsoft

• The new evergreen Bingbot (Microsoft Edge) — Bingbot rendering JavaScript via Edge; relevant since Bing’s index feeds ChatGPT browse.
• IndexNow / indexnow.org — the push protocol to wire to your Sanity publish webhook.

Sanity

• SEO with Sanity — Sanity’s own master SEO guide.
• SEO Optimization course — the full Next.js SEO course (schema types, dynamic sitemaps, JSON-LD).
• Presenting and previewing content (perspectives) — published vs. drafts perspectives, the basis of draft-mode safety.

Quotes from the source

On-the-record statements relevant to Sanity SEO. Each link is a deep link that jumps to the quoted passage on the source page.

Sanity — the headless SEO model

• “When using Sanity as a CMS, you’re doing headless SEO. Although this approach requires thoughtful technical implementation, it can liberate your content to help you reach more users across all channels.” — Sanity, SEO with Sanity. Jump to quote
• “SEO doesn’t have to be complicated. It’s a matter of taking content you’ve already responsibly structured with Sanity and rendering it in the format and places that search engines expect.” — Sanity Learn, SEO Optimization course. Jump to quote
• “For the benefit of content authors, fields relevant to SEO should not always be required. Instead, they should be used to override some existing content, when provided.” — Sanity Learn, SEO schema types and metadata. Jump to quote
• “JSON-LD is a powerful way to provide structured data to search engines—fortunately structured data is what Sanity does best.” — Sanity Learn, Generating JSON-LD dynamically. Jump to quote

Google — dynamic rendering is deprecated

• “Dynamic rendering was a workaround and not a long-term solution for problems with JavaScript-generated content in search engines.” — Google Search Central docs. Jump to quote
• Recommended instead: “server-side rendering, static rendering, or hydration.” Jump to quote

Industry — frontend owns SEO; structure beats plugins

• “Sanity handles content storage and editing, while your frontend framework handles SEO output.” — Webstacks, Sanity SEO. Read the guide
• “AEO and SEO live on the same plumbing, so we treat them as one job.” — Roboto Studio / Jono Alford, AEO & SEO best practices for Sanity. Read the post
• “SEO success in Sanity comes from intentional structure, not plugins.” — Yanatiev, SEO best practices for Sanity CMS. Read the post
• “Probably don’t do llms.txt.” — Knut Melvær, Sanity, How to serve content to agents. Read the field guide

Sanity SEO checklist

A pass built around how Sanity actually works — build the things the platform leaves to your frontend, and lock down the things that quietly break.

Rendering & content (the foundation)

• Pages render their content in HTML on first request (SSG or SSR), not only after client-side JavaScript runs.
• No SEO-critical page depends on CSR (raw HTML maximizes LLM-crawler coverage).
• ISR (if used) regenerates on a Sanity publish webhook, not just a timer.
• Portable Text is serialized server-side with @portabletext/react or @portabletext/to-html (not the deprecated block-content-to-react).

Content model

• One reusable seo object on every document type — not per-type duplication.
• SEO fields are overrides via coalesce(), with validation rules enforcing title/description length before publish.
• A hideFromSearch (or noIndex) boolean exists and is filtered from both the sitemap GROQ query and the page’s robots metadata.

Frontend outputs

• Metadata wired from GROQ into generateMetadata() (or framework equivalent) — one reusable helper.
• Sitemap generated from GROQ, drafts/hidden filtered, _updatedAt used for lastModified, regenerated on a webhook.
• Canonicals are absolute URLs from a single SITE_URL, per-page and self-referencing by default.
• robots.txt exists in the frontend; .js/.css are not blocked.
• JSON-LD generated programmatically from existing fields (Article, Breadcrumb, FAQ, Organization), verified with the Rich Results Test.

Draft / preview safety

• Production API calls use the published perspective.
• Every draft/preview response sends an X-Robots-Tag: noindex header.
• Preview secret validated server-side and scoped to the Studio origin.

AEO & monitoring

• Bing Webmaster Tools set up (Bing feeds ChatGPT browse); IndexNow on publish.
• (Optional) markdown served via content negotiation for AI crawlers.

The mental models

1. Sanity stores, the frontend publishes. The Content Lake holds JSON; your framework produces every byte of HTML and every SEO signal. Before debugging any Sanity SEO problem, ask: what is the frontend actually sending crawlers? Almost everything resolves to that.

2. Rendering mode is the product. Pick by how the content changes:

• Mostly static (blog, docs, marketing) → SSG (rebuild or ISR on publish).
• Frequently changing, must be fresh → SSR.
• Hours/days cadence, want static speed → ISR (webhook-triggered).
• Behind a login, not meant to be indexed → CSR is acceptable.
• Public content you want ranked or cited by AI → never CSR.

3. Overrides, not requirements. SEO fields default to the primary content and only override when an editor fills them in — implemented with coalesce(). This keeps the editing experience clean and guarantees every page has something for its title and description.

4. Generate, don’t author, the markup. Sitemaps, JSON-LD, hreflang, and canonicals are all derived from existing fields in code at render time. A separate editor surface for any of them just creates drift. “Derive from existing fields, at render time, in code.”

5. Defense in depth for drafts. published perspective in production is layer one; an X-Robots-Tag: noindex header on every preview response is layer two. Never rely on a single control to keep unpublished content out of the index.

Sanity SEO — cheat sheet

Rendering modes at a glance

What’s built in the frontend (not in Sanity)

GROQ snippets worth memorizing

• Override with fallback: coalesce(seo.title, title, "")
• Plain text from Portable Text: pt::text(body)
• Sitemap filter: *[... && defined(slug.current) && hideFromSearch != true]

Fast rules

• LLM-crawler rendering varies by provider → avoid CSR-only public content.
• Dynamic rendering is deprecated — use SSR/static/hydration.
• Drafts: published perspective + X-Robots-Tag: noindex header.
• Plugin: sanity-plugin-seo ✅ / sanity-plugin-seo-pane (Yoast) ❌ deprecated.
• “SEO success in Sanity comes from intentional structure, not plugins.”

Draft or preview content appeared in Search Console

Use this runbook when an unpublished Sanity document has a discoverable preview URL or shows up in Google Search Console.

1. Confirm which response leaked. Fetch the reported URL without Studio credentials and inspect both the status and X-Robots-Tag header. If it returns published content, continue to step 2. If it exposes a draft, disable the preview entry point while you continue.
2. Check the production perspective. Trace the page’s GROQ request and confirm production uses the published perspective. If it uses drafts, fix that query first; if it already uses published, continue to the response layer.
3. Add the indexing backstop. Send X-Robots-Tag: noindex on every preview and draft-mode response. If the header is missing on any preview route, fix the shared preview middleware rather than patching one page.
4. Validate preview access. Confirm the preview secret is checked server-side, is not reflected into the destination URL, and accepts requests only from the intended Studio origin. If a public preview URL still works, rotate the secret and close that route.
5. Remove the indexed copy. After the response is safe, use Search Console’s removal workflow when the exposure is urgent, then request a fresh crawl. If the URL should never exist publicly, keep the noindex response available long enough for crawlers to see it rather than blocking it in robots.txt.
6. Verify the fix. Fetch the URL while logged out and run URL Inspection. The draft must be absent from the body and the preview response must carry noindex.

Sanity SEO mistakes to avoid

Expecting Sanity to emit SEO HTML

Why it’s wrong: Sanity stores JSON; it does not publish titles, canonicals, sitemaps, or page HTML. Do this instead: make the frontend responsible for each output and verify the generated response rather than the Studio fields.

Choosing CSR for public content

Why it’s wrong: The initial response is an empty shell, and many AI crawlers do not execute JavaScript at all. Do this instead: ship public content with SSG, SSR, or webhook-triggered ISR.

Assuming unpublished means unindexable

Why it’s wrong: A shared preview URL can leak and be crawled. Do this instead: use the published perspective in production and send an X-Robots-Tag: noindex header on every preview response.

Treating Portable Text as HTML

Why it’s wrong: Portable Text is a JSON AST, so un-serialized content never becomes crawlable body copy. Do this instead: serialize it on the server with @portabletext/react or @portabletext/to-html.

Maintaining JSON-LD in a separate editor

Why it’s wrong: A second copy of product, article, or organization facts drifts from the visible page. Do this instead: derive JSON-LD from the same Sanity fields at render time and validate the rendered output.

Check whether a Sanity page ships real HTML

Run this after changing rendering mode, Portable Text serialization, or page data loading. It checks the initial response, before client-side JavaScript can fill gaps.

macOS / Linux — compare normal and Googlebot responses

URL="https://example.com/article-slug"
curl -sL "$URL" -o /tmp/sanity-page.html
curl -sL -A "Googlebot" "$URL" -o /tmp/sanity-googlebot.html

grep -Ei '<title>|rel="canonical"|<h1|application/ld\+json' /tmp/sanity-page.html
diff -u /tmp/sanity-page.html /tmp/sanity-googlebot.html

The first command should find the page’s real title, canonical, H1, and JSON-LD in raw HTML. A meaningful content difference in the diff deserves investigation; crawlers and users should not receive different canonical content.

Windows PowerShell — inspect the initial response

$url = "https://example.com/article-slug"
$html = (Invoke-WebRequest -Uri $url).Content
$html | Select-String -Pattern '<title>|rel="canonical"|<h1|application/ld\+json'

DevTools Console — confirm Portable Text became semantic elements

[...document.querySelectorAll('main article p, main article h2, main article li')]
  .map((node) => node.textContent.trim())
  .filter(Boolean)
  .slice(0, 20)

Run the snippet in the browser Console. It is a rendered-DOM check, so pair it with the curl test: content appearing only here but not in the initial response is still client-rendered.

Tools for Sanity SEO

• URL Inspection (Google Search Console) — see how a single URL was crawled and rendered. The rendered HTML tells you whether your Portable Text actually made it in — essential for catching CSR gaps on a Sanity frontend.
• Rich Results Test — confirm your programmatic JSON-LD is present in the rendered output after any rendering or template change.
• Screaming Frog SEO Spider — crawl with JavaScript rendering on/off to compare raw HTML vs. rendered HTML; this is how you prove whether your content is server- rendered or client-rendered.
• Ahrefs Site Audit — surfaces missing metadata, broken canonicals, redirect chains, and indexability issues across the whole frontend.
• Bing Webmaster Tools — submit your sitemap and monitor Bing indexing (it feeds ChatGPT browse), plus where IndexNow submissions show up.
• sanity-plugin-seo — in-Studio live SEO score, meta/OG preview, and robots control so editors get feedback at authoring time.

Test yourself: Sanity SEO

Five quick questions on how SEO works on a Sanity-backed site. Pick an answer for each, then check.

Resources worth your time

My related writing

• JavaScript SEO Issues & Best Practices — my primary reference on rendering modes, which decide everything on a Sanity frontend.
• The Beginner’s Guide to Technical SEO — where rendering and crawling fit in the bigger picture.

My speaking

• JavaScript SEO — Ungagged 2019 (SlideShare) — my walkthrough of how headless/decoupled CMSes split the frontend from the backend, plus Googlebot’s stateless rendering. (Standing disclaimer: the dynamic-rendering recommendation in that deck is now outdated — Google deprecated it.)

On this site

• SEO for a Headless CMS — the sibling guide; Sanity is a specific application of the same headless rules.
• JavaScript SEO — the rendering deep dive.
• Canonicalization — the consolidation mechanics behind your frontend’s canonical tags.
• AI Search — how AI crawlers and answer engines behave.

From around the industry

• SEO with Sanity (Sanity) — Sanity’s own master SEO guide; start here for platform-current behavior.
• SEO Optimization course (Sanity Learn) — the hands-on Next.js course covering the SEO object, dynamic sitemaps, and JSON-LD.
• Sanity SEO (Webstacks, Devon Wood) — agency guide making the “frontend handles SEO output” point clearly.
• AEO & SEO best practices for Sanity (Roboto Studio, Jono Alford) — the AEO angle and the “derive JSON-LD from existing fields” rule.
• SEO best practices for Sanity CMS (Yanatiev) — the “structure, not plugins” framing.
• How to serve content to agents: a field guide (Knut Melvær, Sanity) — content negotiation and the case against llms.txt for large sites.
• Headless CMS SEO (Ahrefs, Despina Gavoyannis) — the broader headless playbook (content/code/design optimized independently) that Sanity sits inside.
• turbo-start-sanity (Roboto Studio, GitHub) — an open-source Sanity SEO starter with real query.ts, seo-fields.ts, and seo.ts implementations.

Sanity SEO

Sanity SEO is the set of technical and content practices that make a website built on Sanity.io rank and get cited. Sanity stores content as structured JSON and produces zero HTML, so every SEO output — meta tags, sitemaps, canonicals, structured data — is built in the frontend that consumes Sanity's API.

Related: Headless CMS SEO, JavaScript SEO

Sanity SEO

Sanity SEO refers to the technical and content work required to make websites built with Sanity.io rank in search engines and get cited by AI answer engines. Unlike a traditional CMS like WordPress, Sanity is a headless CMS: it stores content as structured JSON in the “Content Lake” and serves it over GROQ queries or REST, but it produces no HTML of its own. That single fact reshapes everything.

Because Sanity emits no markup, the frontend framework that consumes its API decides your SEO — Next.js, Astro, Remix, Nuxt, or anything else. The rendering mode that frontend uses (static generation or server-side rendering vs. client-side rendering) determines whether crawlers and LLMs ever see your content. Every SEO output you’d expect a CMS plugin to handle — title tags, meta descriptions, canonical tags, XML sitemaps, robots directives, and JSON-LD structured data — has to be implemented deliberately in the frontend.

Three things trip up teams new to Sanity:

• There are no automatic SEO features. Sanity ≠ WordPress + Yoast. Nothing is generated for you.
• Portable Text is not HTML. Sanity stores rich text as a JSON abstract syntax tree that the frontend must serialize to HTML before crawlers can read body copy.
• Drafts can leak into the index. Sanity’s CDN API can return draft documents; without a noindex defense, a shared preview URL can get indexed.

Done right — SSG or SSR, a reusable SEO object in the content model, programmatic JSON-LD, and a locked-down preview perspective — a Sanity-backed site can be highly optimized. The risk is treating it like a turnkey CMS and skipping the implementation work.

Related: Headless CMS SEO, JavaScript SEO

Changelog