WordPress sitemap not updating? Find the stale layer
A new page is published. It loads properly. The URL is in WordPress, linked from the relevant service page, and visible to anyone who has the direct address. Yet the public XML sitemap has not moved an inch.
It is a quiet sort of fault, which makes it irritating. Nothing looks broken enough to trigger an alert, but the sitemap available to crawlers can still be an older copy. For a service business relying on timely content updates, that leaves a gap between what WordPress knows and what the outside world receives.
The sitemap generator may be innocent
A WordPress sitemap can be regenerated correctly inside the application while an older XML response is served by a cache further up the chain. That chain may include a WordPress caching plugin, a host-level nginx or Varnish cache, or a CDN edge cache such as Cloudflare. Republishing a post or rebuilding the sitemap may change the source response without changing the cached version requested by visitors and crawlers.
This is why rebuilding the sitemap repeatedly is often busywork. If the public request is not reaching Rank Math, Yoast, WordPress core or whichever generator is in use, rebuilding that generator changes little.
What a stale sitemap incident usually looks like
A fairly ordinary sequence goes like this. A business publishes a new location or service page. The URL is live and its canonical address is correct. Rank Math includes it when the sitemap is checked from within WordPress, but the public sitemap_index.xml response still lists yesterday’s child sitemap or an older post count.
The first instinct is to republish the page, flush the SEO plugin cache, and regenerate the sitemap again. It feels productive. It also risks obscuring the useful part: one request is being served from a different layer than expected.
In one realistic setup, the sitemap was correctly generated after publishing, the host cache was cleared, and the public XML still remained stale. The response headers showed that the CDN was returning a cached object. Purging that sitemap URL and excluding sitemap paths from the relevant edge-cache rule allowed the current response through. Cloudflare was involved in that instance, but it is not the automatic answer for every site.
Surface the response that crawlers receive
Start by checking the public sitemap URL in a private browser window, then inspect its response headers using browser developer tools, a header checker, or a command-line request if you are comfortable doing so. You are looking for clues such as cache status, age, cache-control directives, server identifiers and CDN headers.
The useful question is not merely whether the XML file looks old. It is which system supplied it.
| Layer to inspect | Useful clue | What to verify |
|---|---|---|
| WordPress sitemap generator | The new URL is absent before any cache is involved | Post status, indexing settings, sitemap inclusion rules and generated sitemap output |
| WordPress cache or transients | Regeneration appears delayed inside WordPress | Plugin cache behaviour, object cache and sitemap-related transients |
| Host cache | Headers indicate nginx, Varnish or managed host caching | Whether XML paths are cached and whether a targeted purge works |
| CDN edge cache | Headers show a cache hit, age value or CDN identifier | Cache rules, edge TTL and exclusion rules for sitemap URLs |
Work through the layers in a controlled order
- Confirm the page is genuinely publishable. Check it is public, indexable, not marked noindex, and not excluded by the sitemap plugin’s post-type or taxonomy settings.
- Check the sitemap source. Open the relevant sitemap and confirm whether the URL exists when caching is bypassed or after a controlled application-level refresh.
- Inspect WordPress caching. Clear only the relevant cache where possible. Object caching and transients can matter, particularly on sites with several optimisation tools bolted together over time.
- Check the host response. Managed hosts may cache XML files separately from normal page cache rules. A homepage purge does not necessarily clear a sitemap response.
- Check the CDN last. Review whether sitemap paths such as sitemap_index.xml and child sitemap XML files are eligible for edge caching. Purge the affected URLs, then consider an exclusion rule if the cache policy is the cause.
- Retest the exact public URL. Compare the XML content and headers after each single change. Otherwise, you will not know what fixed it.
Why sitemap paths deserve their own cache rule
Most cache rules are designed around HTML pages, images and static assets. XML sitemaps sit in an awkward middle ground: they are generated content, but they are requested like a static file. A broad cache-everything rule can catch them accidentally.
Sitemaps do not normally need aggressive edge caching. They need to be available, current enough for the publishing pattern, and served consistently. If a business publishes once a quarter, a different policy may be reasonable than for a content-heavy site adding URLs every day. The important bit is that the rule is deliberate.
For ongoing investigations involving cache behaviour, sitemap checks and publishing reliability, WordPress website maintenance in Dubai provides a practical route for reviewing the moving parts without treating every stale XML file as an emergency.
Do not use Search Console as the first diagnostic tool
Search Console can show when Google last read a sitemap, but it does not identify the cache layer currently serving an old response. First establish what the sitemap URL returns publicly. Once that is correct, crawl and index reporting becomes more useful for confirming that the updated file can be collected over time.
There is also no need to keep submitting the same sitemap after every cache purge. Fix the response being served, confirm it, then let normal crawling do its job unless there is a separate indexing issue.
A small maintenance detail that saves a daft amount of time
Keep a record of which cache layers exist on the site and who controls each one. WordPress admin access may cover the plugin cache but not the host dashboard or CDN account. When a marketing team cannot see a new URL in the sitemap, that ownership gap turns a ten-minute check into an afternoon of screenshots and guesses.
Trace which layer is serving the stale sitemap before repeatedly rebuilding it. If you need help separating the sitemap generator from the cache response, message Standish Services on WhatsApp about the stale sitemap.
Why is my WordPress sitemap stale after publishing?
The page may be published correctly, but the public sitemap response can still be held in a WordPress cache, host cache or CDN edge cache. Check whether the URL is eligible for sitemap inclusion first, then inspect the headers and content returned by the public XML sitemap before regenerating it again.
Which cache layer should be checked first?
Begin with the sitemap generator and WordPress-level cache because they are closest to the content change. Then inspect host caching and CDN headers. The order matters because it helps establish whether the stale content originates in WordPress or is being served by an upstream layer that never requested the new sitemap in the first place.