CMS Content Not Updating in Next.js

"I published it in the CMS, but the website still shows the old version" is a deceptively complicated bug report.

It might be a CMS webhook problem. It might be ISR. It might be App Router cache behaviour. It might be a preview cookie. It might be a CDN cache. It might be the editor looking at the wrong environment. It might even be that the page updated correctly, but a related listing, sitemap, or navigation item did not.

The worst response is to randomly redeploy until the content changes. That may clear the symptom, but it does not explain the system.

Content publishing needs a reliable path from CMS change to rendered page. If that path is not understood, editors lose trust and developers end up babysitting releases.

Start with the Exact Content Change

Do not debug "the CMS is stale". Debug one entry.

Capture:

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

Then confirm whether the stale content appears on:

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

A changed article title might update on the article page but stay stale in an articles index. A product price might update on the product detail page but remain stale in a related products module. Those are different cache paths.

Check Whether the CMS Publish Event Fired

If the site depends on webhooks, inspect the webhook delivery.

Check:

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

If the webhook failed, the front‑end may be behaving correctly with old data. The fix might be CMS configuration, not Next.js.

If there is no webhook, the site may depend on timed revalidation, redeploys, or runtime fetching. That can be fine, but editors need to know the expected delay.

Separate Preview from Published Content

Preview and production are different flows.

Preview asks: can an editor see draft or unpublished content safely? Production asks: can public users 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 broader migration point is covered in why CMS preview belongs in a Next.js migration plan.

Identify the Cache Boundary

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

Possibilities include:

• CMS CDN cache
• local build‑time data
• generated JSON file
• 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 derived data file

Once you know the cache boundary, the fix becomes more concrete. Without that, teams tend to revalidate everything and hope.

The article on Next.js App Router cache tags and revalidation is the deeper version of this problem. The official `revalidateTag` documentation is useful for the API detail, but cache tags only work well if the tag model matches how content appears across routes.

Check Whether the Right Paths are Revalidated

Content rarely affects only one page.

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 path is revalidated, the surrounding site may stay stale.

Build a dependency map:

• content type
• affected routes
• affected generated files
• affected listings
• revalidation mechanism

For small sites, that map can be simple. For larger content platforms, it needs to be a real part of the publishing architecture.

Check Derived Data and Generated Files

Some stale‑content issues have nothing to do with the rendered page cache.

The site may generate:

• valid route lists
• sitemaps
• article indexes
• search data
• image metadata
• AI policy files
• redirects
• category pages
• related content maps

If those are generated only during build, a CMS publish may not update them until the next rebuild. That can be correct, but it should be intentional.

This distinction matters on sites where daily builds pull scheduled content into generated assets. Redis or API caching can reduce repeated CMS reads, but it does not replace a rebuild when generated outputs need to change.

Check Production Data Assumptions

Sometimes content does not update because new content does not pass the app's assumptions.

Examples:

• required image missing
• slug invalid
• related entry unpublished
• category not recognised
• date outside expected range
• rich text contains unsupported node
• field renamed in CMS model
• locale missing
• preview‑only entry referenced by public page

In that case, the page may fall back to old data, skip the entry, or fail quietly depending on the implementation. This is a data contract problem as much as a cache problem.

Give Editors a Clear Expectation

Editors do not need to understand every cache layer. They do need a reliable publishing contract.

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
• what fields trigger wider updates
• when a rebuild is required

If the answer is "ask a developer", the platform is not finished.

Wrapping Up

When CMS content does not update in Next.js, the visible problem is stale copy. The real problem is usually an unclear publishing path.

Debug one entry, find the cache boundary, inspect webhook delivery, separate preview from production, map affected routes, and check generated data. Once the path is visible, the fix is usually straightforward.

Editors need trust. Developers need a system they can reason about. A good publishing architecture gives both.

Key Takeaways

• Debug one CMS entry and one route before generalising.
• Check webhook delivery before changing Next.js code.
• Separate preview freshness from published‑page freshness.
• Identify where the stale value is cached.
• Revalidate every route and generated surface the content affects.
• Give editors a clear publishing expectation instead of ad hoc redeploys.