DEV Community: Nayan Kyada

Sanity Editors Publishing Changes That Don't Show on the Live Site

Nayan Kyada — Sat, 07 Nov 2026 11:13:29 +0000

Your editors click publish in Sanity, refresh the page, and see the old content. They publish again, then message you. A Next.js and Sanity site that serves stale content after publishing is almost always a revalidation wiring problem, not a Sanity problem, and it is fixable without a rebuild.

What the symptoms usually look like

The pattern tells you a lot about the cause:

Content updates only after a redeploy. That points to fully static pages with no revalidation at all.
Content updates after an hour or a day. That is a time-based revalidate value doing the work, and the webhook is missing or failing.
Some pages update and others do not. That is usually a tag or path mismatch: the webhook revalidates what it knows about, and the stale pages are cached under something else.
It works in Studio preview but not on the public URL. Draft mode bypasses the cache, so preview looks fine while production is stale.
It updates for you but not for editors in another country. That suggests a CDN or browser caching layer in front of the app.

What it costs to ignore it

Stale content is not just annoying. Editors stop trusting the Studio, start asking developers to redeploy for every typo, and your marketing team loses the main reason you went headless. Price changes, legal copy, and campaign pages that show old information carry real risk. Some teams react by setting revalidation to zero, which trades the problem for slow pages and a larger API bill. I covered that second failure in Sanity API bill spiking? Why requests explode on Next.js sites.

Cause 1: the webhook never fires or fails silently

Open the Sanity project settings, go to the API section, and look at your webhook and its delivery attempts. Check three things: the filter, the projection, and the response status. A common mistake is a filter limited to one document type, so new types added later never trigger a refresh. Another is the endpoint URL pointing at a preview deployment or an old domain.

If deliveries show 401 or 403, your secret verification is rejecting valid requests. If they show 404, the route handler path is wrong. The full verified setup is in Sanity webhooks and Next.js ISR revalidation with HMAC verification.

Cause 2: the revalidation tag does not match the fetch tag

This is the most common bug I see on inherited codebases. The webhook calls revalidateTag with one string, and the fetch was cached with a different one.

// lib/sanity/fetch.ts - broken: tag names drift apart
import { client } from './client'

export function getPost(slug: string) {
  return client.fetch(
    `*[_type == "post" && slug.current == $slug][0]`,
    { slug },
    { next: { tags: [`post-${slug}`] } }
  )
}

// app/api/revalidate/route.ts - revalidates a tag nobody uses
import { revalidateTag } from 'next/cache'

export async function POST(req: Request) {
  const body = await req.json()
  revalidateTag(body._type) // "post", but fetches use "post-my-slug"
  return Response.json({ ok: true })
}

The fix is one naming convention used in both places. Tag by document type, and optionally by type plus slug, and have the webhook send both.

// lib/sanity/tags.ts
export const tagsFor = (type: string, slug?: string) =>
  slug ? [type, `${type}:${slug}`] : [type]

Then use tagsFor in every fetch and in the route handler. Be aware that the exact signature of revalidateTag has changed across recent Next.js majors, so check the Next.js 16 docs for the version you run rather than copying an older snippet. If webhooks fire in bursts, batching helps; see Sanity webhook revalidation: batching tags in Next.js.

Cause 3: references and parent pages are not invalidated

An editor changes an author name or a navigation item. The author document revalidates, but the 200 blog posts that embed that author stay cached. Either tag every query with the referenced types it reads, or send the webhook a list of affected documents using a GROQ projection that follows references. Without this, the site looks randomly stale.

Cause 4: a cache layer in front of Next.js

If Next.js revalidates correctly but visitors still see old HTML, look upstream. A CDN, a proxy, or an overly aggressive Cache-Control header can pin the page. Compare the response headers from the origin and from the public domain. If they differ, that is your answer.

Cause 5: the client uses the CDN API for reads that need freshness

The Sanity API CDN can serve slightly older data. For server-side fetches triggered by a webhook, the content may not have propagated yet when you revalidate. Using the live API without the CDN for those server fetches avoids the race. Confirm the option name in the current @sanity/client documentation before changing it.

How to verify the fix

Publish a small change in Studio, such as a headline edit.
Check the webhook delivery log and confirm a 200 response.
Reload the public page in a private window and confirm the change.
Repeat with a referenced document, such as an author, and confirm dependent pages update.
Check response headers on the public domain for unexpected caching.

Add a lightweight log line in the route handler that records the document type, slug, and tags revalidated. When an editor reports a problem next month, you can answer in a minute instead of guessing.

What to ask a developer

How do you name cache tags, and where is that convention documented?
What happens when a referenced document changes?
Can I see the webhook delivery log and the route handler code?
How do you test revalidation before launch?
Will you fix it without disabling caching?

A good answer names a tag convention and a test. A bad answer is "we set revalidate to 10 seconds."

Work I do

Diagnosing and fixing stale-content problems on Sanity and Next.js sites is work I do regularly, usually as part of a Performance and Sanity audit from $800. If your editors have stopped trusting the publish button, that is a good place to start.

Next.js build taking too long on a Sanity site: causes and the fix

Nayan Kyada — Fri, 06 Nov 2026 12:19:22 +0000

Your Next.js build is taking too long when a deploy that once finished in a couple of minutes now runs for fifteen, twenty, or longer, and a content change or a one-line fix sits in a queue. On Sanity sites this is almost always self-inflicted: the build is doing the work of rendering and fetching every page in the dataset, every time. Here is how I diagnose it, what it costs you to ignore, and the order I fix it in.

Symptoms that point to a build problem

Check whether these sound familiar:

Deploy time grows every time the editors publish more content.
The build log shows the same page count climbing, with long gaps between prerendered routes.
Builds occasionally fail with timeouts or fetch errors from the Sanity API, then pass on retry.
Editors ask whether the site is broken because they cannot see their change for ages.
Your hosting plan reports a lot of build minutes, and a preview deploy per pull request multiplies it.

If build time scales with content count, the cause is structural, not a bad server. Throwing a bigger build machine at it helps a little and hides the real issue.

What ignoring it costs

The direct cost is build minutes, which is a line item on your hosting bill (see my breakdown of what drives a Vercel bill on a Next.js site). The bigger cost is behavioural. When deploys are slow, developers batch changes, hotfixes wait, and marketing stops trusting that publishing will show up. A site where nobody wants to deploy is a site that rots.

Cause 1: prerendering every document on every build

The most common pattern I find is a dynamic route that returns every slug from generateStaticParams. With 40 pages that is fine. With 4,000 it is the entire build.

// app/blog/[slug]/page.tsx (broken: prerenders everything)
import {client} from '@/sanity/lib/client'

export async function generateStaticParams() {
  const slugs = await client.fetch<string[]>(
    `*[_type == 'post' && defined(slug.current)].slug.current`
  )
  return slugs.map((slug) => ({slug}))
}

The fix is to prerender only what matters and let the rest build on demand. Pages not returned from generateStaticParams are rendered on first request and then cached, because dynamicParams defaults to true.

// app/blog/[slug]/page.tsx (fixed: top pages only, rest on demand)
import {client} from '@/sanity/lib/client'

export const dynamicParams = true

export async function generateStaticParams() {
  const slugs = await client.fetch<string[]>(
    `*[_type == 'post' && defined(slug.current)]
      | order(publishedAt desc)[0...50].slug.current`
  )
  return slugs.map((slug) => ({slug}))
}

Fifty of the newest posts is a starting point, not a rule. Use your analytics: prerender the pages that actually receive traffic. I use the same approach in the 100+ post blog build.

Cause 2: every page fetches far more than it renders

The second pattern is a page query that pulls whole documents, dereferences everything, and returns fields the template never touches. Multiply that payload by thousands of pages and the build spends its life waiting on the network.

Open your page queries and look for a bare projection that returns everything, or deep reference expansion several levels down. Replace it with an explicit projection of the fields the page uses. The techniques in advanced GROQ queries and the conditional projections post cover this in detail.

Cause 3: the same data fetched many times

Layouts, headers, footers, and navigation often each call Sanity separately, and so does every page that needs site settings. Some of these are deduplicated within a render, some are not, depending on how you fetch. A site with a navigation query, a settings query, and a footer query on each of 2,000 pages is 6,000 requests before the page content itself.

Give shared data one fetch function with explicit caching, and tag it so you can invalidate it precisely:

// sanity/lib/fetch.ts
import {client} from './client'

export async function sanityFetch<T>(
  query: string,
  params: Record<string, unknown> = {},
  tags: string[] = []
): Promise<T> {
  return client.fetch<T>(query, params, {
    next: {revalidate: 3600, tags},
  })
}

Then call it with a tag such as settings for global data. Pair it with webhook-driven invalidation, as described in batching tags on Sanity webhooks, so a one-hour fallback is only a safety net.

Cause 4: the build is not using the CDN

For published content during a build, the Sanity API CDN is usually the right choice. If your client is configured with the CDN turned off everywhere, builds hit the live API directly and are more exposed to rate limits, which explains the random failures that pass on retry. Keep the CDN on for published reads and turn it off only for draft or preview fetches. Confirm the exact behaviour in your next-sanity client config and the Sanity docs for your version.

Cause 5: heavy work done at build time

Look for things that do not belong in the build at all: generating image variants for every asset, rendering OG images for every page ahead of time, or running a search index sync inside the build step. Move these to a webhook-triggered job or generate them lazily on request. A build should render pages, not run a content pipeline.

Fix order I use

Measure first: note total build time and page count from a recent deploy log.
Cap generateStaticParams to the pages that matter. This is usually the biggest single win.
Trim page queries to explicit projections.
Centralise shared fetches with tags and a revalidate window.
Check CDN usage and rate-limit errors.
Move non-rendering work out of the build.

Do them in that order, rebuilding after each, so you know which change paid off.

How to verify the fix

Compare build duration and the number of statically generated routes before and after. Then visit a page you did not prerender: the first load should work, and the second should be served from cache. Finally, publish a change in Studio and confirm it appears without a full redeploy. If it does not, the problem has moved to revalidation, not the build.

What to ask a developer

Which pages are prerendered, and why those?
How are shared queries cached, and how are they invalidated on publish?
What happens on first request to a page that was not prerendered?
Can you show the build log before and after?

If the answers are vague, expect the same problem to return as content grows.

This is work I do. If your deploys have gotten painfully slow, my Performance & Sanity audit, from $800, finds the cause and gives you a prioritised fix list.

Restructure a Sanity schema on a live site without breaking pages

Nayan Kyada — Thu, 05 Nov 2026 12:36:02 +0000

If you need to restructure a Sanity schema on a site that is already live, the fear is reasonable: one renamed field and a page renders blank, or an editor opens a document and half the content has vanished. The good news is that Sanity stores content separately from your schema, so you can change the model safely if you move in the right order. This post is the order I use on inherited and aging projects.

Symptoms of a content model that needs restructuring

You rarely hear "our schema is bad". You hear things like these:

Editors paste the same block of copy into five documents because there is no shared type.
Pages have fields named heroTitle2, heroTitleNew and heroTitleOld, and nobody knows which one renders.
A simple page query is forty lines of GROQ with nested conditionals, because three generations of structure all still exist in the dataset.
Developers are afraid to touch the Studio config, so new requests get bolted on instead of modelled.
Everything is a single page type with thirty optional fields, so editors see a wall of inputs that mostly do not apply.

These are not cosmetic. They slow every future change, they make queries heavier than they should be, and they are a large part of why editors end up avoiding the Studio. I covered that side in why editors avoid Sanity Studio and the fix.

What it costs to leave it alone

The cost is not a single bill. It is a tax on every task. A new landing page takes three days instead of one because the developer has to work out which fields are live. Bugs appear when someone fills in the legacy field and the frontend reads the new one. Query payloads grow, which shows up in page speed and in your API usage. And the person who understands the mess becomes a single point of failure. If that person is already gone, start with taking over an existing Next.js project.

Step 1: audit what is actually used

Before changing anything, find out what the dataset contains, not what the schema claims. Export a copy with npx sanity@latest dataset export and look at which document types and fields are populated. Count documents per type and check which fields are empty across nearly all documents. Fields that are never filled in can usually be deleted outright, with no migration.

Then do the reverse check: search the frontend for every field a query reads. Anything in the schema that no query touches is a candidate for removal. My process for finding dead types is in auditing and pruning unused Sanity document types.

Write the target model on paper first. Decide which types become reusable objects, which become referenced documents, and which fields collapse into one.

Step 2: work somewhere that is not production

Do not rehearse a restructure on the dataset editors are using. Export production into a separate dataset or a staging project, point a preview deployment at it, and run everything there first. If you only have one dataset today, splitting staging and production safely is the prerequisite step.

Step 3: make the frontend read both shapes

This is the step that prevents downtime. Before any data moves, update your GROQ to accept old and new fields. Deploy that first. Then the data can change underneath without the site noticing.

// lib/sanity/queries.ts - transition query, safe before and after migration
*[_type == "page" && slug.current == $slug][0]{
  _id,
  title,
  "hero": {
    "title": coalesce(hero.title, heroTitle),
    "subtitle": coalesce(hero.subtitle, heroSubtitle)
  }
}

coalesce returns the first value that is not null, so the page renders correctly whether a document has the old flat fields, the new hero object, or both. For more patterns like this, see advanced GROQ queries with joins and coalesce.

Step 4: add the new fields, keep the old ones temporarily

In the Studio, add the new structure alongside the old. Mark the old fields as hidden: true or readOnly: true so editors stop writing to them, but do not delete them yet. If you delete a field from the schema while documents still hold values, Sanity shows those values as unknown fields in the editor, and your migration script becomes harder to reason about.

Step 5: migrate the data with a script

Sanity has a migration tool in the CLI. You create a migration with npx sanity@latest migration create, write the transform, and run it with npx sanity@latest migration run. It runs as a dry run by default, and you pass --no-dry-run to commit changes. Always read the dry-run output first.

// migrations/hero-fields-to-object/index.ts
import {defineMigration, at, set, unset} from 'sanity/migrate'

export default defineMigration({
  title: 'Move flat hero fields into a hero object',
  documentTypes: ['page'],
  migrate: {
    document(doc) {
      if (!doc.heroTitle) return
      return [
        at('hero', set({title: doc.heroTitle, subtitle: doc.heroSubtitle})),
        at('heroTitle', unset()),
        at('heroSubtitle', unset()),
      ]
    },
  },
})

Two habits matter here. First, make the script idempotent: the early return means running it twice does nothing the second time. Second, run it against the staging dataset, open a sample of migrated documents in the Studio, and load the preview pages before touching production.

Note that drafts and published versions are separate documents. Check that your migration handles both, otherwise an editor opens a draft next week and finds the old structure back.

Step 6: clean up

Once production is migrated and the site has run cleanly for a while, remove the old fields from the schema and simplify the query back to the new fields only. Regenerate types if you use TypeGen so the compiler flags anything still reading a removed field. That is the point where the dual-read GROQ goes away and the payload shrinks.

What to ask a developer before they start

Will you run the migration on a copy of the dataset first, and can I see the dry-run output?
How will the live site keep rendering while data moves?
What is the rollback plan? A dataset export taken immediately before the run is the minimum answer.
How will you handle draft documents and references that point at changed types?
Who writes the editor-facing explanation of what changed in the Studio?

A developer who answers these without hesitation has done this before. One who proposes editing production schema and "seeing what happens" has not.

When to get help

A restructure on a small site is a few days of careful work. On a dataset with thousands of documents, multiple locales and several frontends reading it, it deserves a proper plan. This is work I do: I usually begin with the performance and Sanity audit from $800, which produces the target model and a migration plan, before any data is touched.

Vercel bill too high on a Next.js site? What drives it and how to cut it

Nayan Kyada — Wed, 04 Nov 2026 12:21:34 +0000

If your Vercel bill is too high for a Next.js site that does not get much traffic, the problem is almost never the traffic. It is a handful of configuration choices that make every request, crawl, and content edit cost more than it should. This post walks through the usual culprits on Sanity-backed sites, how to confirm each one, and the order I would fix them in.

Symptoms that point to a config problem, not growth

The pattern is consistent. Usage climbs while analytics visitors stay flat. A month with one big content import costs more than a month with a campaign. The invoice has line items nobody on the team can explain. If any of that sounds familiar, you are paying for waste.

Before touching code, open the Usage page in the Vercel dashboard and note which metric is largest: data transfer, edge requests, function duration and invocations, image optimization, or ISR reads and writes. Plan names and included amounts change, so confirm limits on Vercel's pricing page rather than trusting any blog, including mine. For background on how the plans fit together, see what you actually pay for a real Next.js project on Vercel.

What it costs to ignore

Usage-based costs compound quietly. A site that costs a modest amount at launch can drift upward every month as the content library grows, more pages get crawled, and more editors publish. Teams then react by downgrading features or blaming the framework, when the fix is usually a day or two of targeted work. Ignoring it also hides risk: the same settings that inflate cost often cause slow pages and stale content.

Cause 1: image optimization on oversized originals

Every unique combination of source image, width, and quality is a transformation that gets cached and billed in some form. Sanity images are often uploaded at 4000 pixels wide straight from a designer, and a careless sizes attribute makes Next generate many variants of each.

Sanity's CDN already resizes and converts formats on the fly. Running those images through Vercel's optimizer as well means you pay twice for the same job. I covered the quality side of that in serving WebP and AVIF from Sanity without double-encoding. The cost fix is to hand resizing to Sanity with a custom loader:

// lib/sanity-image-loader.ts
import type { ImageLoaderProps } from 'next/image'

export default function sanityImageLoader({ src, width, quality }: ImageLoaderProps) {
  const url = new URL(src)
  url.searchParams.set('w', String(width))
  url.searchParams.set('q', String(quality || 75))
  url.searchParams.set('auto', 'format')
  return url.toString()
}

// next.config.ts
import type { NextConfig } from 'next'

const config: NextConfig = {
  images: {
    loader: 'custom',
    loaderFile: './lib/sanity-image-loader.ts',
  },
}

export default config

This applies to every next/image on the site, so if you also serve non-Sanity images, either pass full URLs your loader can handle or set the loader per component. Also fix the sizes attribute, so the browser asks for 400 pixels on a card instead of 1600.

Cause 2: revalidation that rebuilds too much

A webhook that calls a path revalidation for the homepage, the blog index, and every listing on each publish creates a burst of regenerations. Ten editors saving drafts all day makes it worse if drafts trigger the webhook at all.

The fix is to filter the webhook so it fires only on published documents, and revalidate by cache tag so only affected pages regenerate. I wrote up the batching approach in Sanity webhook revalidation: batching tags. Confirm the problem by looking at function invocations right after an editing session.

Cause 3: the proxy runs on everything

In Next.js 16 the old middleware file is the proxy file. If its matcher is missing or too broad, it executes on every request: images, fonts, scripts, and bot probes included. That inflates edge requests and adds latency to pages that could have been served straight from cache.

// proxy.ts
import { NextResponse, type NextRequest } from 'next/server'

export function proxy(request: NextRequest) {
  // locale or redirect logic only
  return NextResponse.next()
}

export const config = {
  matcher: ['/((?!_next/static|_next/image|favicon.ico|.*\\..*).*)'],
}

Better still, move redirects into next.config.ts where they are static, and keep the proxy for logic that genuinely needs per-request code.

Cause 4: bots and dynamic routes

Crawlers hit your site constantly. If a route reads cookies, headers, or search params, or uses an uncached fetch, the whole page becomes dynamic and every bot visit runs a function. Faceted filters and calendar-style URLs can give a crawler effectively infinite pages. Check Observability for the top paths and user agents. Typical fixes: make routes static with generateStaticParams, push filtering into client state instead of URL variants, block junk paths in robots.txt, and use Vercel's firewall rules for abusive traffic.

Cause 5: over-fetching from the CMS

Fat GROQ queries and fetches without cache tags make pages slower to render, which raises function duration, and they also drive up your Sanity bill. If both invoices are rising, read why Sanity API requests explode on Next.js sites next.

Fix order I would follow

Read the Usage page and pick the single biggest line item.
Set a spend limit so a runaway month cannot surprise you.
Fix images first, since it is usually the cheapest win.
Tighten the proxy matcher and static redirects.
Filter webhooks and move to tag-based revalidation.
Audit dynamic routes and bot traffic.
Recheck usage after one full week, not one day.

What to ask a developer

Ask which metric they would attack first and why. Ask how they will verify the saving, and whether they will show before-and-after usage from the dashboard. Be wary of anyone who proposes moving hosts before they have looked at the usage breakdown. A move can be right, but the same waste usually follows you. The hosting comparison in Next.js hosting cost across Vercel, Netlify, Railway and a VPS helps judge when it genuinely is.

Work I do

Tracing a bloated Vercel or Sanity bill back to its causes is work I do as part of a fixed-price performance and Sanity audit, from $800. Details are on the services page.

Next.js pages not indexed by Google: causes and the fix path

Nayan Kyada — Tue, 03 Nov 2026 12:08:51 +0000

Your developer launched the Next.js and Sanity site, the pages look fine, and Google still shows half of them as "Discovered - currently not indexed" or "Crawled - currently not indexed". If you are searching for why your Next.js pages are not indexed, the cause is almost always one of five fixable things, and none of them require a rebuild.

What the symptoms look like

Open Search Console and go to the page indexing report. The reason attached to each URL is the most useful clue you have. These are the patterns I see most often on Sanity-backed sites:

Pages excluded by a noindex tag, even though nobody meant to add one.
Alternate page with proper canonical tag, where Google thinks your page is a copy of another one.
Discovered or Crawled but not indexed, where Google found the URL and chose not to keep it.
Soft 404, where an empty or error-like page returns a normal status.
Submitted URL not found in the sitemap report, where the sitemap lists URLs that no longer exist.

Traffic that never arrives is a quiet loss. Nobody gets an alert. The cost is every month those pages could have ranked, plus the money spent building them. If the site replaced an older one, the loss is compounded, because the old URLs were ranking and the new ones are not. The website redesign SEO checklist covers the redirect side of that.

Cause 1: a noindex that should not be there

This is the first thing to rule out. Common sources: a shared metadata helper that sets robots to noindex when an environment variable is missing, a Sanity SEO field where editors tick a "hide from search" box on templates and the default leaks to every page, or a staging flag copied into the production environment on Vercel.

Do not trust the code. View source on the live URL and search for the robots meta tag. Also check the response headers for an X-Robots-Tag, which can be set in next.config or at the host level.

Cause 2: canonicals pointing somewhere else

If every page has the canonical set to the homepage, or to a preview domain, Google will drop the page. This happens when the canonical is built from a base URL environment variable that is wrong in production, or when a trailing slash difference makes the canonical not match the served URL.

Build canonicals from one source of truth and make them self-referencing per page. Here is the pattern I use in the App Router:

// app/[slug]/page.tsx
import type { Metadata } from 'next'
import { notFound } from 'next/navigation'
import { client } from '@/sanity/lib/client'

const SITE_URL = process.env.NEXT_PUBLIC_SITE_URL ?? 'https://example.com'

type Props = { params: Promise<{ slug: string }> }

export async function generateMetadata({ params }: Props): Promise<Metadata> {
  const { slug } = await params
  const page = await client.fetch(
    `*[_type == "page" && slug.current == $slug][0]{ title, "description": seo.description, "noIndex": seo.noIndex }`,
    { slug }
  )
  if (!page) notFound()

  return {
    title: page.title,
    description: page.description,
    alternates: { canonical: `${SITE_URL}/${slug}` },
    robots: page.noIndex ? { index: false, follow: true } : undefined,
  }
}

Note that robots is only set when the editor explicitly opts out. Leaving it undefined means the default, which is indexable.

Cause 3: the sitemap lists the wrong things

A sitemap that includes redirected URLs, noindexed pages, or drafts tells Google the site is untidy. A sitemap that is missing whole content types means Sanity documents never get discovered except through internal links. Generate it from Sanity, exclude opted-out documents, and use the real last-modified date:

// app/sitemap.ts
import type { MetadataRoute } from 'next'
import { client } from '@/sanity/lib/client'

const SITE_URL = process.env.NEXT_PUBLIC_SITE_URL ?? 'https://example.com'

export default async function sitemap(): Promise<MetadataRoute.Sitemap> {
  const pages = await client.fetch<{ slug: string; updated: string }[]>(
    `*[_type == "page" && defined(slug.current) && seo.noIndex != true]{ "slug": slug.current, "updated": _updatedAt }`
  )
  return pages.map((p) => ({
    url: `${SITE_URL}/${p.slug}`,
    lastModified: new Date(p.updated),
  }))
}

Then submit the sitemap URL in Search Console and compare submitted against indexed counts.

Cause 4: soft 404s and empty pages

If a Sanity document exists but its body is empty, or a dynamic route renders a "not found" message without calling notFound(), Google sees a thin page and reports a soft 404. Also be aware that when a page streams, the status code can already be sent as 200 before a not-found is triggered, and Next.js handles this by adding a noindex tag to the output. Check what your error pages actually return with a header check rather than assuming.

On the content side, add a Studio validation rule so editors cannot publish a page with no title, description, or body. That prevents thin pages at the source.

Cause 5: weak internal linking and duplicate content

"Crawled - currently not indexed" is often a quality signal rather than a technical fault. Pages that exist only in the sitemap with no links from other pages, near-identical location or service pages, and tag archives with one post each all land here. The fix is editorial plus structural: link important pages from navigation and related content, merge or remove near-duplicates, and give each page a clear reason to exist. Adding proper JSON-LD structured data helps Google understand the page, but it will not rescue a thin one.

The fix path and how to verify

Export the not-indexed URLs from Search Console and group them by reason.
Check the live HTML and headers of three URLs per group for robots, canonical, and status.
Fix the shared cause in code (metadata helper, sitemap, environment variables) rather than page by page.
Fix content causes in Sanity: thin pages, missing SEO fields, duplicates.
Redeploy, use the URL inspection tool on one URL per group, then request indexing.
Recheck the report after a couple of weeks. Counts should move toward the sitemap total.

If you are not sure whether the problem is technical or editorial, a Next.js website audit answers that quickly. Choosing a stack with this in mind from the start is covered in how to choose a CMS for SEO.

What to ask a developer

Can you show me the rendered robots tag, canonical, and status code for five live URLs?
Where does the base URL come from, and is it set correctly in production?
How is the sitemap generated, and does it exclude noindexed and redirected pages?
What happens in Studio when an editor publishes a page with an empty SEO field?
Will you give me a before-and-after of the indexing report?

A developer who answers these with evidence, not reassurance, is the right one.

Work I do

Diagnosing and fixing indexing problems on Sanity and Next.js sites is work I do as part of a Performance & Sanity audit, which starts from $800. You can see the details on the services page.

Sanity staging and production on one dataset: how to split it safely

Nayan Kyada — Mon, 02 Nov 2026 12:43:18 +0000

If your Sanity staging and production environments read from the same dataset, you are one bad script or one half-finished edit away from a public mistake. I see this setup on inherited projects constantly: a Vercel preview URL that looks like staging but is wired to the live dataset. This post covers the symptoms, what it costs to ignore, and the safe path to a proper split.

Symptoms that you share one dataset

You probably have this problem if any of these sound familiar:

Editors are afraid to create a draft because "it might show up on the site".
The developer tests a schema change by editing live documents.
The staging site and the production site show identical content, always.
There is one .env file, or the preview and production environment variables in Vercel have the same dataset value.
Nobody can say which documents are test data. Titles like "test 2" or "DELETE ME" are live.

Check it in two minutes. Open your Vercel project settings, compare the Sanity dataset variable across the Production and Preview environments, and open the Studio config to see which dataset it points to. If they all say production, that is your answer.

What it costs to ignore

The risk is not abstract. A shared dataset means:

Migration scripts run against live content. A patch script with a wrong filter rewrites real pages. Sanity has history, but restoring document by document under pressure is slow.
Schema changes land before the code is ready. You rename a field in the Studio, editors fill it in, and the production frontend still queries the old name. Pages render blank sections.
No safe place to rehearse a redesign or a migration. Every big change is tested in front of your customers.
Preview deployments leak. Draft content for a launch can be visible through a preview URL that someone shares in Slack.

One broken hero on your homepage costs more than the afternoon it takes to fix this properly.

The fix path

The safe order is: back up, create the new dataset, copy content, change config, then change the workflow. Do not start by editing environment variables.

1. Back up production first

Export before touching anything. The archive includes documents and assets.

# run from your Studio folder
npx sanity dataset export production ./backups/production-before-split.tar.gz

Store that file somewhere outside the repo. It is your undo button.

2. Create a staging dataset and seed it

npx sanity dataset create staging
npx sanity dataset import ./backups/production-before-split.tar.gz staging

If you prefer, the CLI also has a dataset copy command that does this in one step. Either way, open the new dataset in the Studio afterwards and confirm that images load, because assets are the part that most often goes wrong on a first attempt.

A word on privacy: a copy of production content may contain real customer data such as form submissions or author emails. If so, scrub those documents in staging before giving anyone access.

3. Expose both datasets in the Studio

Editors need to know which environment they are in. Workspaces make that obvious, with a separate URL path and name for each.

// sanity.config.ts
import {defineConfig} from 'sanity'
import {structureTool} from 'sanity/structure'
import {schemaTypes} from './schemaTypes'

const projectId = process.env.SANITY_STUDIO_PROJECT_ID!

const shared = {
  projectId,
  plugins: [structureTool()],
  schema: {types: schemaTypes},
}

export default defineConfig([
  {
    ...shared,
    name: 'production',
    title: 'Production',
    basePath: '/production',
    dataset: 'production',
  },
  {
    ...shared,
    name: 'staging',
    title: 'Staging',
    basePath: '/staging',
    dataset: 'staging',
  },
])

Most teams give editors the production workspace only and keep staging for developers and for reviewing big changes. If you want editors to rehearse, tell them clearly that nothing in staging reaches the live site.

4. Drive the dataset from environment variables

The frontend should never hardcode a dataset name. Read it from the environment so Vercel can scope it per environment.

// src/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: '2025-01-01',
  useCdn: true,
})

In Vercel, set NEXT_PUBLIC_SANITY_DATASET to production for the Production environment and staging for Preview. Redeploy, because public variables are inlined at build time.

5. Fix everything else that points at the old setup

This is the step that gets skipped, and it is why staging "works" but behaves oddly:

Webhooks. The revalidation webhook is configured per project with its own dataset filter. Create a separate one for staging that calls your preview URL, with its own secret. Otherwise staging edits revalidate production, or nothing revalidates at all. See my notes on Sanity webhook revalidation with batched tags.
API tokens. Read tokens used for draft mode should be separate for each environment, so a leaked preview token cannot read production drafts.
CORS origins. Add your staging and preview origins in the project settings so the Studio and any client-side fetches work.
Preview and draft mode. Point the Presentation or preview setup at the right dataset, as covered in Sanity draft mode preview with Next.js App Router.

How to verify the split worked

Make a deliberate change in staging, such as adding "STAGING TEST" to a page title, and publish it. It should show on the preview URL and nowhere on production. Then check that a production edit does not appear on staging. Finally run a dry-run of any migration script against staging and confirm the document counts match your expectation before it ever sees production.

Also confirm that your build does not fall back to a default dataset when the environment variable is missing. A silent fallback to production quietly rebuilds the original problem.

What to ask a developer

Whether you are hiring me or someone else, ask these before work starts:

Which datasets exist today, and which environments point at each?
How will you back up production before any change, and where is the backup stored?
Will webhooks, tokens and CORS be separated too, or only the dataset name?
How do schema changes move from staging to production without a gap where the frontend breaks?
What goes in the handover? My Sanity project handover checklist lists what you should expect, and taking over an existing Next.js project covers the wider inherited-codebase picture.

For most sites this split is a few hours to a day, depending on how tangled the webhooks and previews are. It often falls out of a broader review, such as a Performance & Sanity audit from $800.

This is work I do: if you suspect your Sanity site is running staging and production on one dataset, see my Sanity and Next.js services and I can scope the split for you.

Sanity API bill spiking? Why requests explode on Next.js sites

Nayan Kyada — Sun, 01 Nov 2026 11:24:44 +0000

If your Sanity invoice or usage warning jumped and nobody changed the content volume, the cause is almost always how the Next.js front end talks to the API. A Sanity API bill spike is rarely about editors; it is about requests per page view. This post covers the symptoms, what leaving it alone costs, and the fix path I follow.

Symptoms of a Sanity API bill spike

The pattern is consistent across sites like this:

A usage email or dashboard warning about API requests or CDN requests, with no matching traffic growth.
Request counts that climb on days with a crawler spike or an email campaign.
Pages that feel fine but the Studio or the site occasionally returns rate-limit errors.
A Vercel bill that rose at the same time, because uncached pages also burn function time.

Open the usage section in your Sanity project management page and compare it with your hosting analytics. If API requests grow faster than page views, the site is making too many calls per visit. Plan limits and overage rules change, so confirm the current numbers on the Sanity pricing breakdown and Sanity's own pricing page before you draw conclusions.

What it costs to ignore it

The direct cost is overage or a forced plan upgrade. The indirect costs are worse:

Slow pages, because every uncached request adds a network round trip to the render. I covered the diagnosis side in Sanity website slow? How to find the cause.
Rate limiting under load, which shows up as failed builds or blank sections exactly when traffic peaks.
A false belief that Sanity is expensive, which sometimes triggers a pointless migration.

Buying a bigger plan hides the problem until the next traffic jump. Fixing the request pattern is usually a few days of work, not a rebuild.

Cause 1: the client bypasses the CDN

The most common finding is a client configured with the CDN turned off everywhere, often copied from a preview setup and never changed back.

// src/sanity/lib/client.ts (broken pattern)
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: '2025-01-01',
  useCdn: false, // every published read hits the live API
})

Published content does not need to be live to the millisecond. Use the CDN for it and keep a separate path for drafts.

// src/sanity/lib/client.ts (fixed)
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: '2025-01-01',
  useCdn: true,
})

export async function fetchPublished(query: string, params: Record<string, unknown> = {}, tags: string[] = []) {
  return client.fetch(query, params, {
    next: { revalidate: 3600, tags },
  })
}

The tags argument matters for the next cause.

Cause 2: no Next.js caching or tag revalidation

If pages render dynamically on every request, each visit costs one or more Sanity calls. Bots multiply that. The fix is to cache fetches, tag them by document type, and revalidate from a webhook when content changes. The webhook side is written up in Sanity webhooks with ISR revalidation, and for busy publishing days see batching tags so ten edits do not trigger ten rebuild storms.

Check for accidental opt-outs too: reading cookies or headers in a layout, or passing cache: 'no-store' in a shared fetch helper, makes the whole route dynamic.

Cause 3: draft mode and preview leaking into production

Preview setups sometimes poll or use a non-CDN token client on every page, not just inside draft mode. Confirm that the token-bearing client is only used when draft mode is enabled and never ships to the browser. If you run live preview, scope it to the Presentation tool sessions. See draft mode without sacrificing edge performance for the pattern.

Cause 4: heavy queries and N+1 fetching

One page making six separate fetches, or a list component that fetches per card, multiplies every view. Collapse them into one GROQ query with a projection that returns only what the page renders.

*[_type == "post" && defined(slug.current)] | order(publishedAt desc)[0...12]{
  title,
  "slug": slug.current,
  publishedAt,
  "author": author->name,
  "image": mainImage.asset->{url, metadata{dimensions, lqip}}
}

The related reading is avoiding N+1 queries with Sanity references. Also check generateStaticParams: a build that fetches the full document for every path, repeated by several workers, can generate a surprising number of requests per deploy.

Cause 5: bots, previews and image URLs

Crawlers hit uncached routes such as search pages, filter combinations, and paginated archives with unbounded parameters. Cache or block those, and add a sensible robots rule. For images, serving original uploads at full size inflates CDN traffic. Use next/image with proper sizes so the browser requests the right width instead of the original.

The fix path

Pull usage numbers from Sanity and traffic from your host, and compare the ratio over the last few weeks.
Search the codebase for useCdn: false, no-store, and revalidate = 0.
Route all published reads through one cached fetch helper with tags.
Wire a webhook that revalidates by tag on publish.
Merge multi-fetch pages into single projected queries.
Block or cache crawler traps.
Re-measure after a week. The request-per-pageview ratio should fall sharply.

What to ask a developer

How many Sanity requests does one page view cost today, and how will you measure it?
Which routes are dynamic, and why?
Will content still update within a minute of publishing after the caching changes?
Do you keep drafts and published reads on separate clients?
Can you show before and after request counts from the dashboard?

Be cautious about anyone whose first answer is to switch CMS. The API pattern is the problem, not the platform.

Work I do

This kind of diagnosis and cleanup is work I do as a fixed-scope Performance and Sanity audit, from $800, and the findings usually tell you whether a small fix or a bigger one is needed. For what an audit covers, see what a paid Next.js audit includes.

Sanity Preview Not Working: Causes and Fixes for Next.js

Nayan Kyada — Sat, 31 Oct 2026 10:29:59 +0000

Your editor clicks Presentation in the Studio and gets a blank frame, a refused connection, or a page that loads but shows published content and no edit overlays. Preview failures almost always come down to five things: framing and CORS, the enable route and secret, the draftMode cookie, the fetch not using drafts, and caching. Work through them in this order, because each one hides the next.

This post assumes you already have Presentation wired up. If you do not, start with Sanity Live Preview in Next.js App Router (Presentation). This is only about diagnosis.

Symptom checklist: which failure do you have?

Match what you see before changing code:

What you see	Most likely cause
Blank frame, console says refused to display in a frame	Frame headers (cause 1)
Frame loads, Studio says it cannot connect or stays on loading	Missing visual editing component or origin mismatch (cause 2)
Enable route returns 401 or 400	Secret or token mismatch (cause 3)
Page loads, but shows published content	Fetch ignoring drafts (cause 4)
Works once, then goes stale	Caching (cause 5)
Content shows but no click-to-edit overlays	Stega or missing component (cause 6)

Cause 1: the page cannot be framed

Presentation renders your site inside an iframe in the Studio. If your app sends a header that forbids framing, the browser blocks it, and you get a blank pane. This is common on sites where someone added security headers to pass an audit.

The broken pattern:

// next.config.ts
const nextConfig = {
  async headers() {
    return [
      {
        source: '/(.*)',
        headers: [{ key: 'X-Frame-Options', value: 'DENY' }],
      },
    ]
  },
}
export default nextConfig

The fix is to allow your Studio origin with a Content-Security-Policy frame-ancestors directive instead, and drop the blanket DENY. Put your real Studio URL in the list, plus the local one for development:

// next.config.ts
const nextConfig = {
  async headers() {
    return [
      {
        source: '/(.*)',
        headers: [
          {
            key: 'Content-Security-Policy',
            value:
              "frame-ancestors 'self' https://studio.example.com http://localhost:3333",
          },
        ],
      },
    ]
  },
}
export default nextConfig

If you want to be stricter, apply the permissive policy only on preview deployments using an environment variable. Do not leave production open to every origin.

Cause 2: origin and URL mismatches

Two separate origin settings trip people up.

The previewUrl in the Presentation tool. If it points at localhost in production Studio, or at a deployment URL that has since changed, the frame loads the wrong thing or nothing. Check the previewUrl.origin value in your Studio config for the environment you are actually using.
CORS origins in the Sanity project. Client-side queries from the frame, such as live updates, need your site origin allowed in the project's API settings in the Sanity management console. Add the exact origin, including protocol and port, and enable credentials only for origins you trust.

A mismatch between a www and non-www domain, or between a Vercel preview URL and your production domain, is the classic one. The browser console will show a CORS error naming the origin it rejected. Copy that string exactly.

Cause 3: the enable route and secret

Presentation hits your draft-enable route with a secret it generated. If your route rejects it, the frame never enters draft mode. Typical reasons:

The route handler path in your code does not match the previewMode.enable path in the Studio config.
The read token is missing in the environment where the route runs. Vercel has separate variables per environment, so a token set only for Production fails on Preview.
The token has viewer access only, or was created for another project. It needs read access to the dataset including drafts.
You are validating against a hand-rolled secret instead of letting the Sanity helper validate the request.

The working route, using the next-sanity helper:

// src/app/api/draft-mode/enable/route.ts
import { defineEnableDraftMode } from 'next-sanity/draft-mode'
import { client } from '@/sanity/lib/client'

export const { GET } = defineEnableDraftMode({
  client: client.withConfig({ token: process.env.SANITY_API_READ_TOKEN }),
})

If this returns 401, log whether process.env.SANITY_API_READ_TOKEN is defined on that deployment. It is undefined far more often than the token is wrong.

Cause 4: the draftMode cookie is set but the fetch ignores it

Draft mode only sets a cookie. It does not change what your queries return. If the page shows published content while the toolbar says draft mode is on, your fetch layer is not switching.

In Next.js 16, draftMode() is async. Forgetting to await it is a common bug when code is copied from older examples. The reliable pattern is defineLive from next-sanity, which handles perspective and token for you. If you use a plain client, switch the perspective yourself:

// src/sanity/lib/fetch.ts
import { draftMode } from 'next/headers'
import { client } from './client'

export async function sanityFetch<T>(query: string, params = {}) {
  const { isEnabled } = await draftMode()
  return client
    .withConfig({
      useCdn: !isEnabled,
      token: isEnabled ? process.env.SANITY_API_READ_TOKEN : undefined,
      perspective: isEnabled ? 'drafts' : 'published',
    })
    .fetch<T>(query, params)
}

Two details matter here. The CDN must be off for drafts, because the CDN only serves published content. And the token must stay on the server. If a token ever reaches the browser bundle, rotate it.

Also check third-party cookies. The Studio and your site are on different origins, so the draftMode cookie is set in an iframe context. Browsers that block third-party cookies can drop it. Sanity's helper sets the cookie in a way designed for this, but a hand-written route that omits the right attributes will fail in Safari and in some Chrome configurations. Test in more than one browser before blaming your code.

Cause 5: caching serves stale or published output

Pages that are statically cached will not reflect drafts. Draft mode opts the request out of the static cache, but your own cache layers do not know that. Look for:

A use cache function or tagged fetch wrapping your data call without keying on draft state. The published result gets served in draft mode.
A CDN or proxy in front of the preview deployment caching responses that carry the draft cookie.
Middleware that rewrites or redirects before the cookie is read.

The rule: when draft mode is on, bypass your cache wrapper entirely. Keep the cached path for published traffic and call the uncached path for drafts. If you run an edge setup, Sanity Draft Mode Without Sacrificing Edge Performance covers how to keep that split without slowing visitors down.

Cause 6: stega and missing overlays

If content updates but click-to-edit overlays are missing, stega is not active or the visual editing component is not mounted. Stega embeds invisible source data into strings so the overlay knows which field each piece of text came from.

// src/sanity/lib/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: '2025-01-01',
  useCdn: true,
  stega: { studioUrl: process.env.NEXT_PUBLIC_SANITY_STUDIO_URL },
})

Then render the visual editing component in your root layout only when draft mode is enabled. Without it, the frame loads but nothing is clickable.

The flip side: stega characters break strings you compare or pass to non-display code, such as slugs used in URLs, enum values, or JSON-LD. Strip stega for those fields, or apply stega only on the draft-mode client. If a slug lookup fails only in preview, this is the reason.

How to verify the fix

Open the enable route directly with the secret from the Presentation request in the network tab and confirm it returns a redirect, not a 401.
Check the response sets a draft-mode cookie, then reload a page and confirm the toolbar or your own indicator shows draft state.
Edit a field in the Studio without publishing. The frame should update without a manual refresh.
Click a text element and confirm the Studio jumps to that field.
Repeat in a second browser and on the deployed Preview URL, not just localhost.
Open the site in a private window with no cookie and confirm visitors still see only published content.

If you still cannot find it after these, that is the point where an outside look is cheaper than another evening of guessing. A Performance & Sanity audit, from $800, covers the preview setup alongside everything else on the site.

Next.js website audit: what a paid one covers and how to judge it

Nayan Kyada — Fri, 30 Oct 2026 10:57:46 +0000

A Next.js website audit is a paid, time-boxed review of a live site that ends in a ranked list of fixes, each with an effort estimate and an expected outcome. If you already own a Next.js site backed by Sanity and something feels off (slow pages, editors complaining, rankings drifting), an audit is the cheapest way to turn a vague worry into a plan. This post explains what you should get for your money, what real findings look like, and how to decide afterwards whether it was worth it.

What a Next.js website audit should cover

A good audit has a defined scope that you can read before paying. For a Sanity and Next.js site I split it into five areas.

Field performance. Not just a Lighthouse run on my laptop. I look at real-user Core Web Vitals (LCP, INP, CLS) from Search Console or your analytics, then lab-test the templates that matter: home page, a landing page, a long article, a listing page. If you have no field data yet, that is itself a finding. The Core Web Vitals monitoring setup is usually the first thing I recommend.

Rendering and caching. Which routes are static, which are dynamic, and whether that matches what the content actually needs. Many sites are accidentally dynamic because one component reads cookies or headers, which turns a page that could be cached into one that hits the origin and Sanity on every request.

Sanity data layer. GROQ queries, schema shape, and how pages fetch content. I check for over-fetching, reference chains that cause waterfalls, and images served without the metadata needed to prevent layout shift. Patterns here are covered in structuring Sanity schemas to avoid query waterfalls.

Studio and editor experience. I open the Studio the way an editor would. Cluttered document lists, unclear field names, missing validation, and drafts mixed in with live content all cost your team time every week.

SEO plumbing. Metadata, canonical URLs, sitemap, robots, structured data, redirects, and whether the rendered HTML contains the content a crawler needs.

A scope that also promises security pen-testing, legal compliance, and a full rewrite estimate for a few hundred dollars is overselling. Narrow and deep beats broad and shallow.

Sample findings from audits like this

I will not quote results from specific clients. What I can describe is the kind of thing that shows up again and again on sites like this:

The hero image is the LCP element and is lazy-loaded or missing a priority hint. Cheap to fix, often the single biggest LCP gain. See fixing LCP on image-heavy pages.
Every page fetches whole documents. Queries return full Portable Text bodies and every field on referenced documents when the template needs a title and a slug. The payload grows with the content, so the site gets slower as editors do their job.
A client component wraps the whole page. One top-level use client directive pulls a large tree into the JavaScript bundle. Splitting it is usually an afternoon, and the bundle size analysis post shows how to find it.
Revalidation is all or nothing. Either nothing refreshes until the next deploy, or every publish invalidates the entire site. Tag-based revalidation from a Sanity webhook fixes both.
The Studio has document types nobody uses. Old experiments sit in the sidebar and confuse new editors.
Structured data is present but wrong. JSON-LD that references a logo URL that now returns 404, or an Article type on pages that are not articles.
Redirects live in three places. Some in the CMS, some in config, some on the host, with chains between them.

None of these are exotic. That is the point: most audit value comes from finding ordinary problems quickly and putting them in the right order.

How the ranked fix list works

The deliverable that matters is the ranked list. Each row should have four things: what is wrong, why it matters to the business, roughly how long the fix takes, and how we will verify it worked. Here is the shape I use:

Rank	Finding	Impact	Effort	Verify with
1	Hero image not prioritised on landing templates	High (LCP)	Under 2 hours	Field LCP trend over 28 days
2	Home page query returns full documents	High (TTFB, payload)	Half a day	Response size and server timing
3	Top-level client wrapper on article pages	Medium (INP, bundle)	1 day	Bundle analyzer, INP trace
4	Webhook revalidates entire site on every publish	Medium (cost, stale pages)	Half a day	Cache hit rate after publish
5	Unused document types in Studio	Low (editor time)	2 hours	Editor walkthrough

Ranking is by impact divided by effort, not by how alarming a Lighthouse score looks. A red metric that needs a two-week rebuild goes below a yellow one that needs an hour.

You can use the list in three ways. Hand the whole thing to your in-house developer and have them work top to bottom. Hire me to fix the top five. Or take it to another developer for a competing quote, which is a perfectly reasonable thing to do. A good audit is portable; if you cannot use it without the person who wrote it, it was a sales funnel.

How to judge whether the audit was worth it

After the call, ask yourself these questions.

Could someone else act on it? If a competent developer can open the document and start work without a meeting, it passed.

Did it say what not to fix? Honest audits include a short list of things that look bad in a tool but do not matter for your traffic or goals. If every finding is urgent, nothing was prioritised.

Did it tie to money or rankings? A fix for INP on a page with no organic traffic is lower priority than a fix for LCP on your best landing page. The post on what fast pages are worth helps frame this.

Were the claims checkable? Each finding should name the page, the file or query, and the measurement. Vague statements like "improve image optimisation" are not findings.

Did you learn something about your own site? Even if you fix nothing, you should now know where the time goes and which parts of the codebase are risky.

Red flags: the report is mostly screenshots of automated tools, the author cannot explain a finding when asked, the audit recommends a full rebuild without ruling out cheaper fixes, or the price is tied to a retainer you must sign first.

If the top fixes are small, the audit may pay for itself within a month through faster pages and fewer editor complaints. If the answer really is a larger change, such as a migration or an upgrade, you at least have a scoped number instead of a guess.

What to prepare before you buy one

Give the auditor read access to the repository, the Vercel project, the Sanity project, and Search Console. Decide in advance who will receive the findings and who can approve work. Write down your top three concerns in plain language, such as "our pricing page is slow on mobile" or "editors avoid creating case studies." A brief like that keeps the audit pointed at outcomes. If you are unsure how to frame it, the guide on writing a project brief for a Next.js developer applies here too.

If your site is already visibly slow and you want to diagnose it yourself first, start with why a Sanity website is slow and what a fix costs.

Work I do

A performance and Sanity audit with a ranked fix list is a fixed-price package I offer, starting from $800. Details are on the services page.

Is Sanity CMS right for my business? An honest decision guide

Nayan Kyada — Thu, 29 Oct 2026 10:59:52 +0000

Most businesses asking whether Sanity CMS is right for them are really asking whether a custom build is worth the money over WordPress or Webflow. Sometimes it is. Often it is not, and I would rather tell you that before you spend anything.

This is a decision guide for non-technical buyers. No jargon, just the questions I would ask you on a first call.

What Sanity actually is

Sanity is a content database with an editing interface called Sanity Studio. It does not make your website. A developer builds the site separately, usually in Next.js, and the site pulls content from Sanity.

That split is the whole point. It gives you freedom over design, speed, and where content appears. It also means you are paying for a build, not installing a theme. If you want the longer technical background, Headless CMS setup: when it makes sense and when it doesn't covers it.

When Sanity is a great fit

Sanity earns its cost when at least two or three of these are true:

Your content has real structure: products, case studies, team members, events, locations, authors, each with their own fields and relationships.
The same content appears in more than one place, such as your website, a mobile app, a newsletter, or a search index.
Several people edit, and you need roles, approvals, scheduled publishing, or review before anything goes live.
You have more than one language or region, with content that differs between them.
Page speed and search visibility directly affect revenue.
You have outgrown a WordPress site that is slow, fragile, or buried in plugins.

If you recognise your business in that list, the next step is a scoped conversation, not a sales pitch. See Sanity CMS website cost in 2026 for realistic budgets.

When Sanity is overkill

Here is the part most developers skip. Sanity is probably the wrong choice when:

The site is a brochure of roughly 5 to 15 pages that changes a few times a year.
One person, maybe two, edits it, and they want to move boxes around visually.
You need to launch in two or three weeks on a small budget.
You have no developer relationship and no plan to build one.
Your needs are covered by a store, booking tool, or membership plugin that already exists in WordPress or Shopify.

In those cases a template-based tool wins on cost and speed. Paying for custom engineering to host a five-page site is not a good use of money.

Team size and content complexity thresholds

These are rules of thumb from practice, not hard laws. Treat them as a starting point for your own judgement.

Your situation	Likely best fit
1 editor, under 15 pages, few updates	Webflow or WordPress
1 to 3 editors, blog plus marketing pages, visual layout control wanted	Webflow
2 to 5 editors, 3 or more content types, SEO important	Sanity or well-run WordPress
5+ editors, approvals, roles, multiple languages	Sanity
Content reused in app, site, and other channels	Sanity
Large existing WordPress site, slow and plugin-heavy	Sanity migration worth scoping

Content complexity matters more than team size. A single editor managing 40 interlinked product pages across three languages benefits from Sanity more than five people maintaining a simple blog.

A useful test: count your content types, meaning distinct kinds of things with their own fields. One or two, and a template tool is fine. Six or more, with references between them, and structured content starts to pay for itself. A nonprofit case study with nine content types shows what that looks like in practice.

Where WordPress or Webflow wins honestly

WordPress has a huge plugin ecosystem, cheap hosting, and almost every freelancer knows it. Webflow lets non-developers design visually and publish quickly. Both have hosting, forms, and basic SEO built in, so you are not stitching pieces together.

The trade-off is control. As needs grow, you fight plugins in WordPress or hit CMS item and plan limits in Webflow. For a direct look, read Sanity vs Webflow for Next.js and Sanity vs WordPress headless: when headless wins.

If your site works, loads reasonably, and your team is happy editing it, staying put is a legitimate answer.

Costs you should expect

The software is rarely the big number. Sanity has a free plan that covers many small projects, and paid plans charge per seat after that. Confirm current limits on Sanity's pricing page before budgeting; they change. The real cost is the build and the ongoing care.

My fixed-price Sanity + Next.js site builds start from $4,000, and moving an existing site into Sanity starts from $3,000. A WordPress or Webflow template site can cost well under that. If your budget is below roughly $3,000 and the site is simple, I will usually tell you to use a template tool. Details on packages are at /services#packages.

Also budget for maintenance. What a Sanity site runs per month breaks that down.

Questions to ask yourself before deciding

How often does content change, and who changes it?
Does the same content need to appear anywhere besides the website?
What does one extra second of load time cost us in leads or sales?
Do we have, or can we hire, a developer for changes after launch?
Are we solving a real limitation, or just a dated design?

That last question matters. A redesign alone does not need a new CMS. If the only complaint is that the site looks old, a new theme might fix it for far less.

Red flags from the other side

Be cautious of any developer who recommends Sanity without asking about your content, team, or budget. The same applies to anyone who calls it the answer for everything. A good recommendation comes from your constraints, not their preferred stack. If you are vetting someone, Sanity CMS development agency vs freelancer is a useful companion.

The short version

Choose Sanity if your content is structured, shared across channels, edited by a real team, or tied to performance that affects revenue. Choose WordPress or Webflow if your site is small, simple, and needs to launch cheaply. Stay where you are if nothing is actually broken.

If you are on the fence, a short conversation costs nothing, and I will tell you straight if a template tool is the better call. If you decide Sanity fits, you can hire me as a Sanity developer.

Sanity Next.js website case study: a nonprofit with 9 content types

Nayan Kyada — Wed, 28 Oct 2026 10:42:55 +0000

This is a composite-style account of a build I do often: a nonprofit organisation with a lot of different kinds of content, rebuilt on Sanity and Next.js. The client stays unnamed, and I have left out numbers I cannot stand behind. What follows is the scope, the decisions that mattered, and what a buyer should expect from the process in a Sanity Next.js website case study like this one.

The situation we started with

The organisation had an ageing site that a volunteer had built years earlier. Staff dreaded updating it. Events were copied by hand from a spreadsheet, team bios lived in three places, and every annual report was a PDF with no web version. Nobody could say which pages were still accurate.

The brief was not "make it pretty". It was: let a four-person communications team publish without asking a developer, make the content reusable, and keep the site quick on weak mobile connections, because many of their supporters browse on phones.

Scope: nine content types, one rule

Before any code, we listed every kind of thing the organisation publishes. The list came to nine:

Content type	Who edits it	Where it appears
Programme	Programmes lead	Programme pages, homepage, funding pages
Event	Comms team	Events list, programme pages, homepage
News post	Comms team	News, homepage, newsletter export
Team member	Operations	About, programme pages
Annual report	Director	Reports archive
Resource (guide, toolkit)	Programmes lead	Resource library, programme pages
Partner	Fundraising	Partners page, footer
Story (beneficiary or supporter)	Comms team	Homepage, programme pages
Generic page	Anyone	About, policies, contact

The one rule I set: if a fact appears in two places, it is stored once and referenced. A team member is a document, not text pasted into a page. That rule drove nearly every schema decision. If you are scoping something similar, my notes on what to define before you write a line of code cover the same discipline.

Schema decisions that paid off

References over copies. Programmes reference team members, events, resources and stories. An editor updating a staff title changes it once, and every page reflects it. The cost is query design, which is why I shape schemas with the rendering in mind, as described in structuring Sanity schemas to avoid query waterfalls.

A small set of page-builder blocks. The generic page type has a limited list of blocks: rich text, image with caption, call to action, callout, and a card grid. I resisted a thirty-block library. Every extra block is something an editor has to learn and a developer has to maintain.

Events with real dates. Events use proper datetime fields plus a validation rule that the end cannot precede the start. The site then filters upcoming and past events automatically, with no one archiving anything by hand.

Annual reports as structured content. Instead of linking to a PDF alone, each report has a summary, key figures, sections in Portable Text, and the PDF as a download. That gave the organisation a searchable, linkable web version, which also helps search visibility.

Validation as training. Required alt text on images, a character limit on meta descriptions, and slug checks for uniqueness. Rules like these teach editors the right habits without a manual.

The Next.js side

The front end uses Next.js App Router with server components, so most pages ship little JavaScript. Content pages are cached and refreshed when an editor publishes, using Sanity webhooks to trigger revalidation. Editors see the update within moments, and visitors get cached pages. Draft preview lets the comms team check a story before it goes live.

For a content-heavy nonprofit, I treat performance as a requirement and not a bonus. Images come from Sanity with hotspot data so crops stay sensible, and layout dimensions are set from image metadata so pages do not jump while loading.

Editor training

This is the part most case studies skip, and it decides whether the project works a year later.

We ran one live session of about ninety minutes with the whole communications team, using their real content, not demo text. The structure:

A tour of the Studio sidebar, which shows only the nine types in the order the team thinks about them.
Publishing a news post from blank to live, including preview.
Creating an event and watching it appear on the programme page it belongs to.
What happens when you make a mistake: version history, unpublish, and who to ask.

They left with a one-page cheat sheet and a short recorded walkthrough. Two weeks later we held a thirty-minute follow-up to answer the questions that only appear once people use the tool. If you want the principles behind this, see what to set up before editors touch the CMS and why editors avoid the Studio and the fix.

Launch

Launch was boring on purpose. We built a redirect map from every old URL before cutover, tested it on a staging address the client could open, and checked that titles, descriptions and canonical tags were present on the new pages. Sitemaps and robots rules were verified, and the old domain's top pages were spot-checked after go-live. The approach follows the same checklist as any redesign that protects search rankings.

The client approved content on staging for a week before launch, which is when most corrections surface. Hold that review window. Compressing it is how typos reach production.

Results, and what I will not claim

I am not going to quote traffic percentages or conversion lifts here, because those depend on the organisation, its starting point and seasonality, and inventing them would be dishonest. What I can describe are the outcomes that were observable:

Staff publish news and events without developer involvement.
Team and programme details are edited once, not in several places.
Pages pass Core Web Vitals checks on mobile in field data once enough visits accumulate.
Annual reports exist as web pages, not just downloads.
The organisation owns its content in a structured form, so a future redesign does not mean re-keying everything.

What a buyer should take from this

Three questions would have saved this organisation years of frustration, and they apply to any similar project:

Can the developer list your content types and relationships before proposing a design?
Will your actual editors be trained on your actual content?
At handover, do you receive the code, the Studio, the documentation and the accounts in your name? There is a full list in the handover checklist.

A project like this typically sits within my fixed-price Sanity + Next.js site build, which starts from $4,000, with scope driving the final number. Details are on the services page. If you are weighing a similar rebuild, the hire a Sanity developer page explains how I work and how to start.

Fix Core Web Vitals on a Next.js + Sanity Site: Fix Order and Timeline

Nayan Kyada — Tue, 27 Oct 2026 09:56:10 +0000

Your Search Console report says "Poor URLs" or "Needs improvement" and your Next.js + Sanity site is supposed to be fast. This post is for owners who need to fix Core Web Vitals on a Next.js Sanity site and want to know which metric is failing, what is usually behind it, what order to fix things in, and how long until the report goes green.

If you want the deeper theory, I cover thresholds in Core Web Vitals in 2026. This post is the triage version: what to do on Monday morning.

Read the Search Console report correctly

Three things trip owners up before any code is touched.

Field data, not lab data. Search Console shows what real Chrome users experienced over a rolling 28-day window. A green Lighthouse score does not override it.
URL groups. Google groups similar pages. If your 400 blog posts share a template, one bad template fails all 400. That is good news: one fix clears a whole group.
Mobile first. Mobile and desktop are reported separately. Mobile usually fails first, so start there.

The thresholds at the 75th percentile are: LCP at or under 2.5 seconds, INP at or under 200 milliseconds, CLS at or under 0.1. Open the failing group, note which metric is flagged, and ignore the other two until that one is dealt with.

LCP failing: the hero image is almost always the cause

On Sanity sites, the Largest Contentful Paint element is nearly always a hero image or a large heading above a hero. The usual causes, in the order I check them:

The hero image is lazy-loaded. next/image lazy-loads by default, so an above-the-fold image needs the priority prop (or loading="eager" with fetchPriority="high").
The image is served at original size because sizes is missing or wrong, so a phone downloads a desktop-sized file.
The page itself is slow to respond, which is a TTFB problem rather than an image problem.
The image URL goes to Sanity's CDN with no width or format hints, so you ship a huge JPEG.

A broken hero looks like this:

// app/components/Hero.tsx (before)
import Image from 'next/image'

export function Hero({ src, alt }: { src: string; alt: string }) {
  return <Image src={src} alt={alt} width={2400} height={1200} />
}

And the fixed version:

// app/components/Hero.tsx (after)
import Image from 'next/image'

export function Hero({ src, alt }: { src: string; alt: string }) {
  return (
    <Image
      src={src}
      alt={alt}
      width={2400}
      height={1200}
      priority
      sizes="100vw"
      className="h-auto w-full"
    />
  )
}

If the LCP is still slow after that, the problem is upstream. I walk through the full pattern in How to fix LCP on image-heavy pages, and server response time is covered in the TTFB post.

CLS failing: images, fonts and late-loading blocks

Layout shift on a Sanity site comes from a short list of suspects:

Images rendered without reserved space. Sanity returns width and height inside the asset metadata, so there is no excuse to omit them. See Kill CLS on Sanity images.
Web fonts swapping in with different metrics. Use next/font, which self-hosts the font and adjusts fallback metrics, rather than a stylesheet link to a font provider.
Embeds, cookie banners and promo bars injected after load, pushing content down.
Animations that move layout properties instead of transforms. If you use Framer Motion, check this write-up.

A fast way to find the offender: in Chrome DevTools, open the Performance panel, record a page load, and look at the Layout Shifts track. Each shift names the element that moved.

INP failing: client JavaScript is the culprit

Interaction to Next Paint measures how long the page takes to respond after a tap or click. It fails when the main thread is busy. On Next.js sites that usually means:

Too much of the tree is marked use client, so a lot of JavaScript hydrates on every page.
Third-party scripts: chat widgets, tag managers, heatmaps, consent tools.
Heavy components such as a Portable Text renderer, carousel or search UI shipped to every visitor.
Click handlers doing synchronous work like filtering large lists.

The fix is to push work to the server and ship less. Move use client down to the smallest interactive leaf, defer third-party scripts, and render rich text on the server. Two related posts: cutting bundle size by analysing chunks and INP for React apps.

The fix order I use

Cost and impact differ, so I do things in this order:

Step	Fix	Typical effort	Metric helped
1	Priority and sizes on the hero image	Under an hour	LCP
2	Width and height on every image, next/font	Half a day	CLS
3	Reserve space for banners and embeds	Half a day	CLS
4	Defer or remove third-party scripts	1 day	INP, LCP
5	Server-render rich text, shrink client components	1 to 3 days	INP
6	Caching and TTFB work	1 to 2 days	LCP

The effort figures are rough ranges for a typical marketing site, not quotes. A site with a messy component tree takes longer.

Expected timeline to green

The timeline is set by Google, not by your developer:

Days 1 to 5: fixes shipped to production. Check the lab results in PageSpeed Insights.
Weeks 1 to 4: field data slowly improves as the 28-day window fills with fast visits. Vercel Analytics or a similar real-user tool shows progress much sooner than Search Console; here is how I set that up.
Week 4 onward: click "Validate fix" in Search Console. Google then monitors the group and typically confirms or rejects over roughly another four weeks.

So plan for six to eight weeks from deploy to a clean report. If a promised fix claims green in a week, that is not how the data works.

What to ask a developer

Which metric fails, on which URL group, and what element is responsible?
How will you measure real-user data, not just Lighthouse?
Will you fix the shared template or patch individual pages?
What third-party scripts are on the site, and who approved each?
What is the plan if field data has not moved after four weeks?

If you want a developer to find the cause rather than guess, this is work I do. A Performance & Sanity audit starts from $800 and gives you a ranked fix list tied to your own Search Console groups.