Services

Fix Stale Next.js Pages When ISR or Revalidation is Not Working

Content is published, but pages stay stale because cached output, invalidation paths, or deployment behaviour keep old versions live longer than anyone expects.

Fix content not updating and stale pages before ISR or revalidation problems make live freshness unpredictable for teams and users.

Short Answer

ISR and revalidation problems matter because they make live freshness unpredictable. A page may look available, but published content still stays stale for editors, customers, or search engines. A good diagnosis follows one content change from trigger to route update, separates cache issues from dependency issues, and makes freshness behaviour predictable again.

Typical Symptoms

  • Published content is not refreshing when ISR or revalidation should update it.
  • Some routes refresh and others stay stale for too long.
  • Teams no longer trust the live freshness behaviour of the platform.

Likely Causes

  • Revalidation triggers and actual route dependencies are out of sync.
  • Caching assumptions changed with platform or routing updates.
  • The site depends on freshness paths that are not fully represented in the current model.

What I Look at First

  • Publish one targeted content change and verify which routes refresh, which stay stale, and how long each path takes.
  • Whether the problem is trigger‑based, cache‑based, or route‑dependency‑based.
  • How deployment and invalidation paths differ between route types.

How I Help Fix This

  • Trace the freshness problem through the actual runtime behaviour.
  • Compare the intended invalidation path with the one production actually follows.
  • Make content freshness more predictable across the affected routes.

When to Look at This

  • When stale pages are undermining editorial or commercial trust in the platform.
  • When ISR exists but nobody can explain confidently why some routes refresh and others do not.

What Gets Resolved

  • ISR, on‑demand revalidation, tags, cache headers, webhooks, and deployment timing are traced as one publishing path.
  • The first real failure is separated from retry noise and downstream symptoms.
  • Local, preview, build, and production differences are made visible.
  • Environment, config, cache, runtime, and deployment behaviour are checked in order.
  • Fixes are prioritised so the team can ship with more confidence.

How This Usually Works

  1. Technical Diagnostic

    A focused review of affected routes, templates, deployment behaviour, crawl signals, CMS behaviour, performance bottlenecks, or code paths, followed by a prioritised fix plan the team can take into delivery.

  2. Recovery Sprint

    A short, concentrated engagement for a defined technical SEO, performance, CMS, Vercel, migration, or production issue where the business needs the cause isolated and the first fixes moved quickly.

Get in touch about the issue

A short description of the affected route, error, or build log is enough. 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, Vercel deployment behaviour sat alongside headless content, route generation, structured data, and live‑site reliability.

    View case study

More Specific Service Pages

Related Services

All Services

Related Technical Articles