What Is a Sitemap Index File?
A sitemap index file is a special XML file that lists other sitemap files instead of listing individual URLs. Large websites use it because a single XML sitemap is capped at 50,000 URLs or 50MB uncompressed, so bigger sites split their URLs across multiple sitemaps and reference them all from one index. You submit the index to search engines, and they read it to discover every child sitemap and, through them, every page. It acts as a table of contents that points to the sitemaps holding your actual URLs.
- What it is
- An XML file that lists other sitemaps rather than individual page URLs
- Why it exists
- A single sitemap is limited to 50,000 URLs or 50MB uncompressed (sitemaps.org)
- Child sitemap limit
- Each listed sitemap also holds up to 50,000 URLs (Google Search Central)
- Index capacity
- One index can reference up to 50,000 sitemaps (sitemaps.org)
- How to use it
- Submit the index URL to Search Console and list it in robots.txt
What a sitemap index actually is #
A sitemap index file is an XML file whose job is to list other sitemap files rather than individual page URLs. Think of it as a table of contents for your sitemaps: instead of pointing search engines at thousands of pages directly, it points them at several smaller sitemaps, each of which then lists the actual URLs. This structure exists because the sitemap format has hard limits, and large sites bump into them. You submit the single index file to a search engine, and it crawls through to discover every child sitemap and, from there, every page you want indexed. The index uses a specific XML format with sitemapindex and sitemap tags rather than the urlset and url tags of a regular sitemap. For a small site an index is unnecessary, but for a big store, publisher, or directory it is the standard way to organize discovery. Making sure search engines can find and crawl all your pages efficiently is a core part of the technical work on our /services/seo-services page.
Why size limits make it necessary #
The sitemap index exists because a single XML sitemap cannot hold everything on a large site. The Sitemaps protocol caps one sitemap file at 50,000 URLs and 50MB uncompressed (sitemaps.org). A site with hundreds of thousands of pages, common for e-commerce catalogs, large blogs, and directories, would blow past that limit in one file, so it must split URLs across many sitemaps. The index then ties them together so you can submit just one URL and have search engines discover all of them. Without an index, you would have to submit dozens of separate sitemaps manually, which is fragile and easy to get wrong.
<?xml version="1.0" encoding="UTF-8"?>
<sitemapindex xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
<sitemap>
<loc>https://example.com/sitemap-products.xml</loc>
<lastmod>2026-07-10</lastmod>
</sitemap>
<sitemap>
<loc>https://example.com/sitemap-blog.xml</loc>
<lastmod>2026-07-08</lastmod>
</sitemap>
</sitemapindex>How the index and child sitemaps relate #
The relationship is a simple two-level hierarchy. At the top sits the index file, containing a list of sitemap entries, each pointing to the location of a child sitemap and optionally noting when it was last modified. Below it sit the child sitemaps, ordinary XML sitemaps that each list up to 50,000 individual URLs with their own metadata like last-modified dates. A search engine fetches the index, reads each child sitemap location, then fetches those to collect the real page URLs. You can nest logically, but the protocol does not allow an index to point to another index; an index references only regular sitemaps, one level deep. This keeps the structure predictable for crawlers. Organizing which URLs go into which child sitemap is where you gain useful control, since you can group pages by type or section. That organization also makes it far easier to spot crawl and indexing problems, which pairs well with checking your site for broken destinations using our /tools/broken-link-checker before search engines waste crawl budget on dead URLs.
Organizing sitemaps by content type #
One of the practical benefits of using an index is that it lets you split your URLs into logical child sitemaps, and how you group them can help you manage a large site. A common pattern is to separate by content type: one sitemap for product pages, one for blog posts, one for category pages, one for static pages, and perhaps separate ones for images or videos. This makes each sitemap easier to read and gives you clearer signals in Search Console, where indexing status is often reported per submitted sitemap. If your product sitemap shows many pages excluded while your blog sitemap is fully indexed, you have immediately narrowed where the problem lies. For local and multi-location businesses, you might group by region or service area, which complements the structured approach on our /services/local-seo page. The key is a grouping that mirrors how your site is organized, so that when something goes wrong, the sitemap structure itself points you toward the affected section rather than forcing you to search the whole site.
How to submit a sitemap index #
Submitting a sitemap index is straightforward and mirrors submitting a normal sitemap, which is one of its conveniences: you provide one URL and search engines handle the rest. In Google Search Console, you add the index file's URL under the Sitemaps report, and Google then reads the index, discovers every child sitemap, and processes them, showing status for each. You should also declare the index in your robots.txt file with a Sitemap directive, so any crawler that reads robots.txt can find it without manual submission. Use the full, absolute URL of the index, keep it accessible at a stable location, and make sure it returns a 200 status and valid XML. Do not submit each child sitemap separately as well; submitting the index alone is enough and avoids duplication. After submission, monitor the report over the following days to confirm the child sitemaps are being read and pages discovered. Getting these technical signals right is exactly the kind of foundation our /services/seo-services page puts in place so search engines crawl the site efficiently.
Keeping sitemaps accurate and fresh #
A sitemap index is only useful if the sitemaps it points to stay accurate. As you add, remove, and update pages, the child sitemaps should update too, ideally automatically, so they always reflect the site's current URLs. Stale sitemaps that list deleted pages or miss new ones waste crawl budget and send mixed signals. Most content management systems and SEO plugins generate and maintain the index and child sitemaps for you, updating them as content changes and adding accurate last-modified dates, which help search engines prioritize what to recrawl. You should periodically validate that the XML is well-formed and that URLs return the correct status codes rather than errors or redirects, since a sitemap full of broken or redirecting URLs undermines trust in the whole set. Validating structured files and catching errors before they hurt crawling is the sort of check our /tools/schema-validator supports for other markup, and the same discipline applies to sitemaps: keep them clean, current, and honest about which pages truly exist and should be indexed.
Common sitemap index mistakes #
Several avoidable errors trip up large sites. Pointing an index at another index is not allowed and will not work, since the protocol permits only one level. Exceeding the 50,000-URL or 50MB limit inside a single child sitemap causes it to be rejected or truncated, so splitting further is required. Listing non-canonical, redirected, blocked, or 404 URLs in child sitemaps wastes crawl budget and confuses indexing; sitemaps should contain only final, indexable URLs. Forgetting to update sitemaps as content changes leaves them stale. Using relative instead of absolute URLs, or mixing http and https or www and non-www inconsistently, causes discovery problems. Submitting both the index and every child sitemap separately creates needless duplication. Finally, blocking the sitemap files in robots.txt by accident hides them from crawlers entirely. Each mistake quietly reduces how completely and efficiently your pages get discovered. Auditing for these issues is part of a thorough technical review, and a /free-website-audit will flag sitemap and crawlability problems alongside the other factors affecting your search visibility.
Sitemaps and crawl budget #
On large sites, a clean sitemap structure helps search engines spend their crawl budget wisely. Crawl budget is the finite attention a search engine gives your site, and if crawlers waste it fetching redirected, duplicate, or dead URLs, they may reach your important pages more slowly. An accurate index that points only to sitemaps of final, canonical URLs guides crawlers straight to the content you want indexed, rather than sending them down blind alleys. Keeping last-modified dates honest also helps search engines prioritize recrawling pages that actually changed, instead of re-fetching everything. This efficiency matters more the bigger your site grows, since a small blog is crawled easily but a hundred-thousand-page catalog benefits from every signal that focuses attention. Pairing tidy sitemaps with clean internal linking and few broken URLs compounds the benefit, which is why crawl efficiency is part of the technical foundation our /services/seo-services page builds, ensuring the pages that drive revenue are discovered and refreshed promptly rather than buried behind wasted crawling on pages that do not matter.
When you actually need an index #
Not every site needs a sitemap index, and adding one to a small site brings complexity without benefit. If your website has well under 50,000 URLs, a single XML sitemap is perfectly sufficient and simpler to manage, so an index is unnecessary. You genuinely need an index once your total URLs approach or exceed the per-sitemap limit, or when you want to organize a large site into logical, separately monitored sitemaps even before hitting the cap. Big e-commerce catalogs, news and publishing sites, large directories, and multi-location businesses are the typical candidates. The good news is that most modern platforms and SEO plugins automatically switch to an index structure once your URL count grows, so you often get it without manual work. The practical rule is to let your platform handle it, verify the index and its children are valid and submitted, and only intervene if you see discovery problems. If you are running a large or growing site and unsure whether your sitemap setup scales, the technical audit on our /services/seo-services page reviews exactly that.
FAQ
What is a sitemap index file?
It is an XML file that lists other sitemap files rather than individual page URLs, acting as a table of contents for your sitemaps. Large sites use it because a single sitemap is capped at 50,000 URLs, so they split URLs across multiple sitemaps and reference them all from one index that they submit to search engines.
When do I need a sitemap index?
You need one when your site has more URLs than a single sitemap can hold, since one sitemap is limited to 50,000 URLs or 50MB uncompressed. Large e-commerce catalogs, publishers, and directories are typical cases. Sites well under that limit can use a single sitemap, and most platforms switch to an index automatically as you grow.
Can a sitemap index point to another sitemap index?
No. The Sitemaps protocol allows only one level of nesting: an index file can reference regular sitemaps but not other index files. If you have enough URLs to need multiple indexes, that usually signals a structural problem to solve differently, since one index can already reference up to 50,000 individual sitemaps.
How many URLs can a sitemap hold?
Each individual XML sitemap can hold up to 50,000 URLs and must not exceed 50MB uncompressed. A sitemap index can list up to 50,000 sitemaps, so in theory the structure scales to billions of URLs. When a child sitemap approaches the limit, you split its URLs into additional sitemaps and list them in the index.
How do I submit a sitemap index to Google?
Add the index file's full URL in Google Search Console under the Sitemaps report, and Google will read it, discover every child sitemap, and process them. Also declare the index in your robots.txt with a Sitemap directive. Submit only the index, not each child sitemap separately, to avoid duplication and keep management simple.
Should sitemaps include redirected or blocked URLs?
No. Child sitemaps should list only final, canonical, indexable URLs that return a 200 status. Including redirected, blocked, non-canonical, or 404 URLs wastes crawl budget and sends confusing signals to search engines. Keeping sitemaps clean and current, reflecting only pages that truly exist and should be indexed, helps search engines crawl your site efficiently.
How Local Web Advisor checks this for you
Is your own website getting technical seo right?
Our free AI audit scans your site and tells you — in plain English — exactly what to fix for technical seo and seven other areas, with the business impact and the fix for each. No login needed to start.
Run my free website audit →Was this helpful?