CMS Content Not Updating in Next.js

"I published it in the CMS, but the website still shows the old version" sounds simple until you trace the path.

The CMS may have saved correctly. The webhook may have failed. ISR may be serving old output. A CDN may still have the response. Preview may be showing draft content while production is showing published content. A listing page, sitemap or navigation file may depend on a build step rather than route‑level revalidation.

The mistake I try to avoid is repeatedly republishing content, clearing random caches or redeploying the site until the symptom disappears. That might make the editor happy for the moment, but it leaves the system unexplained. The next publish will fail in the same way.

Start with One Controlled Content Change

Do not debug "the CMS is stale". Debug one entry, one field and one expected URL.

Capture:

• CMS entry ID
• content type
• slug or route
• field changed
• publish time
• CMS environment
• locale or market
• editor role
• expected production URL
• preview URL if relevant
• affected page types

Then make one controlled change that is safe to publish and easy to recognise. A temporary sentence in a low‑risk field is better than guessing from an editor's memory of what changed yesterday.

Check whether the new value appears on:

• the detail page
• listing pages
• navigation
• related content modules
• sitemap
• metadata
• structured data
• preview
• API response

A changed article title might update on the article page but remain stale in an index. A product change might appear on the detail page but not in a related‑products module. Those are different route dependencies.

Check the CMS Publish Event

If the site depends on webhooks, inspect delivery before touching Next.js code.

Check:

• webhook fired on publish
• webhook target URL is correct
• environment and branch are correct
• webhook secret is valid
• request returned the expected status
• failed deliveries are retried
• payload includes enough data
• webhook is scoped to the right content types

If the webhook did not fire, the front end may be behaving correctly with old data. If the webhook fired but carried too little context, the site may revalidate the wrong route. If there is no webhook, the site may depend on timed revalidation, scheduled rebuilds or runtime fetching, and editors need to know the delay.

This is the kind of production issue covered by the headless CMS cache and revalidation debugging service: find where the publish path breaks before replacing the whole content stack.

Separate Preview from Production

Preview and production answer different questions.

Preview asks whether an editor can inspect draft or unpublished content safely. Production asks whether public users can see published content after the expected cache path updates.

Check:

• Draft Mode or preview mode is enabled
• preview route sets the expected cookie
• preview bypasses the right cache
• preview works on the production domain
• preview resolves unpublished references
• preview is protected
• published pages do not accidentally use draft data

The Contentful‑specific article on Draft Mode and preview in Next.js covers common iframe, cookie and editor‑flow issues. The wider planning point is covered in why CMS preview belongs in a Next.js migration plan.

Identify the Cache Boundary

The practical question is: where is the stale value stored?

Possibilities include:

• CMS CDN cache
• build‑time data
• generated JSON
• Next.js fetch cache
• App Router route cache
• ISR page cache
• custom in‑memory cache
• Vercel edge or CDN cache
• browser cache
• API response cache
• search index or generated route data

Once you know the boundary, the fix becomes concrete. Without that evidence, teams revalidate everything and hope.

The article on Next.js App Router cache tags and revalidation goes deeper on tag‑based freshness. The official `revalidateTag` documentation is useful for API detail, but tags only help when they match the way content appears across routes.

If the issue is specifically ISR on Vercel, the Vercel and Next.js ISR revalidation debugging service is a better fit than a general CMS review.

Check Route Dependencies, Not Just the Page

Content rarely affects one route.

A single CMS entry may appear on:

• its own detail page
• homepage modules
• category pages
• search indexes
• related article carousels
• service pages
• navigation
• sitemap
• RSS or policy files
• social share metadata

If only the detail route is revalidated, the surrounding site may stay stale. That is not an editor error. It is a dependency map problem.

Build the map around content type, affected routes, affected generated files, listing pages and revalidation mechanism. For small sites, this can be simple. For larger content platforms, it needs to become part of the publishing architecture.

The headless CMS SEO controls matrix is useful here because metadata, canonicals, schema fields and editorial controls often share the same freshness path as the visible page content.

Compare Preview, Production and API Output

Once you have one controlled change, compare the source and every surface that claims to use it.

Check:

• CMS API response
• preview route
• production route
• generated page data
• listing route
• metadata output
• cache headers where relevant
• deployment or runtime logs

The caveat is that stale content is not always a CMS problem. A missing locale, unpublished reference, unsupported rich‑text node, invalid slug, missing image or field renamed in the CMS model can all make an app skip new data or fall back to older output.

That is a data contract problem as much as a cache problem.

Give Editors a Publishing Contract

Editors do not need every implementation detail. They do need to know what the platform promises.

That contract should answer:

• how quickly detail pages update
• how quickly listing pages update
• whether preview shows draft or published content
• what happens for scheduled publishing
• how to report stale content
• which fields trigger wider updates
• when a rebuild is required

If the answer is "ask a developer", the platform is not finished. The headless CMS integration service exists for that kind of operational gap: preview, freshness, metadata and editor trust need to be designed, not patched after every failed publish.

The useful fix is rarely "clear the cache harder". It is making the publish path visible enough that one controlled CMS change can be followed from source entry to rendered page without guesswork.