Services

Fix Stale Content, Webhook and Revalidation Issues in Headless CMS and Next.js Stacks

Content is published in the CMS, but webhooks, caches, and route invalidation no longer agree, leaving changes fresh in one place and stale in another.

Fix content not updating from your CMS before stale pages and revalidation failures stop editors trusting what the live site is actually showing.

Short Answer

Stale content in a headless CMS and Next.js stack usually means webhooks, caches, route dependencies, and revalidation rules no longer line up. Editors lose trust quickly when published changes are fresh in one place and stale in another. Diagnosis should follow one controlled content change through the full freshness path until the failing step is clear.

Typical Symptoms

  • Published content is not appearing on the site when editors expect it to.
  • Webhooks fire but the front end remains stale or partially updated.
  • Different routes refresh at different times or not at all.

Likely Causes

  • Webhook triggers, route invalidation, and cache layers are not aligned.
  • The system does not clearly distinguish preview freshness from published freshness.
  • Revalidation is happening, but not for the routes or dependencies that matter.

What I Look at First

  • Publish one controlled content change and trace the webhook, cache, and route freshness path end to end.
  • Which content changes fail first and whether the failure is deterministic.
  • How freshness behaviour differs between preview and published routes.

How I Help Fix This

  • Trace the stale‑content problem across the actual invalidation chain.
  • Tackle the routes and content types with the clearest commercial impact first.
  • Make freshness more predictable and testable.

When to Look at This

  • When stale content is eroding editorial or commercial trust in the platform.
  • When revalidation exists on paper but behaves differently by route, environment, or content type.

What Gets Resolved

  • The failing freshness boundary is known across cache, webhook, tag, ISR, preview, and production paths.
  • A published change invalidates the exact routes and dependent cache entries that use it.
  • Preview freshness and production freshness follow separate, understood paths.
  • Webhook, tag, and ISR behaviour stays consistent across the affected content types instead of changing route by route.
  • Editors can verify when content is live and recognise a failed update without guessing or repeatedly republishing it.

How This Usually Works

  1. Technical Diagnostic

    A focused review to establish what is happening, where the risk sits, and what should happen next, ending with a prioritised plan the team can take into delivery.

  2. Recovery Sprint

    A short, concentrated engagement to isolate a defined problem, stabilise the immediate situation, and move the first fixes into delivery.

Reviewing your CMS setup?

Tell me what editors and developers need from the CMS, and what you want the current setup to handle better. I'll read it and suggest the next step.

Get in touch

Related Case Studies and Project Work

  1. Screenshot of the Nando’s website; part of John Kavanagh's selected project work.

    A Complete Migration and Replatform for Nando’s

    On Nando’s, headless content, Next.js rendering, Vercel deployment behaviour, and search‑critical local pages had to work as one system.

    View case study

More Specific Service Pages

Related Services

All Services

Related Technical Articles