A Rank Math XML sitemap goes stale after a publishing session, not because the plugin failed to generate it, but because Rank Math serves that sitemap from a cached copy and nothing told it to rebuild. Posts created straight through the WordPress REST API are the most common trigger: they publish correctly, they’re live and readable, and they simply don’t show up in post-sitemap.xml until something forces the cache to regenerate. Here’s how we diagnosed that on this site, what didn’t fix it, and what did.
The symptom
Over the course of a month, this site published well over a hundred posts, but post-sitemap.xml kept listing only nine URLs. Every missing post was live, returned a normal 200 response, and was fully readable — the sitemap file itself was simply frozen at whatever it looked like the last time something had forced it to rebuild. That split — content is correct, sitemap is stale — is the signature of a caching problem rather than a publishing problem, and it’s worth checking for before you assume a post failed to save correctly.
Why the cache doesn’t invalidate on its own
Rank Math stores its generated sitemap behind an internal cache rather than rebuilding the XML from the database on every request — sensible for a site with thousands of URLs, since recomputing the full sitemap tree on every crawler hit would be wasteful. The trouble is that the normal editorial actions in wp-admin (the Publish button, Quick Edit, bulk actions) fire WordPress hooks that Rank Math listens for to know when to invalidate that cache. A post created by posting directly to /wp-json/wp/v2/posts still fires the standard save_post and transition_post_status actions under the hood, but on a site with aggressive page or object caching layered on top — a CDN, a server-level cache, a caching plugin — the sitemap URL itself can keep being served from that cache even after Rank Math’s own copy is current. Rank Math’s own documentation lists common culprits for a stale sitemap: page-caching plugins such as WP Rocket or LiteSpeed Cache, a CDN like Cloudflare caching sitemap.xml at the edge, and the browser’s own cache making a current file look old.
What doesn’t reliably fix it
Two instincts people reach for first don’t actually force a rebuild, and wasted time on them is wasted time you don’t get back during a bulk-publishing push:
- Re-saving a settings page without changing a value. Clicking “Save Changes” on Sitemap Settings with nothing edited does not reliably trigger regeneration — the value has to actually change for WordPress to fire the update hook Rank Math listens for.
- Waiting. There’s no background cron in a stock Rank Math install that periodically rebuilds the sitemap on a schedule; if nothing fires the invalidation, the cached copy can sit there indefinitely.
The fix that actually forces regeneration
Rank Math’s own support guidance confirms the reliable trigger is changing an actual sitemap setting value and saving it — not just visiting the settings screen. The field most people use for this is Links Per Sitemap (labeled “items per page” in some Rank Math versions), under Rank Math SEO → Sitemap Settings:
- Open Sitemap Settings and note the current value of Links Per Sitemap.
- Change it to a different number (for example, from 200 to 190), using the field’s native increment controls so the change registers as a real input event, not just a displayed value.
- Click Save Changes.
- Re-fetch
post-sitemap.xmlwith caching disabled (cache: "no-store"if you’re checking programmatically, or a private browser window if checking by eye) and confirm the new posts appear. - If they still don’t appear, repeat with a second value change — toggling back and forth between two numbers is a reliable way to force a fresh rebuild every time without leaving the setting on an arbitrary value.
If a caching plugin or CDN sits in front of the site, that layer needs its own purge after this step, or it will keep serving its own stale copy of the sitemap URL regardless of what Rank Math just rebuilt internally. On a site running Elementor for page building and WP Rocket for page caching, the order matters: clear the page-builder cache first, then the page cache, since clearing them in the opposite order can let a stale Elementor render get swept back into the freshly cleared page cache.
A verification checklist for every bulk-publishing session
The failure described above went unnoticed for a month precisely because nobody checked the sitemap after publishing — the posts themselves looked fine. Run this after any session that publishes more than a couple of posts programmatically:
- Fetch
post-sitemap.xmlwith caching disabled and confirm today’s slugs are present by name, not just that the file “looks recent.” - Check the
<lastmod>timestamp on the sitemap index itself, not just a sub-sitemap — an index that hasn’t updated means something upstream of individual post caching is stale. - If any slug is missing, force regeneration with the Links Per Sitemap toggle above before assuming a post failed to publish.
- Purge any page cache or CDN layer in front of the site, in the correct order for your stack, after confirming Rank Math’s own copy is current.
- Spot-check that a newly published post is both indexable (not accidentally set to noindex) and in an included post type — a post can be perfectly live and still be deliberately excluded from the sitemap by a setting rather than a bug.
That last check matters because a missing-from-sitemap post has two very different root causes that look identical from the outside: a stale cache, or a configuration that’s correctly excluding the post on purpose. Confirming the post type and noindex status rules out the second before you spend time chasing the first.
Every caching layer that can be hiding the real sitemap
Rank Math’s internal cache is only the first of up to four layers a request to sitemap.xml can pass through on a typical managed-hosting setup, and each one needs its own, different purge action:
| Layer | What it caches | How to exclude or purge it |
|---|---|---|
| Rank Math’s internal sitemap cache | The generated XML itself | Force regeneration via the Links Per Sitemap toggle described above |
| Page-caching plugin (WP Rocket, LiteSpeed Cache, WP Super Cache, W3 Total Cache) | The full HTTP response for the sitemap URL | Add the sitemap URL pattern to that plugin’s cache-exclusion list, then purge |
| CDN edge cache (Cloudflare and similar) | A copy of the response stored at the edge, independent of what origin now serves | Purge the specific URL, or set a page rule bypassing cache for sitemap paths |
| Browser cache (yours, while checking) | The last response your own browser fetched | Use a private window or an explicit cache: "no-store" fetch when verifying |
The reason this is worth mapping out explicitly rather than just “clearing the cache” is that clearing only one layer and declaring victory is how the same issue resurfaces a week later: if the CDN is still holding an edge copy, Rank Math can regenerate a perfectly correct sitemap internally and visitors — and crawlers — will still be served the old one until that specific layer is purged too.
Why this matters beyond the sitemap file itself
A sitemap that’s missing recent URLs doesn’t just mean Google discovers them a little later — at volume, it compounds. If a crawler keeps fetching the same sitemap and keeps finding the same nine URLs, it has no fresh signal to recrawl, and newer pages rely entirely on being discovered some other way, such as internal links or Instant Indexing requests. That’s a different problem from the one covered in our checklist for auditing against Google’s Scaled Content Abuse policy — that one is about whether content deserves to rank, this one is about whether Google even knows it exists yet — but the two compound badly together: a high-volume publishing schedule with a broken sitemap looks, from Google’s side, like a site that occasionally produces a handful of pages, not one still producing the rest.
The same programmatic-publishing gap can show up in structured data, too. If you’re setting Rank Math’s schema fields through its REST endpoint rather than the block editor UI, it’s worth separately confirming the Article schema actually validates the way our walkthrough of Rank Math’s Article schema describes, since a missing field there fails just as silently as a stale sitemap does — nothing errors, the schema is just incomplete.
Worth distinguishing from all of this: an llms.txt file and a sitemap solve different problems for different consumers. A sitemap tells search crawlers which URLs exist and roughly how they’re organized; llms.txt, covered in our look at what that spec actually requires, is a much newer, unofficial convention aimed at AI systems reading a site directly, and Google’s own John Mueller has said directly that it doesn’t currently use it for standard Search or AI Overviews. Fixing a broken sitemap doesn’t substitute for either, and neither substitutes for the other.
Finally, if part of your indexing strategy depends on blocking certain crawlers while allowing others — AI training crawlers but not search crawlers, for instance — make sure that configuration isn’t accidentally scoped to catch your sitemap URL too. Our comparison of robots.txt, meta robots, and X-Robots-Tag covers how those three mechanisms differ, and a rule written broadly enough can block a crawler from the sitemap file itself, which produces the same symptom — “posts aren’t showing up” — for a completely different reason than the caching issue this article covers.
