An XML sitemap lists page or media URLs. A sitemap index lists other sitemap files. The two formats are related, but they solve different problems. A normal sitemap is enough for many websites. A sitemap index becomes useful when the site exceeds protocol limits or when separate files make monitoring and maintenance easier.
Choosing the right format is less about site prestige and more about operational clarity. A small site does not gain an SEO advantage from creating dozens of tiny sitemap files, while a large site becomes difficult to manage when every URL is forced into one document.
What a standard XML sitemap contains
A standard URL sitemap has a urlset root element. Each url entry contains a loc element with the absolute page address. Optional fields can describe the last meaningful modification date or provide extensions for images, video, news, and alternate language versions.
The purpose is direct URL submission. Search engines fetch the file, read the listed locations, and add unknown or updated URLs to their crawling systems. The sitemap remains a hint. It does not override noindex, robots.txt, canonical selection, or quality assessment.
What a sitemap index contains
A sitemap index uses a sitemapindex root element. Instead of page URLs, it contains loc entries pointing to individual sitemap files. It may also include lastmod values that describe when each child sitemap changed.
The index works like a directory. You can submit the index once, and the search engine can retrieve the child files referenced inside it. Google allows up to 50,000 sitemap locations in one index, according to its sitemap index documentation.
Protocol limits decide when splitting is mandatory
A single sitemap may contain no more than 50,000 URLs and may not exceed 50 MB when uncompressed. If either limit is exceeded, split the URLs across multiple files. The files can then be gathered in one or more sitemap indexes.
Compression can reduce transfer size, but the 50 MB limit applies to the uncompressed document. A compressed file is therefore not a way to place an unlimited number of entries into one sitemap.
Reasons to use an index before you hit the limit
Operational separation can justify multiple sitemaps on a smaller site. You might create different files for articles, products, categories, videos, images, or language versions. This can make errors easier to isolate and coverage trends easier to compare in Search Console.
For example, if product URLs are indexed normally but article URLs show a sudden increase in exclusions, separate sitemap reporting helps you focus on the affected template. The split should follow a useful editorial or technical boundary, not an arbitrary number of files.
When one sitemap is the better choice
If a website has a few hundred or a few thousand indexable URLs, one well-maintained sitemap is usually simpler. It reduces moving parts, avoids empty child files, and makes manual inspection easier.
A sitemap index adds no inherent ranking benefit. Search engines do not reward a site for having a complex sitemap hierarchy. Complexity is justified only when it improves scale, ownership, monitoring, or generation reliability.
How to organise child sitemaps
Use groups that remain stable over time. Common approaches include content type, hostname, language, publication year, or product catalogue section. Avoid splitting by values that change constantly, such as current popularity or temporary campaign membership.
Every child sitemap should follow the same inclusion standards. It should list live, canonical, indexable URLs. The principles in what belongs in an XML sitemap apply equally whether the file is submitted directly or through an index.
Keep filenames understandable. Names such as sitemap-articles.xml and sitemap-products-01.xml are easier to investigate than randomly generated identifiers. If a file is regenerated automatically, preserve its URL unless there is a technical reason to change it.
Use lastmod at the correct level
In a URL sitemap, lastmod refers to the page. In a sitemap index, lastmod refers to the child sitemap file. The index value should change when the contents of that child sitemap meaningfully change, not merely whenever a scheduled job runs.
This distinction lets a crawler decide whether it may need to fetch a child file again. As with page-level dates, false freshness makes the signal less dependable.
Common configuration mistakes
- Putting page URLs directly inside a sitemap index.
- Putting child sitemap URLs inside a normal urlset file.
- Listing a sitemap index inside itself.
- Exceeding the URL or uncompressed size limit.
- Referencing child files that redirect, require authentication, or return errors.
- Mixing production and staging hosts.
- Keeping obsolete child sitemaps in the index after their content has moved.
Run the checks described in how to audit an XML sitemap against both the index and every child file. A valid index does not prove that its referenced files are healthy.
Submission and robots.txt
You can submit either individual sitemap files or the index through search engine tools. When an index includes all relevant child files, submitting the index is normally sufficient. You may also declare its URL with a Sitemap line in robots.txt.
Make sure the index and child files are accessible to crawlers. A sitemap URL is not governed like a normal page entry, but firewalls, authentication, and server errors can still prevent retrieval.
A practical decision rule
Use one XML sitemap when it fits comfortably within the limits and remains easy to maintain. Use a sitemap index when multiple files are required by size or when their separation creates clear monitoring and ownership benefits.
Whichever structure you choose, quality comes from the URLs inside it. A tidy index full of broken, redirected, or non-canonical entries is still a poor sitemap system. Start with accurate inclusion rules, then choose the simplest structure that supports them.