Sitemap Best Practices for Large WordPress Sites

Large WooCommerce catalogs and high-volume publishers generate a specific flavor of support ticket: “Google isn’t indexing most of my products” or “half my archive isn’t showing up in Search Console at all,” sent in by someone who’s confirmed the sitemap technically exists. Usually it does exist. It’s just carrying the wrong information, or too much of the wrong information, for Google to treat it as a trustworthy map of the site.

The Limits You’re Actually Working Within

Google’s own documentation caps a single sitemap file at 50,000 URLs and 50MB uncompressed. Past that, you split into multiple sitemap files and connect them through a sitemap index file, which itself can reference up to 50,000 individual sitemaps — a theoretical ceiling around 2.5 billion URLs. That number is a ceiling, not a target. Nobody should be trying to fill it.

Segment by Content Type, Not Just by Count

The best practice on large sites isn’t just splitting once you hit 50,000 — it’s segmenting by content type well before you’re forced to. Products, blog posts, categories and tags, and static pages each belong in their own sub-sitemap. The value isn’t just organizational; it’s diagnostic. Google Search Console’s sitemap report shows indexing rate per submitted sitemap file, so a segmented setup tells you “products are indexing fine, but the tag archive sitemap is stuck at 20%” instead of one blended number that hides exactly where the problem is.

Some technical SEOs go further and recommend capping individual files well under the 50,000 limit — a number like 10,000 URLs per file comes up often in practitioner writing — purely to keep that per-file diagnostic granularity useful in Search Console’s reporting UI. That’s a practical convention rather than a rule Google enforces or processes differently, and I’d treat it as a reasonable default rather than a hard requirement.

What Shouldn’t Be in There at All

A sitemap should only list URLs you actually want indexed: 200-status, canonical, not noindexed, not blocked by robots.txt. On large WooCommerce catalogs specifically, the most common source of accidental bloat is attribute and filter combination URLs — color-and-size variant permutations, faceted filter states — leaking into the sitemap because a product feed or theme template generated them without anyone deciding they belonged there. On publisher sites, it’s usually thin tag archives and paginated duplicate pages doing the same thing.

• Exclude redirected and 404’d URLs — a sitemap referencing dead or moved URLs actively signals that the file isn’t being maintained.
• Exclude paginated archive duplicates and filtered/faceted variants.
• Exclude thin or auto-generated taxonomy pages with little unique content.
• Compress with gzip where your setup supports it — search engines accept uncompressed files, but compression cuts bandwidth and processing time on large files.

lastmod Is Doing More Work Than Priority or changefreq

Google’s own sitemap guidance has been consistent that the <priority> and <changefreq> tags are effectively ignored in how it prioritizes crawling today, despite still being valid sitemap protocol fields that plenty of plugins continue to output by default. <lastmod> is the field Google has indicated it still pays attention to as a freshness signal — but only when it’s trustworthy. A sitemap that stamps every single URL with the current date on every deploy, regardless of whether the content actually changed, trains Google to discount that field for the whole site rather than use it to prioritize recrawls of what genuinely updated.

How Often to Regenerate, and Whether to Ping

On a large catalog, sitemap freshness matters more than the exact regeneration schedule you pick. Most WordPress sitemap tools, including Rank Math’s, regenerate dynamically on request rather than as a static file rebuilt on a cron job, which means the sitemap reflects the current state of the database the moment it’s requested rather than lagging behind a nightly build. Pinging Google directly after a large batch of changes — a bulk product import, a big taxonomy restructure — can nudge a faster recrawl, but it’s a minor accelerant, not a substitute for the sitemap itself being accurate. Submitting the same sitemap index URL once in Search Console is normally enough; Google recrawls sitemaps on its own schedule after that, and repeated manual resubmission doesn’t meaningfully speed things up beyond the occasional post-bulk-change ping.

A sitemap isn’t a crawl-budget hack — it’s a map of what you’re vouching for as worth indexing, and the moment it includes noise, Google starts trusting the whole document a little less.

Sitemap hygiene isn’t a one-time setup task on a large site — it’s ongoing maintenance that has to scale with the catalog or publishing volume. The sites that struggle with indexing at scale usually aren’t missing a sitemap; they’re carrying one that quietly stopped reflecting what the site actually wants indexed months or years ago.