Telling them apart
One element name is the whole difference, and it is visible in the first line or two of the file.
A regular sitemap opens a urlset element, and each entry is a url containing a loc. Those loc values are pages on your site.
A sitemap index opens a sitemapindex element, and each entry is a sitemap containing a loc. Those loc values are other sitemap files, not pages.
The confusion is understandable, because both use loc for their entries. If you are reading a sitemap and the loc values end in .xml, you are looking at an index.
| Sitemap | Sitemap index | |
|---|---|---|
| Root element | urlset | sitemapindex |
| Entry element | url | sitemap |
| What loc points at | A page on your site | Another sitemap file |
| Nesting | Cannot contain sitemaps | Cannot be nested inside another index |
| Submit it? | Yes, if you have only one | Yes, and its children are found automatically |
When you need an index
Strictly, when a single sitemap would exceed 50,000 URLs or 50MB uncompressed, which are the limits Google states for all sitemap formats.
Practically, well before that. Splitting by content type and using an index gives you per-section reporting in Search Console, which turns a vague indexing problem into a specific one. Knowing that your product sitemap has issues while your blog sitemap does not is worth more than any amount of guessing.
Most CMS plugins do this for you without asking. If your site reports several sitemaps, you almost certainly have an index already and did not have to think about it.
Submit the index, not the children
Crawlers follow an index to its children on their own, so submitting the index is sufficient and submitting each child as well adds nothing.
The same applies to robots.txt. One Sitemap line pointing at your index is enough. Listing every child there is not harmful, just redundant.
One rule that does bite: an index cannot contain another index. Nesting is a single level deep, and a nested index is invalid rather than merely inadvisable. If you have organised your sitemaps into a hierarchy, flatten it.
Where this trips people up
Two situations account for most of the confusion we see.
The first is a checker reporting a sitemap with zero URLs. That is usually an index being read as a regular sitemap, and it does contain entries, they just point at other files. Our sitemap checker distinguishes the two and follows the index for you.
The second is a discovered-URL count in Search Console that looks far too low. If you submitted an index, the count against the index may reflect the children rather than the total pages, and you need to read the per-child rows to see the real numbers.
Common questions
What is the difference between a sitemap and a sitemap index?+
A sitemap lists page URLs in a urlset element. A sitemap index lists other sitemap files in a sitemapindex element. Both use loc for entries, which is why they are easily confused.
Do I need to submit each child sitemap separately?+
No. Crawlers follow an index to its children automatically, so submitting the index alone is enough. Submitting the children as well is redundant rather than harmful.
Can a sitemap index contain another index?+
No. Nesting is limited to one level, and a nested index is invalid. If your sitemaps are arranged hierarchically, flatten them.
When should I switch to an index?+
Required once a single sitemap would pass 50,000 URLs or 50MB uncompressed. Worth doing earlier anyway, because splitting by content type gives you per-section reporting in Search Console.
Sources