The difference in sitemap index vs sitemap comes down to one job each does. A regular sitemap.xml is a flat list of your actual page URLs. A sitemap index is a list of sitemaps, not pages. Once a site crosses 50,000 URLs or a 50MB uncompressed file size, a single sitemap.xml is no longer valid, and you split your URLs across multiple sitemap files that an index file points to. This guide covers exactly when that switch is forced, the precise syntax, how to chunk a large site logically, and how to submit the index to Google so it crawls efficiently.
Most pages on this topic stop at Google's one-line spec ("50,000 URLs and 50MB per file") and leave you to figure out the rest. The practical questions are what nobody answers: how to split, what the index file actually looks like, and where hreflang and image sitemaps fit. That is the gap this article fills.
Sitemap Index vs Sitemap: The Core Difference#
A sitemap and a sitemap index are two different file types that use two different root elements. Confusing them is the single most common mistake, and search engines will reject the file if you nest them wrong.
- A sitemap uses the
<urlset>root and contains<url>entries. Each entry is a real, indexable page on your site. - A sitemap index uses the
<sitemapindex>root and contains<sitemap>entries. Each entry points to the location of another sitemap file, not a page.
Think of the index as a table of contents. It does not list your articles or product pages directly. It lists the smaller sitemap files, and each of those lists the pages. Search engines fetch the index first, then crawl each child sitemap it references.
Key rule: a sitemap index can only point to sitemaps. You cannot put page URLs and child-sitemap URLs in the same file. Mixing the two root elements is invalid and will fail validation in Search Console.
Why the two-tier structure exists#
The whole reason this structure exists is the hard ceiling on a single file. The sitemaps.org protocol (and Google, Bing, and the rest follow it) caps any one sitemap at:
- 50,000 URLs maximum per file.
- 50MB uncompressed maximum file size.
Hit either limit and the file is out of spec. Big sites blow past 50,000 URLs constantly, so the protocol lets you publish many sitemap files and tie them together with one index. A single sitemap index can itself reference up to 50,000 sitemaps, which means the theoretical ceiling is 50,000 x 50,000 = 2.5 billion URLs. You will run out of pages long before you run out of sitemap capacity.
When to Switch From a Single Sitemap to a Sitemap Index#
The switch is not a style choice. It is forced by limits, and there are three triggers. The first one that you hit decides the matter.
| Trigger | The limit | What happens if you ignore it |
|---|---|---|
| URL count | More than 50,000 URLs in one file | Search engines stop reading at the limit; extra URLs are silently dropped |
| File size | More than 50MB uncompressed | The file is rejected as invalid; nothing in it gets crawled reliably |
| Logical organization | No hard limit, but useful past a few thousand URLs | Harder to debug crawl issues and read coverage reports per section |
Here is the practical read on each.
URL count is the most common reason. With more than 50,000 published, indexable URLs you must split. There is no flag to flip or quota to raise. You either split into multiple sitemaps under an index, or the URLs past number 50,000 never get submitted.
File size catches sites with long URLs. You can hit the 50MB ceiling before 50,000 URLs if your URLs are very long, or if you pack lots of <image:image> and <xhtml:link> (hreflang) entries per URL. Each extra element adds bytes, and multilingual sites with hreflang annotations bloat fast.
Logical organization is the underrated reason. Even at 8,000 URLs, splitting into themed sitemaps is smart. When Search Console reports a sitemap has indexing problems, a per-section split tells you immediately whether the issue is in your blog, products, or category pages. One giant file tells you nothing.
Practical tip: if you are anywhere near 40,000 URLs, build the index structure now rather than after you cross 50,000. Retrofitting under pressure when pages are dropping out of the index is far more stressful than setting it up early.
The Exact Sitemap Index Syntax (With Example)#
This is the part the terse spec sheets skip. A sitemap index is a small XML file. Here is a complete, valid example pointing to three child sitemaps.
<?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-06-25T09:00:00+00:00</lastmod>
</sitemap>
<sitemap>
<loc>https://example.com/sitemap-products.xml</loc>
<lastmod>2026-06-24T14:30:00+00:00</lastmod>
</sitemap>
<sitemap>
<loc>https://example.com/sitemap-pages.xml</loc>
<lastmod>2026-06-20T08:15:00+00:00</lastmod>
</sitemap>
</sitemapindex>
Three details matter here.
<loc>must be an absolute URL. Use the fullhttps://example.com/...path, not a relative/sitemap-posts.xml. Relative URLs are invalid in sitemaps.<lastmod>is the only other allowed child. Each<sitemap>entry accepts<loc>and optionally<lastmod>. There is no<changefreq>or<priority>at the index level (Google ignores those even in regular sitemaps).<lastmod>should be honest. Set it to the most recent time a URL inside that child sitemap actually changed. A<lastmod>that always reads "today" trains crawlers to ignore it, while an accurate one helps a crawler decide which child sitemaps to re-fetch first.
Each child sitemap is just a normal <urlset> file:
<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
<url>
<loc>https://example.com/blog/first-post</loc>
<lastmod>2026-06-25T09:00:00+00:00</lastmod>
</url>
<url>
<loc>https://example.com/blog/second-post</loc>
<lastmod>2026-06-22T11:00:00+00:00</lastmod>
</url>
</urlset>
You can hand-edit these for a tiny split, but for anything real you generate them. A free XML sitemap generator handles the chunking, the index file, and absolute-URL formatting so you do not introduce a typo that quietly breaks crawling.
How to Split a Large Site Logically#
You are allowed to split arbitrarily ("URLs 1 to 50,000 here, 50,001 to 100,000 there"), but that is a wasted opportunity. Splitting by section or content type makes your sitemaps a diagnostic tool, not just a compliance checkbox.
Split by content type or section#
The cleanest pattern is one sitemap per logical group, all referenced by a single index:
sitemap-posts.xmlfor blog or article URLssitemap-products.xmlfor product or listing pagessitemap-categories.xmlfor taxonomy and category pagessitemap-pages.xmlfor static pages (about, contact, legal)
Now when Search Console says "sitemap-products.xml: 4,200 submitted, 3,100 indexed," you know exactly where to investigate. With one monolithic file you would only know that something, somewhere, is not indexed.
Keep each child sitemap well under the cap#
Do not pack each child file right up to 49,999 URLs. Aim for a few thousand up to roughly 10,000 to 20,000 URLs each. Smaller files are faster to fetch and re-fetch when only one section changes, and they keep you safely under the 50MB size ceiling as URLs grow.
Decide between separate sitemaps and combined ones#
You have a choice between dedicated specialized sitemaps and combining everything per URL.
| Approach | When to use it | Trade-off |
|---|---|---|
| Combine images and hreflang into the main URL sitemaps | Most sites | Simpler structure; watch the 50MB size limit |
| Separate image sitemap | Image-heavy sites (galleries, stock, ecommerce) | Cleaner reporting on image indexing, but more files to maintain |
| Separate hreflang/language handling | Large multilingual sites | Avoids bloating one file; requires reciprocal annotations |
For most sites, fewer files is better. Reach for separate specialized sitemaps only when a section is large enough that combining would push a file toward the size limit or muddy your reporting.
Where Hreflang and Image Sitemaps Fit in an Index#
This is the piece almost no competing article addresses, and it trips people up on large international and media-heavy sites.
Hreflang inside a sitemap index#
Hreflang annotations live inside the <url> entries of a regular sitemap, using the xhtml:link element. They do not change the index file at all. The index still just lists child sitemaps. A child sitemap with hreflang looks like this:
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9"
xmlns:xhtml="http://www.w3.org/1999/xhtml">
<url>
<loc>https://example.com/page</loc>
<xhtml:link rel="alternate" hreflang="en" href="https://example.com/page"/>
<xhtml:link rel="alternate" hreflang="es" href="https://example.com/es/page"/>
<xhtml:link rel="alternate" hreflang="x-default" href="https://example.com/page"/>
</url>
</urlset>
Two things to remember. First, hreflang annotations must be reciprocal: if the English page points to the Spanish version, the Spanish page must point back. Second, every xhtml:link adds bytes, so hreflang-heavy sitemaps reach the 50MB limit at far fewer than 50,000 URLs. That is precisely the case where splitting into more child sitemaps under one index becomes necessary even with a modest URL count.
Image sitemaps inside an index#
Image entries also live inside the page <url> block, using the image:image namespace, not in the index. You can either attach images to the URLs in your main sitemaps, or create a dedicated image sitemap and add it as another <sitemap> entry in the index.
For a site with thousands of images per section, a separate image sitemap keeps your main sitemaps lean and gives you a clean line in Search Console for image indexing. For everything else, attaching images to existing URL entries is simpler and works fine.
How to Submit a Sitemap Index to Google#
Once your index is built, you only submit one thing: the index file. You do not submit each child sitemap separately. Google discovers the children by reading the index.
Step 1: Reference the index in robots.txt#
Add a Sitemap: line to your robots.txt pointing at the absolute URL of the index file. This lets any crawler discover it, not just Google.
Sitemap: https://example.com/sitemap-index.xml
You can list multiple Sitemap: lines if needed, but with a proper index you only need the one. If you also need to control which paths crawlers can access, generate a clean file with a free robots.txt generator so the directives and the sitemap reference are formatted correctly.
Step 2: Submit the index in Google Search Console#
In Search Console, open the Sitemaps report for your property and enter the path to your index file (for example, sitemap-index.xml). Submit it. Google reads the index, then queues each child sitemap. You will see the index listed, and over the following days the per-sitemap discovery and indexing counts populate.
Step 3: Verify each child sitemap was read#
After Google processes the index, the Sitemaps report shows each referenced child sitemap. Confirm that the submitted-URL counts match what you expect per section. If a child sitemap shows zero URLs or an error, that file has a problem (a bad <loc>, a syntax error, or a size overflow), and you fix that one file rather than the whole structure.
Step 4: Monitor and keep lastmod accurate#
Resubmission is rarely needed once an index is in place. Google re-fetches the index and child sitemaps on its own schedule. The most useful thing you can do is keep <lastmod> accurate, both in the index entries and inside the child sitemaps, so crawlers prioritize the sections that actually changed. While you are tightening up technical SEO signals, it is worth pairing your sitemap with structured data: our schema markup generator helps your key pages earn rich results once they are crawled.
Common Sitemap Index Mistakes to Avoid#
A few errors account for most broken large-site sitemaps.
- Nesting an index inside an index. A sitemap index cannot point to another sitemap index, only to regular sitemaps. One level of indexing is all you get.
- Mixing
<url>and<sitemap>entries. A file is either a<urlset>or a<sitemapindex>, never both. - Relative URLs in
<loc>. Always absolute, always with the correct protocol and host. - Listing the same URL in multiple child sitemaps. Each URL should appear once across the whole set. Duplicates waste crawl budget and confuse reporting.
- Submitting child sitemaps individually after submitting the index. Redundant, and it clutters your Sitemaps report. Submit the index only.
The Bottom Line on Sitemap Index vs Sitemap#
The sitemap index vs sitemap decision is settled by your URL count and file size, not preference. Under 50,000 URLs and 50MB, a single sitemap.xml is fine. Cross either limit and you must split your pages across multiple child sitemaps tied together by one <sitemapindex> file, then submit only that index to Google.
Done well, the split is more than compliance. Chunking by section turns your sitemaps into a crawl-health dashboard, keeps hreflang and image-heavy files under the size ceiling, and tells you exactly where indexing problems live. If you would rather not hand-write a single line of XML, a free XML sitemap generator builds the index and child files, formats the absolute URLs, and saves you from the typos that quietly break crawling on a large site.
Frequently Asked Questions#
What is the difference between a sitemap and a sitemap index?
A sitemap (<urlset>) lists the actual page URLs on your site. A sitemap index (<sitemapindex>) lists other sitemap files, not pages. Search engines read the index first, then crawl each child sitemap it references. You use an index once you have more sitemap files than a single one can hold.
When do I need a sitemap index instead of one sitemap.xml? You must switch when a single file exceeds 50,000 URLs or 50MB uncompressed, whichever comes first. Multilingual sites with hreflang or image-rich sites can hit the 50MB size limit well before 50,000 URLs. Many teams also split earlier, around a few thousand URLs, purely for cleaner per-section reporting in Search Console.
Can a sitemap index point to another sitemap index?
No. A sitemap index can only reference regular sitemaps (<urlset> files), not other index files. You get exactly one level of indexing. If you need to organize many sitemaps, group them logically under a single index rather than trying to nest indexes.
How many URLs can a sitemap index handle in total? A single sitemap index can reference up to 50,000 child sitemaps, and each child sitemap can hold up to 50,000 URLs. That works out to a ceiling of roughly 2.5 billion URLs from one index, which is far more than any real site needs.
Do I submit each child sitemap to Google or just the index? Submit only the index file in Google Search Console and reference it once in robots.txt. Google reads the index and discovers every child sitemap automatically. Submitting child sitemaps individually is redundant and only clutters your Sitemaps report.
Where do hreflang and image entries go in a sitemap index?
They never go in the index file itself. Hreflang (xhtml:link) and image (image:image) annotations live inside the <url> entries of the regular child sitemaps. The index only ever lists child sitemap locations. Because these annotations add file size, hreflang-heavy or image-heavy child sitemaps reach the 50MB limit at fewer URLs, which is often why you split.
