What Is a Sitemap Index? Splitting Big Sitemaps Right

Jul 18, 2026 · SEO Glossary

The XML sitemap protocol has a hard ceiling: 50,000 URLs or 50MB uncompressed per file, whichever you hit first. An e-commerce site with 200,000 product pages can't ship one giant file — the spec forbids it and Google will reject it. The protocol's answer is a second file format that most people never look at until they're forced to. So, what is a sitemap index? It's a sitemap of sitemaps: a parent XML file whose entries point at child sitemap files instead of pages.

What a Sitemap Index File Looks Like

The format mirrors a regular sitemap but swaps <urlset> for <sitemapindex> and <url> for <sitemap>:

<?xml version="1.0" encoding="UTF-8"?><sitemapindex xmlns="http://www.sitemaps.org/schemas/sitemap/0.9"><sitemap><loc>https://example.com/sitemap-products-1.xml</loc><lastmod>2026-08-01</lastmod></sitemap><sitemap><loc>https://example.com/sitemap-blog.xml</loc></sitemap></sitemapindex>

Each <loc> is the URL of a child sitemap. The optional <lastmod> tells crawlers when that child file last changed, which helps them skip re-fetching children that haven't moved. You submit only the index URL to Search Console; Google follows it to the children automatically.

What Is a Sitemap Index For, Beyond the Size Limit?

The 50,000/50MB rule is the reason the format exists, but even mid-sized sites benefit from splitting early. Here's why I set up an index on sites with as few as 5,000 URLs:

• Per-section indexing visibility. Search Console reports indexed-vs-discovered counts per submitted sitemap. One monolithic file tells you "62% of your URLs are indexed" — useless. Split into sitemap-products.xml, sitemap-blog.xml, and sitemap-categories.xml, and you can see that products index at 94% while blog posts sit at 31%, which turns a vague number into a specific investigation.
• Cheaper regeneration. When one product changes, you rebuild one child file, not a 40MB monster.
• Faster recrawl signaling. Updating the lastmod on a single child tells Google exactly which slice of the site to revisit.

Rules the Spec Actually Enforces

1. An index can list up to 50,000 child sitemaps — the same numeric cap as URLs in a regular sitemap. Combined with 50,000 URLs per child, the theoretical ceiling is 2.5 billion URLs. You will not hit it.
2. No nesting. A sitemap index cannot point at another sitemap index. Google rejects nested indexes, so plan a flat, one-level hierarchy.
3. Same-host references. Child sitemaps should live on the same host as the index. Cross-host references only work if the other host proves ownership via robots.txt declaration, and it's rarely worth the complexity.
4. Compression counts against nothing. You can gzip each child (sitemap-products-1.xml.gz); the 50MB limit applies to the uncompressed size.

How to Split: Strategies That Age Well

The spec doesn't care how you partition URLs, but future-you does. Three patterns I've shipped:

By content type

Products, categories, articles, static pages — each type gets its own child (or numbered series of children). This is the default because it maps directly onto how indexing problems present themselves.

By date bucket

News and publisher sites split by month: sitemap-2026-08.xml. Old buckets never change, so their lastmod stays static and crawlers concentrate on the current month's file.

By numeric chunk

Plain pagination — sitemap-1.xml through sitemap-n.xml, filled in ID order. Simplest to generate, worst to debug, because a chunk number tells you nothing about what's inside. Use it only when the other two don't fit.

Whichever pattern you pick, leave headroom in each child. Filling files to exactly 50,000 URLs means the next published page forces a re-partition, which renames files and resets whatever crawl familiarity Google built with the old ones. Capping children at 40,000 or so costs nothing and makes growth boring — the good kind of boring.

Implementation Bugs I Keep Seeing

• The index references children that were never regenerated. A deploy script rebuilds sitemap-products-1.xml but not the index, or vice versa, so lastmod values disagree with the files' actual contents. Regenerate index and children in the same job, atomically.
• Relative or protocol-mismatched child URLs. The spec requires full absolute URLs in <loc>, and an index served over HTTPS pointing at http:// children will trip validation in some consumers and waste redirects in others.
• Children blocked by robots.txt or auth. The index is public but the child files sit in a directory the CDN protects or a Disallow rule covers. Google reports these as "Couldn't fetch", and the affected section silently loses its discovery channel.
• Stale children left behind. After a re-partition, old child files keep being served and keep listing dead URLs. Delete or 404 retired children; Google eventually drops them, but months of crawl requests go to the graveyard first.

Verifying the Whole Tree

A sitemap index adds a failure mode a single file doesn't have: the index can be healthy while a child 404s. Fetch the index, then fetch every child it references, and confirm each returns 200 with valid XML — a loop with curl and xmllint --noout covers it. If you'd rather not script it, point an automated site audit at your domain; it reads the index, walks every child, and cross-references the listed URLs against what the crawl actually found, flagging entries that 404, redirect, or contradict your XML sitemap hygiene rules. In Search Console, submit the index once and check that the child sitemaps appear beneath it with a "Success" status — a child stuck on "Couldn't fetch" for more than a day usually means a firewall or CDN rule is blocking Googlebot from the file.