Next.js Sitemap Not Updating? Debug Cache and CMS Publishing

When a Next.js sitemap is not updating, compare the published CMS records with the XML served at the public sitemap URL. If the CMS response contains the new page but the XML does not, investigate the sitemap route, its data cache and the deployed delivery layer. If the record is missing from the CMS response, fix the publishing query first.

This tutorial includes a downloadable production-mode lab. I tested a fictional catalog locally on 5 October 2026 using Next.js 16.3.8: publishing a second record left the cached sitemap with one URL; invalidating the sitemap and requesting it again exposed both. The exercise also checks modified dates, deletions and draft exclusion. These observations describe the lab, not Google indexing or a client result.

Start with the missing URL, not the whole cache

Choose one recently published page and write down its expected canonical URL, CMS identifier, publication time and deployed environment. Check the page itself in a logged-out browser. A preview route that works for an editor is weak evidence that the production page exists.

Save the response body from the sitemap URL your site actually advertises. Some projects serve an index of several sitemaps, so follow the relevant child sitemap rather than assuming every page belongs in the root XML file. Confirm the hostname, slash policy and slug against the expected URL.

On smaller screens, scroll the table horizontally to read all columns.

Keep the original evidence. Clearing several caches at once may hide the stale response without revealing which layer caused it. A useful bug report contains the missing URL and two captured responses, not just “the sitemap looks wrong.”

Confirm the CMS is returning published records

Run the same query, against the same environment, that the deployed sitemap uses. Compare the record’s status and modification field with the API output. Look for preview tokens, locale filters, collection limits, scheduled publication times and pagination cursors.

A dashboard can show a published document while the production query still reads a different dataset. Another common failure is fetching only the first batch of records: a new page exists, but a default query limit excludes it from the sitemap. Test with enough fictional records to cross that limit before concluding that caching is responsible.

Unpublishing deserves equal attention. A record may remain in a cached query after an editor removes it. Decide which events change your indexable URL set, and document how the sitemap obtains the final published state. For a renamed slug, confirm both the new entry and the old URL’s redirect or removal behavior.

Use a stable canonical origin from trusted configuration. Do not let arbitrary request headers or unvalidated CMS URLs determine the sitemap hostname. Build the basic route correctly first; the Next.js App Router SEO guide covers the broader metadata and sitemap setup.

Identify the cache and deployment you actually have

Next.js documents sitemap.js as a special Route Handler that is cached by default unless request-time APIs or dynamic configuration change that behavior. The details depend on your installed version and configuration. Read the official sitemap reference alongside your project, rather than copying a cache setting from a tutorial for another release.

There can be more than one stale copy. The sitemap route might regenerate while a cached CMS fetch still returns old records. Alternatively, the application can return fresh XML while a proxy keeps serving an older response. Capture the CMS query, application output and public URL separately when your hosting setup allows that comparison.

Record whether Cache Components are enabled and whether the deployment supports runtime regeneration. This lab explicitly sets cacheComponents: false and a one-hour route revalidation interval. Its direct file read avoids an upstream fetch cache, so it isolates sitemap output freshness. Those choices are test conditions, not universal production recommendations.

A static export is a different workflow. It produces files during the build; a CMS publish event must trigger an appropriate rebuild and deployment to replace stale XML. There is no running Next.js server in that exported output to execute a revalidation webhook. Check the static export documentation before designing the fix.

Reproduce stale XML in a production-mode lab

Download the source-only sitemap lab. It includes the fictional catalog, capture script, setup instructions and recorded XML snapshots. Dependencies and build output are excluded. Restore the initial catalog before each build, then run the commands from the lab directory in two terminals.

npm install
npm run build
npm run start

# In a second terminal, from the same directory:
node capture.cjs

The lab sitemap deliberately caches its output. The catalog contains a published alpha record and a draft that must stay excluded. The initial build therefore emits one URL. Here is the complete sitemap function used in this fixture:

import { readCatalog } from '../lib/catalog';

export const revalidate = 3600;

export default async function sitemap() {
  const records = await readCatalog();
  return records
    .filter(record => record.status === 'published')
    .map(record => ({
      url: `https://example.test/blog/${record.slug}/`,
      lastModified: new Date(record.updatedAt),
    }));
}

The capture script publishes beta by changing the local JSON catalog, then compares a fresh catalog API response with the cached sitemap. It does not depend on a CMS vendor, network latency or Googlebot. That makes the disagreement easy to reproduce.

On smaller screens, scroll the table horizontally to read all columns.

The local run passed 22 assertions, including a rejected request to the fixture’s guarded endpoint. Inspect the recorded test results and XML snapshots to see exactly what was checked. This count measures test checks, not SEO improvement.

Connect publishing events to the right invalidation

In this fixture, a local POST handler calls revalidatePath('/sitemap.xml'). Next.js says that calling this function in a Route Handler marks the path for revalidation on its next visit. The script therefore performs a subsequent GET and checks the resulting XML; a successful webhook response alone is insufficient. See the revalidatePath reference for the distinction between Route Handlers and Server Functions.

The demo endpoint accepts only localhost requests with a fixture header. That header is not production authentication. Do not publish the teaching endpoint on the internet. A real integration must validate the CMS provider’s signature or equivalent authorization, validate the event, apply suitable replay controls and handle failures before invalidating anything.

If your sitemap reads a cached fetch or another cached data function, inspect that dependency’s invalidation mechanism as well. Refreshing the XML route while keeping an old published-record list can reproduce the same missing URL. Use the tag or path APIs supported by your version and cache mode; then verify the actual response rather than assuming the API call refreshed every layer.

Wait until the new CMS state is readable before regeneration. A webhook delivered ahead of a query’s updated response can rebuild stale XML successfully. Where necessary, retry after checking the document’s expected revision. Record failed deliveries and make repeated events safe to process.

On a multi-instance deployment, check the hosting adapter’s cache behavior and invalidation propagation. A passing single-process lab does not establish that every deployed instance or CDN location serves the new sitemap.

Test additions, edits, removals and public delivery

Turn the one-page investigation into a release checklist. For each scenario, save the expected URL set, trigger the real publishing workflow and fetch the public sitemap without relying on your browser’s saved response.

1. Add: the new canonical URL appears once; no draft or preview URL appears.
2. Edit: a significant content change updates the appropriate modification value.
3. Unpublish: the record leaves the indexable sitemap set.
4. Rename: the new URL appears and the old URL follows your documented redirect or removal policy.
5. Deploy: the public hostname serves the expected XML, including any child sitemap.
6. Fail: an invalid webhook is rejected, and a legitimate failed delivery is observable and retryable.

A timestamp should come from a meaningful page change, not from the time someone requested the sitemap. Google explains that useful lastmod values must consistently reflect significant updates; sitemap submission remains a hint rather than an indexing guarantee. See its sitemap guidance.

Check your actual deployed page responses too. A listed URL can still redirect unexpectedly, carry noindex or point its canonical elsewhere. The Playwright SEO testing tutorial shows how to make stable route expectations part of a release gate. Use the JavaScript SEO guide when the page itself has rendering or discoverability problems.

If Search Console still shows old sitemap information

Compare the public XML with Search Console’s last read date. A correct response today does not mean Google fetched it immediately after your CMS event. Keep the sitemap available at a stable URL, verify the configured sitemap address and inspect reported fetching or parsing errors.

For the affected page, separate discovery, crawling and indexing. First prove that the current XML contains the right URL. Then check whether Google can fetch the page and what its inspection report says. Avoid repeatedly changing slugs or timestamps to chase an older report; those changes introduce additional variables.

If this spans publishing infrastructure and application code, my front-end development service can help define the failing stage and implement a repeatable publishing test.

Frequently asked questions

Does a hard refresh fix a stale Next.js sitemap?

It can bypass a browser’s saved response, but it does not necessarily refresh the application’s generated XML, a cached CMS query or an external proxy. Compare captured responses to identify the stale layer.

Should I make the sitemap fully dynamic?

Only if that fits your version, traffic and hosting model. A fresh response on every request can add unnecessary work. Reliable event-driven regeneration or an appropriate interval may fit better; test the maximum acceptable publishing delay.

Will fixing the sitemap make the page rank immediately?

No. The fix makes the intended URL available in the current XML. Google still decides whether and when to crawl, index and rank the page, based on more than sitemap inclusion.

Documentation and corrections

Primary documentation checked on 5 October 2026: Next.js sitemap, revalidatePath and static export references; Google Search Central’s sitemap guidance. The links appear beside the relevant claims above. Framework releases, hosting adapters and security products can change these details.

Found a discrepancy? Send a sanitized correction with the affected step, installed version or product, and reproducible evidence.