What Is a Sitemap Index? How to Manage Multiple Sitemaps on Large Sites

We are Talha Aslan and team, and we usually discuss this setup with stores that carry thousands of products, hundreds of categories, and a deep blog archive. A small business site rarely needs more than one sitemap. However, as a catalog grows, one file starts to hit the limits. It also becomes hard to read. You can no longer tell which section is getting indexed and which one is falling behind.

This guide covers the whole structure. We explain the official limits, what goes inside the file, how to split by content type, why lastmod accuracy matters, and how to monitor each child sitemap in Search Console. If you still need the basics, start with our guide on what an XML sitemap is and how to create one. This article builds the next layer on top of that foundation.

When does a single sitemap stop being enough?

According to Google's documentation, a single sitemap can hold up to 50,000 URLs or 50MB uncompressed. Once you reach either limit, you need to split the file. You can confirm both values on the Google Search Central page about how to build and submit a sitemap.

That said, the limit is not the only reason to split. For example, a site with 8,000 URLs can also benefit from several files. When products, categories, and blog posts share one file, Search Console only shows you one combined number. As a result, you need extra exports to find which content type has a problem.

In practice, we suggest moving beyond a single file in these cases:

• Your URL count is getting close to 50,000, or the file size grows fast.
• Your site mixes very different content types.
• You add and remove products every day, so the catalog changes constantly.
• Different teams own different sections of the site.
• You want to diagnose indexing issues section by section.

In short, crossing the limit forces a split. Easier monitoring, on the other hand, is an optional reason. Still, it is a very valuable one.

What goes inside a sitemap index file?

In practice, a sitemap index is a simple XML document. Under the Sitemaps protocol, the file opens with a <sitemapindex> tag and ends with the same closing tag. Each child sitemap gets its own <sitemap> entry. Inside that entry, the only required child is <loc>, which holds the full address of the child sitemap.

There is also an optional <lastmod> field. It tells crawlers when the child sitemap file last changed. You can read the full specification on the sitemaps.org protocol page.

As an example scenario, picture a store called example.com. Its sitemap index could list these files:

• https://www.example.com/sitemap-products-1.xml
• https://www.example.com/sitemap-products-2.xml
• https://www.example.com/sitemap-categories.xml
• https://www.example.com/sitemap-blog.xml
• https://www.example.com/sitemap-pages.xml

Notice that the index never lists page URLs. It only lists sitemap files, and the page URLs live in the child sitemaps. Because of that, this separation is the most basic rule of the setup. Also, Google asks for fully qualified, absolute URLs, so avoid relative paths.

What are the official sitemap index limits?

Google's documentation on large sitemaps says a sitemap index file may contain up to 50,000 <loc> tags. In other words, one index can point to 50,000 child sitemaps. The sitemaps.org protocol adds that an index file should stay under 50MB. Moreover, Google states that all sitemap requirements also apply to sitemap index files.

Search Console adds one more limit. According to Google's guide to managing large sitemaps with an index, you can submit up to 500 sitemap index files per site through Search Console. For most sites, then, that ceiling is far away.

These values can change over time. Therefore, check the current figures in the official docs before you build. We also prefer to keep files well below the limit instead of sitting right at the edge.

Where should child sitemaps live on your server?

The location rule is the detail teams miss most often. Google says the sitemaps an index references must live on the same site as the index file. In addition, they must sit in the same directory as the index or in a deeper one.

For example, if your index lives in a /maps/ folder, the files it lists must sit in /maps/ or its subfolders. If you place the index at the site root, this restriction mostly disappears. Google also recommends posting sitemaps at the root. The reason is simple: unless you submit through Search Console, a sitemap only affects URLs below its parent directory.

When the location is wrong, Search Console shows a warning along those lines. We cover that case in detail in our post on the sitemap URL not allowed error. Put simply, a protocol mismatch, a www mismatch, or a different subdomain can all count as "not the same site."

So pick one standard before you start. First, decide which protocol, which hostname, and which folder you will use. Then generate the index and every child file from that single standard.

How do you split sitemaps by content type?

Splitting by content type means grouping URLs by what they do. Product pages go into one file, category pages into another, and blog posts into a third. As a result, Search Console shows the status of each content type on its own row.

For an online store, a typical split could look like this:

1. Product pages: the largest group, which you can split further into numbered parts.
2. Category and subcategory pages: fewer URLs, but commercially critical.
3. Brand pages: a separate file, if your store has them.
4. Blog posts and guides: the source of informational traffic.
5. Static company pages: about, contact, shipping terms.

Above all, the biggest benefit here is diagnostic speed. Say most of your category URLs are indexed while a large share of product URLs are not. You instantly know the problem sits in the product template or the product content. With one combined file, you would need a separate export and a manual match to see the same thing.

Also, if the product file grows very large, you can split it by product group. For instance, clothing, shoes, and accessories can each get their own file. That way, you also see which product group struggles with indexing.

When does splitting by number or by date make sense?

Numbered splitting puts URLs of the same type into fixed-size chunks. For example, you place 10,000 products in each file: sitemap-products-1, sitemap-products-2, and so on. This method is the easiest to automate because the software only needs a counter.

However, numbered files have a weakness. When you delete or add a product and the order shifts, many files can change at once. Then their lastmod values all move together, which sends Google an "everything changed" signal. For that reason, it is safer to tie the order to a permanent identifier, such as the product ID.

Date-based splitting works well for news sites and blog archives. You group posts by publishing month or year. Older files rarely change, because new content always lands in the newest file. As a result, Google has fewer files to re-read.

On the other hand, date-based splitting rarely suits a product catalog. Prices, stock, and descriptions change all the time. So our most common field recommendation combines two methods. We use content type plus numbering for products, and date-based files for the blog.

Which splitting method should you choose?

The right method depends on your site structure, how often content changes, and how you want to monitor it. The comparison below is a general framework we use to speed up the decision. It is not a strict rule; it is a starting point based on our field experience.

On most sites, combining methods gives the best result. For example, a multilingual store can split by language first, then by content type, and finally by number. Still, do not overcomplicate it. You should understand the structure at a glance from the file names alone.

How should you use lastmod inside a sitemap index?

Inside a sitemap index, lastmod describes the child sitemap file, not a page. According to Google, this field is optional and uses the W3C Datetime format. Google also notes that the value helps it schedule crawling.

So when should this value change? It should change when a URL enters or leaves the child file. It should also change when a page inside it gets a meaningful lastmod update. In other words, the child file's lastmod should match the newest lastmod among its pages.

A common mistake is an index that prints the current time on every request. In that case, every child file always looks freshly changed. As a result, the signal loses its meaning. Google says clearly that it uses lastmod only when the value is consistently and verifiably accurate.

We cover page-level usage in our guide to the sitemap lastmod tag. Here we only highlight the difference at the index layer. At this layer, an accurate lastmod is a short note that tells Google which child file deserves a fresh read.

Why does lastmod accuracy matter so much in child sitemaps?

On a large site, you cannot expect Google to read every file and every page at the same pace. An accurate lastmod points attention to the sections that changed. However, an inaccurate one can do the opposite. The signal becomes unreliable, and Google may stop trusting it.

Google's documentation says lastmod should reflect the last significant update to the page. For example, changing the copyright year in the footer does not count. Likewise, refreshing a small sidebar widget usually does not mean the page itself changed.

We run through this checklist on every setup:

• Does lastmod come from the real content update field in your database?
• Does a bulk price or stock update change the date of every product?
• Does a template change artificially refresh page dates?
• Next, does the date in the index match the newest date in the child file?
• Do you write time zone information consistently?

In addition, Google says it ignores priority and changefreq values. So instead of tuning those fields, put your energy into lastmod accuracy. On a large site, a correct date is one of the small details that pays off the most.

Which URLs should stay out of your child sitemaps?

A sitemap tells Google, "these are the main pages I want in the index." Therefore, the list should only contain canonical, crawlable URLs that return a 200 status. Otherwise, your Search Console reports fill up with noise. Then the real problem becomes harder to find.

These are the main URL types to remove from child sitemaps:

• Pages with a noindex rule.
• URLs that redirect to another address.
• Duplicate URLs whose canonical tag points elsewhere.
• Filter, sort, and session parameter URLs.
• Sections you block from crawling in robots.txt.
• Deleted pages that return 404 or 410.

Also, this cleanup matters even more on large sites. Automatically generated sitemaps can quietly add filter URLs or old products to the list. Over time, that feeds an index full of pages nobody needs. We explain the bigger picture in our article on index bloat and how to fix it.

In short, a tidy sitemap index structure cannot help much if the URLs inside the child files are messy.

How do you submit a sitemap index to Google?

Google's documentation lists several submission methods. The most common one is the Sitemaps report in Search Console. You enter the index URL there once, and you do not need to add the child files one by one. Google reaches them through the index.

The second method is a Sitemap line in your robots.txt file. Google notes that you can list several Sitemap lines there. Still, when you use an index, a single line usually does the job. Our guide on what robots.txt is and how to create it covers the general rules.

The third method is programmatic submission through the Search Console API. Teams that manage many properties save time this way. On the other hand, a one-time submission through the report is enough for most sites.

Above all, keep one point in mind. Google says plainly that submitting a sitemap is merely a hint. It does not guarantee that Google will crawl or index your pages. So a sitemap never replaces internal linking, content quality, or technical health. It simply supports them as one more discovery channel.

How do you monitor each child sitemap in Search Console?

This step delivers the real payoff. According to Search Console Help, the Sitemaps report shows columns such as Type, Submitted, Last read, Status, and Discovered pages for each submission. Your index file appears with the type "Sitemap index."

On the index row, Discovered pages adds up the URLs across all child files. If the same URL appears in more than one file, Google counts it only once. When you open the details, you see each child sitemap on its own row.

We ask three questions during monitoring. First, which child file has a much older Last read date than the others? Second, which file shows far fewer discovered pages than you expect? Finally, which file has errors? Together, these questions usually expose the weak section within minutes.

You can find the official description on the Search Console Sitemaps report help page. If you do not have time for this routine, our SEO consulting team can build your sitemap structure and monitor it on a regular schedule.

How do you filter the Page indexing report by sitemap?

The Sitemaps report shows discovery data, but it does not explain indexing status in depth. For that, you use the Page indexing report. According to Search Console Help, you can filter this report by sitemap. In addition, each sitemap's detail view offers a "See index coverage" link to the matching view.

This is where splitting by content type really pays off. For example, when you select only the product sitemap, you see why product pages stay out of the index. Then you repeat the same check for the category and blog files.

Example scenario: on example.com, almost every URL in the blog file is indexed. In the product file, however, a status such as "Crawled, currently not indexed" keeps piling up. That pattern suggests the issue is not general site health. Instead, it points to the product template or the product content.

We walk through the full method for finding and grouping unindexed URLs in our guide on how to find unindexed pages in Search Console. A sitemap index lets you apply that method one section at a time.

What do the Sitemaps report statuses mean?

According to Search Console Help, the Sitemaps report shows the status of the last request for each sitemap. There are three main statuses: Success, Has errors, and Couldn't fetch.

Specifically, Success means Google read the file without errors. Has errors means Google fetched the file but found one or more problems inside it. Even then, Google still queues the URLs it could parse. Couldn't fetch means Google could not retrieve the file at all.

With a sitemap index, watch for one trap. The index row can show Success while one of the child files shows Couldn't fetch. So do not stop at the top row. Open the details and check the status of every child file.

We explain the common causes and fixes for that status in our post on the sitemap couldn't fetch error. Also, removing a sitemap from the report does not make Google forget the file or its URLs. The help page says this directly. To stop crawling or indexing, you need robots.txt, deletion, or a noindex rule.

What are the most common sitemap index mistakes?

Most mistakes we see in the field are small details with a big impact. The list below covers the main points we suggest you check before and after launch.

1. Putting page URLs in the index file: the index only lists sitemap files.
2. Hosting child files on another domain or in a higher directory.
3. Using relative paths, although Google wants absolute URLs.
4. Mixing http and https, or www and non-www URLs.
5. Printing the current time as lastmod on every request.
6. Leaving deleted products and redirecting URLs in the list.
7. Generating files in a non-UTF-8 encoding or skipping character escaping.
8. Missing the moment when one child file grows past the limit.

Another common problem is a conflict between a plugin's sitemap and your own setup. For instance, if both your theme and an SEO plugin generate sitemaps, Google may see two lists that contradict each other. Therefore, choose one source of truth for the site and turn the other one off.

How do you set up a sitemap index step by step?

We wrote the steps below as an example scenario for example.com, a store with thousands of products and a blog. You can adapt them to your own platform.

1. Build an inventory: list every canonical URL you want indexed, grouped by content type.
2. Plan the split: assign separate files to products, categories, blog posts, and static pages.
3. Choose a chunk size: keep product files well below the official limit.
4. Set a stable order: distribute products by an ID that never changes.
5. Connect the lastmod source: pull the value from real content updates.
6. Generate the index: list each child file's full URL and lastmod value.
7. Verify the location: put the index at the root and keep child files on the same hostname.
8. Add it to robots.txt: declare the index URL with a Sitemap line.
9. Submit it in Search Console: enter only the index URL in the Sitemaps report.
10. Watch the first read: check each child file's status and discovered page count.

If you want to create a sample file for a small site, try our XML sitemap generator. On large sites, however, your platform should generate the files automatically and keep them current.

How should you organize a sitemap index on a multilingual site?

On multilingual sites, language is a natural axis for splitting. When you group each language's URLs into separate child files, Search Console shows which language version gets indexed better. For example, a site in English, German, and Turkish can have content-type files for each language.

However, keep one detail in mind. If language versions live in different folders, the location rule still applies. Placing the index at the root lets you list child files from every language folder without trouble.

Also, if you choose to declare alternate language versions in the sitemap, that data must not conflict with your on-page hreflang setup. So generate both from the same source. Two conflicting signals create more questions than a single one.

We cover the general rules for multilingual sites in our multilingual website SEO guide. A sitemap index is simply the layer that makes that structure easier to measure.

Should image and video sitemaps sit under the same index?

Yes, they can. The Sitemaps protocol describes the index as a list of sitemap files, and Google supports image and video extensions. Therefore, you can place sitemaps that carry image or video data under the same index.

In addition, Search Console Help notes that the Sitemaps report shows Discovered videos in a column next to Discovered pages. Keeping videos in a separate file makes that number easier to read.

Our recommendation, then, is simple. For images, adding the data to the file that lists the related page is usually enough. However, if your site is heavy on video, a separate video sitemap keeps monitoring clean. That way, video issues do not mix with product or blog data.

Finally, do not rely on an index that lists another index. Google's documentation describes the index as a structure that lists sitemap files. For that reason, we always build a single, flat index layer. If you need more files, create a second index file and submit it separately.

How often should you review your sitemap index?

The right frequency depends on how fast your site changes. A store that adds products every day does not need the same routine as a company site that publishes once a month. Still, large sites benefit from a regular maintenance calendar.

We usually suggest this rhythm:

• Weekly: does the Sitemaps report show any errors or a Couldn't fetch status?
• Monthly: do discovered page counts in child files match your expected numbers?
• Monthly: review the Page indexing report separately for each child file.
• After every major change: if the template, platform, or URL structure changed, verify the files again.

Site migrations and platform changes break sitemaps easily. Old URLs can stay in the list, and new ones can also go missing. Therefore, include a sitemap check in every migration plan. Also, track the size of each child file. Splitting a file before it reaches the limit prevents problems later.

When should you hand your sitemap index setup to a professional?

On a small site, a sitemap index setup takes a few hours, and plugin settings often handle it. However, things change on a store with tens of thousands of URLs, a multilingual structure, or a custom platform. There, you need to design the split logic, the lastmod source, and the cleanup rules together with your developers.

In practice, a few signs suggest it may be time for outside help. You keep seeing errors in child files. Discovered page counts do not match your catalog size. Or you cannot work out which content type stays out of the index.

As Talha Aslan and team, we take on this problem on your site from the ground up. We build the inventory, plan the split, agree on the lastmod source with your developers, and monitor each child sitemap in Search Console over time. Of course, no sitemap project can guarantee rankings. The goal is to help Google find the right pages and to help you spot problems fast. For a scope and quote tailored to your site, reach us through our SEO consulting page.

Core guide: What Is Digital Marketing? Its types, examples and how it is done, on one page with an interactive film that travels through the brain.