Most sites never need to think about sitemap index files, because most sites never get close to the limits of a single sitemap. The moment they do — a marketplace with a few hundred thousand listings, a publisher with a decade of archived articles, an e-commerce catalog with regional variants — a single sitemap.xml stops being an option and becomes a liability: it either gets rejected outright or gets crawled inconsistently because crawlers deprioritize oversized files.
The Limits That Force a Split
The sitemaps.org protocol caps a single sitemap file at 50,000 URLs and 50MB uncompressed. Both limits are hard — hit either one and the file is invalid, not just suboptimal. In practice, sites split well before the URL cap, because sitemap files with rich <lastmod>, <image:image>, or <xhtml:link> hreflang data reach the size cap at a much lower URL count than 50,000.
A sitemap index solves this by acting as a manifest: instead of one file listing URLs, it's a file listing other sitemap files, each of which stays under the limits independently.
<?xml version="1.0" encoding="UTF-8"?>
<sitemapindex xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
<sitemap>
<loc>https://example.com/sitemaps/products-1.xml</loc>
<lastmod>2026-08-01</lastmod>
</sitemap>
<sitemap>
<loc>https://example.com/sitemaps/products-2.xml</loc>
<lastmod>2026-08-01</lastmod>
</sitemap>
<sitemap>
<loc>https://example.com/sitemaps/blog.xml</loc>
<lastmod>2026-07-28</lastmod>
</sitemap>
</sitemapindex>
Each referenced file is a standard sitemap, valid on its own, just partitioned by whatever grouping makes sense for the site.
Deciding How to Partition
This is the actual design decision, and it matters more than getting the XML syntax right. Three partitioning strategies cover most cases:
- By content type (products, blog posts, category pages, static pages). This is the most common approach and makes debugging easy — if Search Console flags errors in
sitemap-blog.xml, you immediately know which part of the site to check. - By update frequency. Pages that change daily (product availability, pricing) go in one sitemap, stable pages (about, legal, evergreen guides) in another. This lets you resubmit or ping only the volatile sitemap after a batch update instead of the whole set, which matters at scale since re-crawling a stable sitemap wastes crawl budget without discovering anything new.
- By date range, common for publishers —
articles-2024.xml,articles-2025.xml. This keeps individual files naturally under the size cap as archives grow and makes it trivial to freeze old years as immutable files that never need regenerating.
Content type is the right default unless you have a specific operational reason to prefer one of the others — mixing strategies within the same index (some files by type, others by date) makes the system harder to reason about later without a proportional benefit.
Building the Index Correctly
A few structural rules trip people up:
No nested indexes. A sitemap index can only point to sitemap files, not to other sitemap index files. If your generation pipeline produces enough child sitemaps that you're tempted to index the indexes, you likely need better partitioning (fewer, larger — but still under 50K/50MB — child files) rather than a hierarchy the protocol doesn't support.
Absolute URLs only. Every <loc> — in both the index and its children — must be a fully qualified absolute URL on a domain the sitemap file itself is allowed to reference. A child sitemap hosted at example.com/sitemaps/products-1.xml can only list URLs on example.com (or a subdomain, depending on where the sitemap file itself is served from); cross-domain references are ignored by crawlers as a spam-prevention measure.
lastmod should be honest. Set it to when the sitemap file's contents genuinely changed, not to the current date on every generation run. A lastmod that updates on every build regardless of actual content changes trains crawlers to deprioritize the signal, since it stops correlating with anything real.
Serving and Discovery
Point crawlers at the index the same way you would a single sitemap — reference it in robots.txt:
Sitemap: https://example.com/sitemap-index.xml
You can list multiple sitemap or sitemap-index entries in robots.txt if needed, though for most sites a single index referencing all child sitemaps is cleaner than scattering multiple top-level entries. Verify the directive is present and correctly formatted with the Robots.txt Generator before deploying — a malformed Sitemap: line is silently ignored rather than erroring, so it's easy to ship a robots.txt that looks right but never actually points anywhere.
Submit only the index URL to Search Console and Bing Webmaster Tools; both platforms crawl the index, discover the child sitemaps automatically, and report per-child-file status in their coverage reports, so you retain per-file granularity for debugging without submitting each file manually.
When Not to Bother
If the site is under a few thousand URLs and unlikely to grow past that in the next year or two, a sitemap index is unnecessary complexity. A single well-formed sitemap.xml is easier to generate, debug, and reason about, and splitting prematurely just adds moving parts — multiple files to keep in sync, an index to maintain, more surface area for a partition boundary bug to hide URLs from all sitemaps entirely. Split when you're approaching the actual limits, not preemptively because large sites do it.
For sites that do need to generate either a single sitemap or a full indexed set, the Sitemap Generator handles both cases and produces protocol-valid XML without needing to hand-track the URL and size caps yourself.
Auditing an Existing Index
If you've inherited a sitemap index and aren't sure it's healthy, check each child file individually for the same things you'd check on a single sitemap — valid XML, no more than 50,000 URLs, URLs that return 200 rather than redirects or 404s — and check the index file itself for stale <loc> entries pointing at child sitemaps that no longer exist on the server. A sitemap index that references a deleted child file doesn't error visibly; crawlers just get a 404 on that one file and move on, silently dropping every URL that child sitemap used to contain.