Sitemap Index

TL;DR — A sitemap index is a sitemap of sitemaps. A single sitemap can only hold 50,000 URLs, so big sites split their URLs across several sitemaps and then list those sitemaps in one small “index” file. You submit just the index, and search engines follow it to all the rest.

What a sitemap index is

A normal XML sitemap is a list of your page URLs. A sitemap index is one level up: it’s a file that lists your other sitemaps instead of listing pages. Think of it as a table of contents that points at several chapters, where each chapter is a sitemap full of URLs.

You hand search engines the index, and they read it to find every sitemap it references, then read each of those to find your URLs. Evidence for this claim A sitemap index contains sitemap entries with a required loc value and an optional lastmod value. Scope: Sitemaps.org protocol structure for sitemap index files. Confidence: high · Verified: 2026-07-14 Sitemaps.org: Sitemap index XML tag definitions

Why you’d need one

A single sitemap has hard limits: it can hold at most 50,000 URLs, and the file can’t be bigger than 50MB uncompressed. The moment you have more URLs than that — or the file gets too big — you have to split it into multiple sitemaps. The sitemap index is what ties those pieces back together so you only submit one thing.

You don’t have to wait until you hit the limit, either. Plenty of large sites use an index just to keep things tidy — one sitemap for the blog, one for products, one per language — even when each part is well under 50,000 URLs.

How much can it cover?

A lot. An index can list up to 50,000 child sitemaps, and each of those can hold up to 50,000 URLs. Multiply that out and a single index already covers 2.5 billion URLs. Whatever size your site is, you will never run out of sitemap capacity.

How you use it

• Split your URLs across multiple sitemap files (most SEO plugins and frameworks do this for you automatically).
• Put a sitemap index file at the top that lists each of those sitemaps.
• Submit only the index in Google Search Console and Bing Webmaster Tools. That one submission covers all the children.

Want the anatomy, the exact limits, the “don’t nest an index in an index” rule, and the splitting trick that turns your sitemaps into an indexing diagnostic? Switch to the Advanced tab.

TL;DR — A sitemap index is a sitemap of sitemaps — a <sitemapindex> file listing <sitemap> entries (<loc> + optional <lastmod>) instead of URLs. You need one once a single sitemap would exceed 50,000 URLs or 50MB uncompressed, or to organize a large multi-section/region site. An index can reference up to 50,000 child sitemaps × 50,000 URLs each = 2.5 billion URLs per index; with up to 500 index files per site in Search Console, the theoretical ceiling is 1.25 trillion — a number no real site approaches. Children stay on the same site at the same directory level or lower, you don’t nest an index inside an index (no tag for it, no tooling support), and you submit only the index. The payoff worth chasing: split by section/content type so you can read submitted-vs-indexed per segment.

What a sitemap index file actually is

A sitemap index is a sitemap whose entries are other sitemaps. Where a regular sitemap wraps <url> blocks in a <urlset>, an index wraps <sitemap> blocks in a <sitemapindex>. Each <sitemap> has a <loc> pointing at one of your sitemap files and, optionally, a <lastmod>. That’s the whole structure — it carries no page URLs of its own. Evidence for this claim A sitemap index contains sitemap entries with a required loc value and an optional lastmod value. Scope: Sitemaps.org protocol structure for sitemap index files. Confidence: high · Verified: 2026-07-14 Sitemaps.org: Sitemap index XML tag definitions

It exists for one reason: the sitemaps format has hard size limits, and big sites blow past them. So you split your URLs across many sitemaps and use an index to present them to search engines as a single unit.

When you need one

Two triggers:

1. You hit the size limits. A single sitemap maxes out at 50,000 URLs or 50MB uncompressed, whichever comes first. Google’s guidance is direct: “If you have a sitemap that exceeds the size limits, you’ll need to split up your large sitemap into multiple sitemaps.” Evidence for this claim A sitemap index can list up to 50,000 sitemap files, and each sitemap is limited to 50,000 URLs or 50 MB uncompressed. Scope: Google-supported sitemap and sitemap-index limits. Confidence: high · Verified: 2026-07-14 Google Search Central: Manage sitemaps with a sitemap index file Once you’ve split, an index ties the pieces together.
2. You want to organize a large site — even under the limit. Multi-section sites (blog vs. products vs. category pages) and multi-region/multi-language sites are far easier to manage and monitor as separate sitemaps under one index. That organizational use is, in my view, the better reason to reach for an index, and I come back to it in the Frameworks tab.

Anatomy

The index is small and dull by design — <sitemapindex>, then a <sitemap> block per child, each with a <loc> and an optional <lastmod>:

<?xml version="1.0" encoding="UTF-8"?>
<sitemapindex xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <sitemap>
    <loc>https://www.example.com/sitemap1.xml.gz</loc>
    <lastmod>2024-08-15</lastmod>
  </sitemap>
  <sitemap>
    <loc>https://www.example.com/sitemap2.xml.gz</loc>
    <lastmod>2024-08-15</lastmod>
  </sitemap>
</sitemapindex>

Notes that matter:

• The namespace is the same sitemaps.org/schemas/sitemap/0.9 you use on a regular sitemap; the file is UTF-8 and <loc> values are fully-qualified absolute URLs.
• Children can be gzipped — .xml.gz is fine, and the 50MB cap is measured on the uncompressed size.
• The optional <lastmod> here describes when that child sitemap last changed, not when individual pages changed.

How many can you submit — and how many pages is that?

This is where people lowball the ceiling. Stack the limits up:

• Google Search Console accepts up to 500 sitemap index files per site: “You can submit up to 500 sitemap index files for each site in your Search Console account.”
• Each index can list up to 50,000 child sitemaps.
• Each child sitemap can hold up to 50,000 URLs.

Do the multiplication and the theoretical ceiling is 500 × 50,000 × 50,000 = 1.25 trillion URLs (1,250,000,000,000). Treat that as a ceiling no real site approaches, not a target — the takeaway is simply that you will never run out of sitemap capacity. And you rarely need to get fancy with multiple index files at all: a single sitemap index, without submitting any others, already covers 50,000 × 50,000 = 2.5 billion URLs. If you’ve got 2.5 billion indexable URLs, your sitemap setup is not your problem.

Location rules

The child sitemaps an index references have to live on the same site as the index, and at the same directory level or lower than the index file. An index at https://www.example.com/sitemap-index.xml can point at https://www.example.com/sitemaps/products.xml, but not at a sitemap on a different host or sitting above its own path. Break this and Search Console flags the children as “URL not allowed.” (Cross-domain references are only valid when both domains are verified in Search Console — but for an ordinary single-site index you don’t go there.)

Don’t nest an index inside an index

A sitemap index lists sitemaps, not other indexes. Neither sitemaps.org’s live protocol page nor Google’s sitemap-index documentation states this in so many words today — I checked both directly rather than trust an older paraphrase. What the protocol does say is narrower: the <loc> tag inside a <sitemapindex> is defined as identifying “a Sitemap, an Atom file, RSS file or a simple text file” — an index file isn’t on that list, and the format has no tag for nesting one index under another. Every sitemap generator, plugin, and search engine I’m aware of treats index-of-indexes as unsupported on that basis; it’s a strong practitioner convention grounded in the format’s structure rather than a single quotable sentence from either doc. Treat it as a hard rule: one level of indexing only. If you find yourself wanting an index-of-indexes, you almost certainly have room to reorganize within the 2.5-billion-URL ceiling a single index already gives you.

Submit only the index

You submit the index file, and that single submission pulls in every child sitemap it references — you don’t need to submit the children one by one. John Mueller put it plainly: “You can submit the individual ones, but you don’t really need to.” Submitting both the index and its children isn’t harmful, just redundant. One clean submission of the index is the move.

That said, submitting a sitemap — index or not — is a discovery aid, not an indexing guarantee. The index helps engines find your sitemaps; it doesn’t promise the URLs inside them get crawled or indexed.

Splitting strategy — for reporting, not crawl efficiency

Here’s the part that’s underplayed everywhere else. How you split your sitemaps across an index does not change how Google crawls or indexes your pages. The reason to split thoughtfully is monitoring. Mueller’s framing is the one I lean on: “I generally recommend splitting a sitemap file into logical parts of your site so that you can monitor those parts individually (eg, category pages vs detail pages…). … It doesn’t change how Google crawls & indexes them, it’s really just so that you can track them better on your side.”

The practical payoff: the Search Console Sitemaps report shows submitted-vs-indexed counts per sitemap. Split your index by section or content type — blog, products, categories, docs, per region — and you can see which segment is under-indexed instead of staring at one site-wide number. That’s a diagnostic I use constantly. (It’s the same reason I’ll keep a sitemap of old URLs around during a migration: so I can watch that specific set drop out of the index in GSC.)

So split by what you want to measure, not by some imagined crawl benefit. The crawl benefit isn’t there; the reporting benefit is real.

How it relates to the rest of the sitemap family

A sitemap index sits on top of your regular XML sitemaps, and the broader sitemaps overview is the place to start if you’re new to the whole topic. Your image and video sitemaps are just more child files an index can reference, and the whole apparatus is part of how search engines handle discovery. None of those need linking out from here — they’re siblings in the same cluster.

AI summary

A condensed take on the Advanced version:

• A sitemap index is a sitemap of sitemaps — a <sitemapindex> file listing <sitemap> entries (<loc> + optional <lastmod>), not page URLs.
• You need one when a single sitemap would exceed 50,000 URLs or 50MB uncompressed, or when you want to organize a large multi-section/region site (the organizational use is the better reason).
• Capacity is effectively unlimited: up to 50,000 child sitemaps per index × 50,000 URLs each = 2.5 billion URLs per index. With up to 500 index files per site in Search Console, the theoretical ceiling is 1.25 trillion URLs — a number no real site approaches.
• Rules: children live on the same site, at the same directory level or lower; don’t nest an index inside an index (the format has no tag for it, and no generator or search engine supports it); children may be gzipped (.xml.gz).
• Submit only the index — one submission covers all children. Submitting the children too is redundant, not harmful (Mueller: “you don’t really need to”).
• Splitting is for reporting, not crawl efficiency. It doesn’t change crawling or indexing; split by section/content type so you can read submitted-vs-indexed per segment in the Search Console Sitemaps report.

Official documentation

Primary-source documentation on sitemap index files and the limits behind them.

Google

• Manage large sitemaps with a sitemap index file — splitting past the limits, the sitemap index format, and the 500-index-files-per-site cap.
• Build and submit a sitemap — the 50,000-URL / 50MB-uncompressed limit, UTF-8, and absolute-URL rules that apply to every sitemap.
• Sitemaps overview — what a sitemap is and the “discovery, not a guarantee of indexing” framing.

sitemaps.org

• Sitemaps XML protocol — the canonical spec: the <sitemapindex> format, the 50,000-sitemaps / 50MB index limit, and the “an index file can not list other index files” rule.

Quotes from the source

On-the-record statements from Google and the sitemaps.org protocol. Each link is a deep link that jumps to the quoted passage on the source page.

Google — splitting and submission limits

• “If you have a sitemap that exceeds the size limits, you’ll need to split up your large sitemap into multiple sitemaps.” — Google, Manage large sitemaps. Jump to quote
• “You can submit up to 500 sitemap index files for each site in your Search Console account.” Jump to quote

sitemaps.org — the protocol size limits (see the footnote below for the no-nesting rule’s sourcing, which isn’t a standalone quote)

• “Sitemap index files may not list more than 50,000 Sitemaps and must be no larger than 50MB (52,428,800 bytes) and can be compressed.” — sitemaps.org protocol. Jump to quote

John Mueller, Google — splitting for monitoring, and submitting only the index

• “I generally recommend splitting a sitemap file into logical parts of your site so that you can monitor those parts individually (eg, category pages vs detail pages…). … It doesn’t change how Google crawls & indexes them, it’s really just so that you can track them better on your side.” Jump to quote
• “You can submit the individual ones, but you don’t really need to.” Jump to quote

Sitemap index — limits cheat sheet

The numbers that define your capacity

Fast facts

• A sitemap index lists sitemaps, not URLs — <sitemapindex> wrapping <sitemap> blocks (<loc> + optional <lastmod>).
• You need one once a single sitemap would exceed 50,000 URLs or 50MB, or to organize a large multi-section/region site.
• Children must be on the same site, at the same directory level or lower than the index.
• Children can be gzipped (.xml.gz).
• Don’t nest an index inside an index (no tag for it, not supported by any generator or engine).
• Submit only the index — it covers all children; submitting children too is redundant.
• Split by section/content type for reporting, not for crawl efficiency — it doesn’t change crawling/indexing.

How to split a sitemap index (split for what you measure)

The mental model that matters here: how you split doesn’t change crawling — it changes what you can monitor. Google crawls and indexes the same URLs whether they sit in one sitemap or fifty. So choose your split lines to match the segments you want to read independently in the Search Console Sitemaps report (submitted vs. indexed, per sitemap).

Split by content type

• /sitemaps/blog.xml, /sitemaps/products.xml, /sitemaps/categories.xml, /sitemaps/docs.xml.
• Best when different templates have different indexing behavior — e.g. thin product variants under-indexing while your blog sails through. You’ll see exactly which template is the problem.

Split by section

• One child sitemap per major site section or subfolder.
• Best for large sites where teams own different sections — each owner gets a clean coverage number for their area.

Split by region / language

• One child per locale (/sitemaps/en.xml, /sitemaps/de.xml, …).
• Best for international sites: you can spot a whole locale that isn’t getting picked up, separate from any hreflang issues.

The decision rule

• Ask: “If one of these segments were under-indexed, would I want to see it in isolation?” If yes, that’s a split line. If the answer is “I’d never analyze that separately,” don’t split there — you’re just making more files to maintain.

A migration use I rely on

• During a site migration I’ll keep a sitemap of the old URLs in the index for a while — not to get them indexed, but to watch them drop out of the index in GSC as the new URLs take over. The segment-level reporting is the whole point.

The crawl-efficiency angle people expect from splitting isn’t real. The reporting angle is, and it’s worth designing your index around.

A minimal valid sitemap index

This is the entire shape of a sitemap index file — a <sitemapindex> root, then one <sitemap> block per child sitemap, each with a <loc> and an optional <lastmod>. Children may be gzipped (.xml.gz); the 50MB cap is measured uncompressed.

<?xml version="1.0" encoding="UTF-8"?>
<sitemapindex xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <sitemap>
    <loc>https://www.example.com/sitemaps/blog.xml.gz</loc>
    <lastmod>2026-06-22</lastmod>
  </sitemap>
  <sitemap>
    <loc>https://www.example.com/sitemaps/products.xml.gz</loc>
    <lastmod>2026-06-22</lastmod>
  </sitemap>
  <sitemap>
    <loc>https://www.example.com/sitemaps/categories.xml.gz</loc>
    <lastmod>2026-06-22</lastmod>
  </sitemap>
</sitemapindex>

Rules baked into that example:

• Root is <sitemapindex> (not <urlset>) on the sitemaps.org/schemas/sitemap/0.9 namespace; the file is UTF-8.
• Each <loc> is a fully-qualified absolute URL on the same site, at the same directory level or lower than this index.
• <lastmod> is optional and describes when that child sitemap changed.
• Don’t add a <sitemap> entry pointing at another sitemap index — one level only.

How you submit it

You submit only this index file — one submission, and search engines follow it to every child sitemap. There’s no need to submit the children separately.

# robots.txt — point engines at the index (the Sitemap: line takes the index URL)
Sitemap: https://www.example.com/sitemap-index.xml

Then add the same index URL in Google Search Console (Sitemaps report) and Bing Webmaster Tools. That’s it — the children come along for the ride.

Tools for building and checking a sitemap index

• Google Index Checker — once you’ve submitted the index, use this to spot-check whether specific URLs from a child sitemap actually made it into Google’s index, rather than waiting on the aggregate Search Console number.
• Google Search Console — Sitemaps report — the primary place to watch a submitted index: fetch status per child sitemap, and submitted-vs-indexed counts you can read per segment if you split thoughtfully.
• Bing Webmaster Tools — Sitemaps — the equivalent report for Bing; submit the same index URL there too.
• Your sitemap generator / CMS plugin — most frameworks and SEO plugins build the index and child files for you automatically as your URL count grows; the manual XML in the Scripts tab is for when you need to see (or hand-build) the shape yourself.

Sitemap index pre-submission checklist

Run through this before you point Search Console or Bing Webmaster Tools at a new or restructured index:

• Every child sitemap is under 50,000 URLs and 50MB uncompressed (with headroom — don’t build right up to the ceiling).
• The index file lists only sitemaps, never another sitemap index.
• Every child <loc> lives on the same site, at the same directory level or lower than the index file.
• Index and children are valid XML, UTF-8, with the correct root element (<sitemapindex> for the index, <urlset> for each child).
• robots.txt has a Sitemap: line pointing at the index, not at one of the children.
• Your split lines (section, content type, or region) match something you’ll actually want to monitor separately in Search Console — don’t split arbitrarily.
• Only the index is queued for submission — you don’t also need to submit every child sitemap one by one.

Mistakes to avoid with a sitemap index

• Nesting an index inside an index. The format has no tag for it — a sitemap index’s <loc> only identifies a sitemap, Atom, RSS, or text file, never another index — and no generator or search engine supports it. Do instead: keep one level of indexing, and if you’re tempted to go deeper you almost certainly have room to reorganize your split within the 2.5-billion-URL ceiling a single index already gives you.
• Submitting every child sitemap individually on top of the index. Not harmful, just redundant — the index submission already pulls in every child it references. Do instead: submit the index alone in Search Console and Bing Webmaster Tools.
• Splitting sitemaps expecting a crawl-budget or ranking win. How you split doesn’t change how Google crawls or indexes your pages. Do instead: split purely for reporting — pick lines you actually want to monitor independently in the Sitemaps report.
• Pointing a child sitemap at a different host, subdomain, or a directory above the index. Search Console flags this as “URL not allowed.” Do instead: keep every child on the same site, at the index’s directory level or lower.
• Letting a sitemap grow past 50,000 URLs or 50MB uncompressed instead of splitting ahead of time. Do instead: split proactively once a section is approaching the limit, not after it’s already broken.

Common issues with a sitemap index

Symptom: Search Console shows “Couldn’t fetch” on the index. Likely cause: the index URL 404s, times out, or is blocked by robots.txt. Fix: open the exact index URL in a browser (or the Sitemap Validator) and confirm it returns 200 with valid XML before resubmitting.

Symptom: The index fetches fine, but one specific child sitemap shows an error. Likely cause: a <loc> inside that child points at a 404’d, non-canonical, or wrong-domain URL, or the child itself has malformed XML. Fix: open that child sitemap directly and spot-check its <loc> entries; fix or regenerate that file, then wait for the next fetch.

Symptom: “Sitemap index file can’t reference another sitemap index” (or the entry is silently ignored). Likely cause: you nested an index inside an index, which no generator or search engine supports — the format’s <loc> tag has no provision for pointing at another index file. Fix: flatten to one level — the top-level index should only ever point at sitemaps that list URLs, not at other indexes.

Symptom: “URL not allowed” on a child sitemap entry. Likely cause: that child lives on a different host/subdomain than the index, or sits above the index’s own directory path. Fix: move the child to the same site, at the same directory level or lower (cross-domain references only work when both domains are verified in Search Console — and for an ordinary single-site index you shouldn’t need that).

Symptom: An index or child sitemap gets rejected for size. Likely cause: it exceeds 50,000 URLs, or 50MB uncompressed for a sitemap / 50MB for the index file itself. Fix: split further — add another child sitemap (or, for a very large site, another index) rather than trying to squeeze more in.

Prove the new sitemap index actually took

Test: Load the index URL directly (browser or curl -I). Expected result: HTTP 200, valid XML, <sitemapindex> root. Failure interpretation: a 404/timeout here means Search Console can’t reach it either — fix this before anything else. Monitoring window: immediate. Rollback trigger: sustained non-200 response — revert to the prior sitemap setup.

Test: Submit the index in the Search Console Sitemaps report (or run it through the Sitemap Validator first). Expected result: status flips to a successful fetch and per-child sitemap rows appear. Failure interpretation: “Couldn’t fetch” means a URL, hosting, or robots.txt problem, not an indexing problem yet. Monitoring window: hours to a day for the first fetch. Rollback trigger: repeated fetch failures across resubmissions.

Test: Spot-check each child sitemap’s URL count against what your site actually has for that segment. Expected result: counts are in the right ballpark for that section/content type. Failure interpretation: a big mismatch usually means the generator is including stale, non-canonical, or duplicate URLs. Monitoring window: immediate, right after generation. Rollback trigger: none — fix the generator logic and regenerate.

Test: Check submitted-vs-indexed counts per sitemap in the Sitemaps report. Expected result: indexed count trends toward the submitted count for each segment over time. Failure interpretation: one segment stuck well below its submitted count points at a problem specific to that segment (thin content, duplication, noindex left on by mistake) rather than the index itself. Monitoring window: 2–4 weeks for the trend to be meaningful. Rollback trigger: a segment’s indexed count actively falling after the change, not just staying flat.

Test: Confirm robots.txt still carries the correct Sitemap: line. Expected result: the line resolves to the current index URL. Failure interpretation: a missing or stale line doesn’t break discovery for engines that already know your index, but it removes one of your discovery signals for anything crawling fresh. Monitoring window: immediate. Rollback trigger: line missing or pointing at a retired file — restore it.

Standing KPIs for a sitemap index

Metric: Submitted vs. indexed count, per sitemap segment. What it tells you: which section, content type, or region is under-indexed, instead of one blended site-wide number. How to pull it: the Search Console Sitemaps report, read per submitted sitemap. Benchmark / realistic range: no fixed target — there’s no honest universal number here. Healthy looks like the indexed count trending close to the submitted count for that segment; a persistent, large gap on one segment (and not the others) is the signal worth chasing, not a specific percentage. Cadence: weekly during a migration or a large rollout; monthly otherwise.

Metric: Sitemap fetch status, per index and per child. What it tells you: whether engines can actually read the files you’ve submitted at all — a precondition for everything else on this list. How to pull it: the status column in the Sitemaps report (or the Sitemap Validator for an on-demand check). Benchmark / realistic range: this one isn’t a range — “Success” is the only acceptable state; “Couldn’t fetch” or “Has errors” is a fail state to fix immediately, not something to tolerate at some rate. Cadence: check whenever you touch the sitemap generation code or add a new child; otherwise a monthly spot check.

Metric: URL count and file size per sitemap, against the limits. What it tells you: how much headroom you have before a segment needs splitting further. How to pull it: your sitemap generator’s own counts, or the Sitemap Validator. Benchmark / realistic range: stay comfortably under 50,000 URLs and 50MB uncompressed per file — leave real headroom rather than running up to the ceiling. Cadence: monitor as your URL count grows; re-split a segment once it’s approaching the limit, not after it’s already broken.

AI prompts for a sitemap index

Prompt: sanity-check a proposed split. Paste in a short description of your site’s sections (roughly how many URLs each has) and ask an AI to sanity-check your split lines before you build the index:

I'm building a sitemap index for a site with these sections and approximate
URL counts:
- Blog: <N> URLs
- Product pages: <N> URLs
- Category pages: <N> URLs
- <other sections>

I want to split these into child sitemaps under one sitemap index so I can
read submitted-vs-indexed coverage per section in Google Search Console.
Given these counts, suggest a sensible way to split them into child
sitemaps (staying well under 50,000 URLs and 50MB uncompressed per file),
and flag any section that's small enough it probably doesn't need its own
child sitemap.

Expect back: a proposed grouping of your sections into child sitemaps, with a note on any section too small to bother separating.

Prompt: review an existing sitemap index for structural mistakes. Paste in the raw XML of your sitemap index (or a representative excerpt) and ask for a structural review:

Here is my sitemap index XML:

<paste your <sitemapindex> XML here>

Check it against these rules and flag any violation:
1. The root element is <sitemapindex>, not <urlset>.
2. No <sitemap> entry points at another sitemap index file.
3. Every <loc> is a fully-qualified, absolute URL on the same site as this
   index.
4. No <loc> sits at a directory level above this index's own path.
List any entries that break these rules and explain which rule each one
breaks.

Expect back: a line-by-line list of any entries that violate the nesting or location rules, so you can fix them before resubmitting.

Resources worth your time

My related writing

• When Should You Worry About Crawl Budget? — where clean, complete sitemaps fit into crawl efficiency on large sites.
• Website Migration: The Pre- and Post-Launch Checklist — including keeping a sitemap of old URLs around to watch them drop out of the index in GSC.
• Enterprise Technical SEO — automation-first sitemaps and the submitted-vs-indexed diagnostic at scale.
• The Beginner’s Guide to Technical SEO — where sitemaps and discovery sit in the bigger picture.

Official

• Google — Manage large sitemaps with a sitemap index file.
• sitemaps.org protocol — the canonical <sitemapindex> spec and limits.

From others

• r/TechSEO — the community for sitemap, crawl, and indexing debugging.
• Bing Webmaster Tools — Submit a sitemap — Bing’s guidance on submitting sitemap index files and verifying them in Bing Webmaster Tools.
• Search Engine Journal — Sitemaps coverage — includes verbatim coverage of Mueller sitemap Q&As and crawl/indexing write-ups.
• Onely — Sitemap resources — technical SEO deep-dives from a crawling-focused agency; covers large-scale sitemap issues and indexation diagnostics.

Test yourself: Sitemap index

Five quick questions on what a sitemap index is and how to use one. Pick an answer for each, then check.

Sitemap index

A sitemap index is a sitemap of sitemaps — a single file that lists your other sitemap files instead of listing URLs directly. It's how large sites stay under the 50,000-URL / 50MB-per-sitemap limit while submitting just one file.

Related: Sitemap, XML sitemap

Sitemap index

A sitemap index file is a sitemap of sitemaps. Instead of listing page URLs, it lists other sitemap files — each in a <sitemap> block with a <loc> and an optional <lastmod>, all wrapped in a <sitemapindex> root element. You reach for one when a single sitemap would blow past the format’s hard limits (50,000 URLs or 50MB uncompressed, whichever comes first) or when you simply want to organize a large multi-section or multi-region site into separate files.

The capacity is enormous. A sitemap index can reference up to 50,000 child sitemaps, and each child can hold up to 50,000 URLs — so one index already covers 2.5 billion URLs. Google Search Console accepts up to 500 sitemap index files per site, which puts the theoretical ceiling at 1.25 trillion URLs. No real site approaches that; the practical takeaway is that you will never run out of sitemap capacity.

A few rules matter. The child sitemaps must live on the same site as the index and at the same directory level or lower. You don’t nest a sitemap index inside another sitemap index — the sitemaps.org protocol disallows it. And you submit only the index file: that one request pulls in every child sitemap it references, so there’s no need to submit the children separately.

Related: Sitemap, XML sitemap

Changelog