A sitemap index is an XML file that lists the addresses of other sitemap files rather than individual pages. It lets a search engine discover every sitemap on a site from one location, which is necessary once a site outgrows a single file and useful for organisation well before that.
How a sitemap index works
An ordinary XML sitemap lists page URLs. The sitemaps protocol caps each file at 50,000 URLs or 50MB uncompressed, so larger sites split their URLs across several files. The index file wraps those up: it contains a list of <sitemap> entries, each with a <loc> giving a child sitemap’s address and, optionally, a <lastmod> date.
Most UK small business sites meet sitemap indexes through their CMS. Yoast and Rank Math on WordPress publish one at /sitemap_index.xml, with children such as page-sitemap.xml, post-sitemap.xml and product-sitemap.xml. WordPress core, when no plugin takes over, uses /wp-sitemap.xml. Shopify generates /sitemap.xml as an index pointing to separate product, collection, page and blog sitemaps.
An index can also point to specialist files such as an image sitemap or a news sitemap. It cannot point to another index: the protocol allows one level only.
Why it matters
Search engines can find pages by following links, so a sitemap is a hint rather than a requirement. But for a shop with thousands of products, a site that publishes often, or a site with weak internal linking, sitemaps help new and updated pages get found sooner.
The bigger benefit is diagnosis. In the Search Console Sitemaps report, each child sitemap gets its own count of discovered URLs, and the Page indexing report can be filtered by sitemap. If product pages are being indexed and blog posts are not, you can see that straight away rather than digging through one list of 20,000 URLs.
A sitemap index also makes large sites easier to maintain. When a shop adds a new range, a new child sitemap can be generated without touching the others, and old sections can be retired cleanly. For news publishers and property portals, where thousands of URLs change each week, splitting sitemaps by date or section keeps each file small enough to regenerate quickly.
Common mistakes
- Two competing indexes. An SEO plugin and WordPress core, or two plugins, each publishing their own. Pick one and disable the other.
- Dirty child sitemaps. Redirected, noindexed, 404 or non-canonical URLs listed as if they should be indexed. This sends Google mixed signals.
- Stale or fake lastmod dates. Google says it uses lastmod only when it is consistently accurate. Setting every date to today teaches it to ignore yours.
- Old indexes still submitted. After a migration, the previous platform’s sitemap often lingers in Search Console, reporting errors for URLs that no longer exist.
- Blocked by robots.txt or a firewall. The file exists but Googlebot cannot fetch it.
How to act on it
Open your sitemap index in a browser and click through each child. Spot-check a handful of URLs from each: they should all return 200, be indexable and be the canonical version. Then add a line to robots.txt such as “Sitemap: https://www.example.co.uk/sitemap_index.xml”, and submit the same address in Google Search Console and Bing Webmaster Tools.
Check the Sitemaps report every month or so and after any major change. A sudden fall in discovered URLs, or a child sitemap reporting errors, is often the first sign that a plugin update or template change has broken something. If the problem runs deeper than one file, this is part of the technical SEO work I do on crawling and indexing.