When to split a sitemap, and how to write the sitemap index

A sitemap index is a sitemap that lists other sitemaps instead of pages. You need one when a single file would cross Google's published limit — 50MB uncompressed or 50,000 URLs, whichever arrives first. Below that line, splitting buys you nothing about crawling and one thing about debugging, which is usually the better reason to do it anyway.

What you need before this chapter

You need a working sitemap already submitted. Writing the first one, choosing what belongs in it and what does not, is covered in how to create a sitemap. This chapter starts at the point where one file stops being enough, or stops being readable.

The two numbers that force a sitemap index

Google states the ceiling in one line: "All formats limit a single sitemap to 50MB (uncompressed) or 50,000 URLs." Cross either and the file is invalid, not merely large. The documented remedy is equally short: "If you have a larger file or more URLs, you must break your sitemap into multiple sitemaps. You can optionally create a sitemap index file and submit that single index file to Google" (Build and submit a sitemap, read 2026-09-03).

The uncompressed part catches people. Gzipping a sitemap is allowed and sensible, but the 50MB is measured before compression, so a 9MB .gz file can still be over the limit.

The index has its own ceiling: "A sitemap index file may have up to 50,000 loc tags", and "You can submit up to 500 sitemap index files for each site in your Search Console account" (Manage large sitemaps, read 2026-09-03). Multiply the first two rows and the headroom for one index is 2.5 billion URLs. Almost nobody is constrained by this file format.

Before deciding anything, get the two numbers for your own file: how many <loc> entries it holds, and what it weighs on disk before compression. Most build tools report neither, and teams argue about splitting for a week without either number in the room. If you are under 10,000 URLs and a few megabytes, the limits are not your reason and the next section is.

Where to split, when the limit is not what is forcing you

Most sites that build an index are nowhere near 50,000 URLs. They split because one flat file tells them nothing when Search Console reports that 4,000 pages are not indexed. Split by the axis you will want to read a number against.

The last row is the one to take seriously. An index over three files that all behave identically adds a moving part and answers no question you had.

Split a sitemap along the line you would want to read a coverage number against. Any other line just makes more files.

Build and submit it in four steps

The whole job is one file plus two references. Everything hard about it is deciding the split, which is the previous section.

1. Write each child sitemap normally, keeping every one under both limits. Give them names that say what they hold: sitemap-blog.xml, not sitemap-2.xml.
2. Write the index file listing every child by absolute URL. Same site only — sitemaps.org is explicit that "A Sitemap index file can only specify Sitemaps that are found on the same site as the Sitemap index file."
3. Put the index at the site root and point robots.txt at it with a Sitemap: line. Location matters beyond tidiness: Google notes that "unless you submit your sitemap through Search Console, a sitemap affects only descendants of the parent directory."
4. Submit the index in Search Console — the index only, never the children as well. Search Console will report each child underneath it, which is the whole reason you built it.

After submitting, wait for Search Console to report the index as read, then confirm each child appears beneath it with its own URL count. A child that is listed but shows zero discovered URLs is usually a path problem in the index rather than a problem in the child, and catching that on day one is much cheaper than noticing it in a coverage report a month later.

The template

Copy this, replace the three entries, and delete lastmod if you cannot generate it honestly.

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

The lastmod on an index entry describes the child sitemap, not the pages inside it. A build pipeline that stamps today's date on every entry at every deploy is publishing a field that carries no information, which is the failure mode measured in whether lastmod can be trusted. Leaving the element out is a valid and more honest option.

Four ways this goes wrong

All four are quiet. None of them produces an error message anywhere you routinely look.

1. Submitting the index and every child. Search Console then reports the same URLs twice under different parents, and every count you read afterwards is ambiguous.
2. Gzipping past the limit. The 50MB is uncompressed. Check the file before it is compressed, or you will ship an invalid sitemap that looks small on disk.
3. Putting the index in a subdirectory. An index at /xml/sitemap-index.xml that lists pages outside /xml/ depends entirely on Search Console submission to be honoured. Root is the safe place.
4. Splitting by an axis nobody reads. Alphabetical shards, or shards numbered by build order, produce files you cannot form a hypothesis about. When coverage drops, you will still be looking at 40,000 URLs with no way to narrow it.

What a sitemap index will not do

It will not make Google crawl faster or more often. Nothing in the documentation promises that, and we have never measured a case where splitting alone changed indexing. It does not push anything — for that, see how to set up IndexNow. And it cannot make a page eligible for indexing that was not already; a sitemap is a suggestion about discovery, not an instruction about inclusion. To check that the URLs you are listing actually return what you think they return, see how QueryWin reads a page.

One thing we could not settle: neither the sitemaps.org protocol page nor Google's large-sitemap documentation states whether an index file may list another index file. We did not find a sentence either way, so we do not nest them, and neither should you until someone can point at the line that allows it.

Common questions

How many URLs before I need a sitemap index?

Technically 50,001. Practically, build one as soon as you have two page types whose coverage you want to read separately, which for most sites is far earlier.

Should I submit each child sitemap too?

No. Submit the index alone. Search Console lists the children under it, and submitting both produces duplicate reporting that makes every number harder to read.

Can the child sitemaps live on a subdomain?

Not in the same index. The protocol restricts an index to sitemaps "found on the same site as the Sitemap index file", so a separate subdomain needs its own sitemap set and its own Search Console property.

Does the order of entries matter?

Nothing in the specification says it does, and we have no data suggesting otherwise. Order them so a human can find a file quickly.

Do I need to compress the files?

Only if size is a real constraint on your bandwidth or your build. Compression is allowed, it changes nothing about the 50,000-URL count, and it does not raise the 50MB ceiling because that is measured uncompressed.