What is a sitemap index?

The sitemap protocol sets two ceilings for every file: 50,000 URLs and 50 MB uncompressed. A corporate site of two hundred pages never comes close to that boundary. A shop with a deep catalogue, a news portal with an archive or a property listings site breaks through it without effort, and then the file has to be split.

The difference from an ordinary sitemap lies in what each entry holds. In a normal sitemap, every url element describes a page of the site and its loc carries the address of that page. In an index, every sitemap element describes a file and its loc carries the address of that file. The crawler reading it therefore works in two steps: it downloads the index first and then each of the sitemaps listed.

Everything else is identical. The same XML namespace, the same mandatory UTF-8 encoding, the same rules for escaped entities. Google puts it bluntly: the requirements that apply to a sitemap apply to an index as well. That is why a malformed index fails just like a malformed sitemap, and why the 50 MB ceiling also applies to the index file itself.

The structure is short. The root is sitemapindex, every listed file sits inside a sitemap, and only loc is required. The lastmod tag is optional and states when the corresponding sitemap file was last modified, in W3C Datetime format.

<?xml version="1.0" encoding="UTF-8"?>
<sitemapindex xmlns=
"http://www.sitemaps.org/schemas/sitemap/0.9">
  <sitemap>
  <loc>https://ejemplo.com/sitemap-1.xml</loc>
  <lastmod>2026-08-18</lastmod>
  </sitemap>
  <sitemap>
  <loc>https://ejemplo.com/sitemap-2.xml</loc>
  <lastmod>2026-07-30</lastmod>
  </sitemap>
</sitemapindex>

The limits repeat those of a normal sitemap: an index may list up to 50,000 files and must not exceed 50 MB uncompressed, that is 52,428,800 bytes. Combining both ceilings, a single index covers up to 2.5 billion URLs. Search Console additionally accepts up to 500 index files per site, so the practical headroom goes far beyond what almost any project needs.

One restriction surprises many people: an index cannot list another index. Google rejects that construction with an error of its own, “Nested sitemap indexes”, and asks you to remove entries pointing at index files. When a project needs more capacity, the way out is to submit several indexes separately.

Location matters too. The referenced sitemaps must live on the same site as the index and in its own directory or below it. An index placed at the domain root covers the whole site; one placed in /public/ only reaches that folder and its subdirectories. Listing sitemaps hosted on another host requires cross-site submission, which relies on the robots.txt of the target host or on the matching property in Search Console.

The decision hanging on this file is how to slice the sitemap, and that decision determines what you can measure afterwards. Search Console reports per sitemap: URLs discovered, read errors and, cross-referenced with the page indexing report, how many of those URLs made it in. If the whole catalogue travels in one giant file, that figure arrives as a lump sum and says almost nothing.

Slicing by content type changes the diagnosis. An index pointing at one sitemap for product pages, another for categories, another for articles and another for legal pages reveals that categories are indexed at 95 % while product pages stall at 40 %. That contrast shows where the problem sits before anything is touched.

It is worth remembering how far the tool reaches. Submitting a sitemap is only a hint to the search engine: it neither obliges it to download the file nor guarantees that the listed URLs will be crawled or indexed. An index speeds up discovery on large sites and organises the diagnosis, and there its power ends. Page quality and internal linking still decide the outcome.

• Place the index at the domain root, for example at https://ejemplo.com/sitemap_index.xml, so that its reach covers the entire site.
• Declare its address in robots.txt with the Sitemap: directive and submit it in Search Console as well.
• Slice by content type rather than cutting into arbitrary blocks of 50,000 URLs: that way every figure in the report answers a concrete question.
• Keep lastmod alive and honest. Google uses the value when it is consistent and verifiable, and stops trusting it once every regeneration stamps today's date onto all files.
• Include only canonical URLs that return 200 and are indexable; a redirect or a noindex inside a sitemap is noise working against you.
• Compress heavy child sitemaps with gzip, keeping in mind that the 50 MB limit is measured on the uncompressed file.

• Nesting indexes. An index pointing at another index triggers the “Nested sitemap indexes” error and leaves everything hanging off that entry unread.
• Putting the index in a subdirectory and listing sitemaps that sit above it in the hierarchy. Those entries fall outside its reach.
• Mixing hosts or protocols. An index served on one domain cannot list sitemaps from another without verified cross-site submission.
• Regenerating the file every night with today's date in every lastmod. The signal loses its value and the search engine stops taking it into account.
• Leaving dead URLs inside after a migration. The index still validates while the report fills with errors that cover up the real problems.