Keeping Sanity Content Fresh: ISR, Webhooks, and Cache

A Sanity-backed Next.js site carries a built-in tension. You want pages that are static-fast, but content changes in Sanity and editors expect to see their edits without waiting for a deploy. Incremental Static Regeneration plus webhooks is how you get both.

What ISR does

With ISR you set a revalidation window on a page. Visitors always get a fast, cached response. When the window elapses, the next request serves the stale page and triggers a background regeneration, so the following visitor gets fresh content — without you rebuilding the whole site.

Where webhooks come in

A time-based window is fine for content that changes slowly, but editors don’t want to wait it out. Sanity can fire a webhook on publish, which triggers on-demand revalidation of just the affected paths. The result is near-instant updates on publish, scoped to what actually changed, with no full rebuild.

The Sanity CDN layer

Reads can go through Sanity’s CDN for speed, at the cost of a short freshness lag, or hit the live API with a token for guaranteed-fresh data. The usual split: CDN for production page rendering, tokened fresh reads for draft previews so editors see unpublished work immediately.

Getting the trade-off right

Match the mechanism to the content. Short revalidation for fast-moving pages, on-demand webhook revalidation for editorial publishing, and a preview mode for drafts. Most sites use all three at once, on different routes.

How we run it

This site runs exactly this setup — Next.js with ISR against Sanity, EU-hosted on SrvBot. We dogfood the stack we host, which is why the platform is tuned for Node front ends with revalidation rather than treated as an afterthought. More on hosting the stack at /sanity.

The bottom line

You don’t have to choose between fast and fresh. ISR handles the baseline, webhooks handle the “I just published this” case, and the CDN choice tunes the rest. See how we host it at /sanity.