Sitemap Index Files: When and How to Use Them
One file that lists your other sitemaps: the index is simple, but the rules about nesting, hosts and submission trip people up.
A sitemap index is an XML file that lists other sitemap files instead of pages. You need one when a single sitemap would exceed 50,000 URLs or 50 MB uncompressed, and you probably want one earlier, to segment a site by content type. Crawlers read the index, then fetch each child sitemap it references.
The structure
An index looks like a sitemap with two substitutions: the root element is <sitemapindex>, and entries are <sitemap> elements pointing at sitemap files:
<?xml version="1.0" encoding="UTF-8"?>
<sitemapindex xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
<sitemap>
<loc>https://example.com/sitemap-posts.xml</loc>
<lastmod>2026-07-16</lastmod>
</sitemap>
<sitemap>
<loc>https://example.com/sitemap-products.xml</loc>
<lastmod>2026-07-02</lastmod>
</sitemap>
</sitemapindex>Each entry allows exactly two elements: a required <loc> and an optional <lastmod>. No changefreq, no priority. The namespace is the same one ordinary sitemaps use.
The rules that matter
- Capacity. An index may list up to 50,000 sitemaps and must stay under 50 MB itself. With full children, that is 2.5 billion URLs, enough for anyone.
- No nesting. An index must reference sitemaps, not other index files. One level, no deeper. Nested indexes are the most common structural mistake on very large sites, and crawlers refuse to follow them.
- Same host. Child sitemaps should live on the same host as the index, subject to the usual cross-host exception via robots.txt.
- Child lastmod. The lastmod on each entry should record when that child file last changed. Accurate values let crawlers skip unchanged children and spend their fetches on the segment that actually updated.
When to split, and how
| Situation | Recommended split |
|---|---|
| Approaching 50,000 URLs | Numbered parts: sitemap-1.xml, sitemap-2.xml |
| Mixed content site | By type: posts, pages, products, categories |
| Multilingual site | By language or region |
| News or frequently updated site | By date, with a small "latest" sitemap that changes often |
| Debugging indexing problems | By template, so coverage reports isolate the culprit |
Segmenting has a diagnostic payoff beyond the limits: Google Search Console reports coverage per sitemap, so "products indexed at 60%, posts at 98%" becomes visible the moment you split by type.
Submission
Submit only the index in Search Console and Bing Webmaster Tools, and reference only the index from robots.txt. The children are discovered through it automatically, and their statistics still show up individually. Submitting children separately does not break anything, but it clutters reporting and doubles the URLs you have to keep stable.
Common index mistakes
- Wrapping page URLs in
<sitemap>entries. Pages belong in child sitemaps; the index lists files only. - Using
<urlset>as the root with sitemap children, or<sitemapindex>with url children. The root element and entry type must match. - Referencing children that 404 or redirect. Every loc in the index is a promise; a validator that fetches children, like ours, catches this immediately.
- Forgetting to update the index after adding a child file. The new sitemap exists but nothing points to it.
- Stamping all children with the same lastmod on every build, which tells crawlers nothing.
Paste an index into the sitemap validator and it validates the index structure first, then lists every child with a one-click check for each, so you can walk the whole tree without leaving the page.