Sitemap Index

A sitemap index is a special XML file that lists other sitemap files instead of listing individual page URLs. An ordinary XML sitemap enumerates the pages you want search engines to know about — each URL, optionally with a last-modified date. A sitemap index sits one level above that. Its entries are not pages but the addresses of your separate sitemap files, each wrapped in a sitemap element with a location. You submit the single index to a search engine, and it fetches every sitemap the index names. The structure is deliberately shallow. An index points to sitemaps, and those sitemaps point to pages — two levels, no deeper. A sitemap index may not point to another index, so the hierarchy stops there. Think of it as a table of contents for your sitemaps, a single door behind which all the individual maps are filed.

The reason sitemap indexes exist is a hard limit. A single XML sitemap can hold at most fifty thousand URLs and must stay under fifty megabytes uncompressed. A large e-commerce catalog, news archive, or listings site can blow past that easily. Rather than cram everything into one oversized, invalid file, you split the URLs across many compliant sitemaps and list them all in one index. A single index can reference up to fifty thousand sitemaps, so the ceiling becomes enormous. Beyond raw scale, the split brings order. You can group sitemaps by section — products, categories, blog, images — which makes coverage easier to reason about and lets you see, in a search console, which group has indexing problems. For any site past a few tens of thousands of URLs, an index is not optional bookkeeping but the correct, standard way to organize sitemaps.

The distinction is simple but worth stating plainly, because the two files look similar and are easy to confuse. A plain sitemap lists page URLs — the actual addresses you want crawled and indexed. A sitemap index lists sitemaps — the addresses of those URL files. In XML, a sitemap uses url and loc elements for pages, while an index uses sitemap and loc elements for other sitemaps. A small site with a few hundred pages needs only a single plain sitemap and no index at all. You reach for an index only once your URLs outgrow one file, or once you want to split coverage into logical groups for easier management. Using an index where a single sitemap would do adds needless plumbing. Skipping an index when you have hundreds of thousands of URLs forces invalid, oversized files. Match the tool to the scale.

Splitting sitemaps under an index also sharpens diagnosis. Because search consoles report indexing status per submitted sitemap, grouping your URLs — one sitemap for products, one for editorial, one for images — lets you spot exactly where coverage breaks. If the products sitemap shows thousands of pages submitted but few indexed, the problem is scoped to the catalog, not the whole site. That granularity is hard to get from a single monolithic file. Two rules keep an index reliable. Every sitemap it references must be a valid, live file at the stated location, or you strand URLs behind a dead link. And the index must not reference another index, since the specification allows only the two-level structure. Keep the index current as sections grow, prune sitemaps for pages you have removed, and the whole arrangement stays a trustworthy map of the site.

Use a sitemap index whenever your site has more URLs than a single fifty-thousand-URL sitemap can hold, or whenever splitting coverage into named groups makes the site easier to manage. Generate the index and its child sitemaps automatically from your content system so they stay in step as pages are added and removed, since hand-maintained sitemaps rot quickly on a large site. Reference the index in your robots.txt file and submit it in the search console, so engines discover every child sitemap from one entry point. Keep each child sitemap valid and under the size and URL limits, and organize them by section so a coverage report tells you something actionable. Include accurate last-modified dates where you can, since they help engines prioritize recrawling changed pages. Treated as living infrastructure rather than a set-and-forget file, an index scales cleanly to millions of URLs.

The failures cluster around neglect and misuse. Pointing an index at sitemaps that no longer exist strands whole sections behind dead links. Nesting an index inside another index breaks the specification and can cause engines to ignore it. Letting sitemaps go stale — listing deleted pages or missing new ones — feeds crawlers a wrong map and wastes crawl budget. Building one bloated file instead of splitting under an index yields an oversized, invalid sitemap that may be rejected outright. And forgetting to reference or submit the index means engines may never find the child sitemaps at all. The discipline is to generate the index and its sitemaps automatically, keep every referenced file valid and current, respect the two-level limit, and submit the index so the whole structure is discoverable.

A sitemap index extends the Sitemaps XML protocol, introduced by Google in 2005 and adopted by major search engines, adding a file that lists other sitemaps for large sites.

Etymology: source.

Search interest for this term over the last five years:

View interest-over-time on Google Trends →

Areas of marketing where sitemap index is a core concern: