Search Console does not ignore the rest of a sitemap index. Google reads every child sitemap the index lists, and for an index the Discovered pages count covers all URLs in all child sitemaps. When the report suggests only one child was read, the other children usually break a location rule, are nested indexes or fail to fetch.
In technical SEO, a sitemap index is an XML file that lists the locations of other sitemap files; Google calls it a sitemap of sitemaps. A child sitemap is one of the files an index points to. The practical rule: submit only the sitemap index. Search Console then reads the children for you, and your job is to check each child's host, format and fetch status.
The question comes up often, most recently in an r/TechSEO thread titled "Google Search Console only reads 1 sitemap file in the sitemap index and ignores the rest?" (October 2026).
Do you need to submit every child sitemap, or only the sitemap index?
Submitting only the sitemap index is enough. Google fetches the index, reads the location of each child sitemap and then fetches those children on its own schedule. Google's John Mueller confirmed this on Reddit, as reported by Search Engine Journal in August 2025, saying the individual sitemaps do not need their own submission.
Submission does not force a crawl. Google's Build and submit a sitemap page says "submitting a sitemap is merely a hint", and Mueller added in the same exchange that "sitemaps don't guarantee that everything is recrawled immediately" and "there's no specific time for recrawling."
Submitting a child on its own is allowed and gives it its own row, which helps to monitor one section of a site. Google allows up to 500 sitemap index files per site in Search Console, and the Sitemaps report shows a maximum of 1,000 submitted requests, as of October 2026.
How you submit matters for what you see. Google accepts sitemaps through the Sitemaps report, the Search Console API and a Sitemap: line in robots.txt, but the report only lists sitemaps submitted through the report or the API. An index that Google found only through robots.txt does not appear as a row.
What does the Sitemaps report show for a sitemap index?
For a sitemap index, the Sitemaps report shows one row with the Type "Sitemap index", a Status, a Last read date and a Discovered pages count. Discovered pages for an index is the count of all URLs in all child sitemaps, so a count that is too low points to children Google has not parsed.
The Sitemaps report is the Search Console report that lists the sitemaps you submitted, with the fields Sitemap URL, Type, Submitted, Last read, Status, Discovered pages and Discovered videos, according to the Sitemaps report help page. Last read is the last time Google fetched the file, and it only appears when the fetch worked. Status has three values: "Success", "Has errors" and "Couldn't fetch".
Discovered pages is the number of page URLs Google parsed from the sitemap. It is not an indexing count: Google gives no guarantee that a discovered URL will be crawled or indexed. For an index, "See index coverage" includes the URLs from child sitemaps already crawled.
A simple rule turns the count into a diagnosis. Count the <loc> entries in each child sitemap and add them up. If Discovered pages equals the total, every child was parsed. If it equals the count of one child, the other children were not read or failed. Click the index row to open its details page and expand any errors listed there.
Which sitemap index limits and rules does Google enforce?
Google applies every sitemap rule to a sitemap index, plus a few of its own. Each child sitemap holds at most 50,000 URLs or 50MB uncompressed, one index lists at most 50,000 sitemaps, and every child must sit on the same site as the index, in the same or a deeper directory.
- Size per child sitemap. Google limits a sitemap to "50MB (uncompressed) or 50,000 URLs" on its Build and submit a sitemap page. The sitemaps.org protocol gives the same limit as 52,428,800 bytes and allows gzip, as long as the uncompressed file stays within it.
- Entries per index. A sitemap index may hold up to 50,000
loctags, per Google's sitemap index documentation. Above that, Search Console reports "Too many sitemaps". - Same site and directory. Child sitemaps must be hosted on the same site as the index and in the same directory or lower. Cross-site submission waives this. Cross-site submission is a setup in which you prove ownership of every site involved, through Search Console verification or a robots.txt reference.
- No nesting. The Sitemaps report help page states that "a sitemap index file can't list other sitemap index files, only sitemap files." The error appears as "Incorrect sitemap index format: Nested sitemap indexes".
- Dates. The
lastmodof an entry in the index identifies when that child sitemap file changed, in W3C Datetime format. Google useslastmodonly when it is "consistently and verifiably" accurate.
A valid index is short. Every loc is an absolute URL on the same host and protocol as the index file:
<?xml version="1.0" encoding="UTF-8"?>
<sitemapindex xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
<sitemap>
<loc>https://www.example.com/sitemaps/posts.xml</loc>
<lastmod>2026-10-08</lastmod>
</sitemap>
<sitemap>
<loc>https://www.example.com/sitemaps/products.xml.gz</loc>
<lastmod>2026-10-01</lastmod>
</sitemap>
</sitemapindex>
Why does Search Console seem to read only one child sitemap?
Search Console seems to read only one child sitemap when the other children fail a location rule or a fetch, when they sit outside the property you are looking at, or when Google has not reached them yet. The index row adds everything into one number, so each child needs its own check.
Host, protocol or directory mismatch. The sitemaps.org protocol requires all URLs to use the same protocol and host as the sitemap. A child on example.com listed in an index on www.example.com, an http child under an https index, or children on a CDN or storage bucket all break that rule. The help page describes "URL not allowed" as a sitemap that includes URLs "at a higher level or different domain than the sitemap file."
Property scope. A Domain property is a Search Console property that includes all subdomains and all protocols. A URL-prefix property only includes URLs that start with its exact prefix, so http:// and m. versions fall outside it, according to Google's property help page. Sitemaps submitted in one property are also not visible in another.
Fetch failures. A child that returns a 404 or 5xx, is blocked by robots.txt or has a typo in its loc gets a fetch error. In the Search Off the Record episode "Do sitemaps still matter?" (October 1, 2026), John Mueller and Martin Splitt explained that "Couldn't fetch" on a valid file can come from host load or from low crawl demand linked to perceived site quality. Crawl demand is how much Google wants to crawl a site, and the help page notes that higher quality content raises it.
Timing. Google tries to fetch an index as soon as you submit it, but crawling the children takes time. After failed fetches it retries for a few days, then stops.
Sitemap index troubleshooting table: which symptom points to which cause?
The fastest way to fix a sitemap index is to start from what the Sitemaps report shows and work back to the cause. The table maps each common symptom to its likely cause, the check that confirms it and the fix, using only behavior Google documents for Search Console.
| Symptom in the report | Likely cause | Check | Fix |
|---|---|---|---|
| Discovered pages equals the URL count of one child | Other children not parsed yet or failing | Count loc entries per child; open the index details page | Fix failing children, then wait for a new Last read date |
| "URL not allowed" | Child or its URLs on another host, protocol or a higher directory | Compare scheme, host and path of every loc with the index | Move children next to the index or set up cross-site submission |
| "Nested sitemap indexes" | The index lists another index | Open each child and look for a sitemapindex root tag | List the sitemaps directly, or submit the second index on its own |
| "Couldn't fetch" on a valid file | robots.txt block, wrong URL, host load or low crawl demand | Live URL Inspection test on the sitemap URL | Unblock Googlebot, return a 200, improve site quality |
| Child sitemap missing from the report | Found via robots.txt only, or submitted in another property | Check which property and method you used | Submit the index in the property that covers every child |
| Discovered pages high, few pages indexed | Discovery is not indexing | Open "See index coverage" for the index | Improve the pages and list canonical URLs only |
| "Too many sitemaps" | More than 50,000 entries in one index | Count sitemap entries | Split into several indexes, up to 500 per site |
How to verify a sitemap index: Search Console checks step by step
To verify a sitemap index, test the index and every child as Googlebot would see them before you look at the report. Fetch each file, compare each location with the index and the property, then submit the index and compare Discovered pages with the URL total you counted yourself.
- Fetch the index yourself. Open the index URL or request it with curl. It should return a 200 status, valid XML and a
sitemapindexroot tag. - Compare every child location. Each
locshould use the same protocol and host as the index and sit in the same or a deeper directory. - Fetch each child. Every child should return a 200 status, use a
urlsetroot tag and stay within 50,000 URLs and 50MB uncompressed. Write down its URL count. - Check robots.txt. Make sure no
Disallowrule covers the index or child paths for Googlebot. - Run a live URL Inspection test. Google's help page recommends a live test of the sitemap URL and checking that Page fetch shows success.
- Submit the index in the right property. In the Sitemaps report, paste the index URL into "Add a new sitemap" and click "Submit", in a property that covers every child.
- Compare the counts. Once Last read shows a date, compare Discovered pages with your total. A gap means at least one child was not parsed.
- Expand the errors and resubmit. Open the details page, fix what it lists and resubmit the index after big changes.
Do sitemaps still matter for discovery in AI search?
Sitemaps still matter for discovery, in classic search and beyond. In the October 2026 Search Off the Record episode, Google's Search Relations team said keeping auto-generated sitemaps enabled carries no downside, and noted that AI training crawlers use both XML sitemaps and RSS feeds to find content.
A sitemap index that Google reads in full gives every section of a site a chance to be found, which matters for content you want cited, not only ranked. Our guide to AI search engine optimization covers what else influences visibility in AI answers.
The same episode recommends listing clean, canonical URLs instead of parameter-tagged tracking URLs. For pages drafted with AI help, Google's AI content guidelines ask for a manual review before publishing. Once pages are indexed, the snippet decides the click, which the meta description character limit guide covers.
Common mistakes with a sitemap index in Search Console
The common mistakes with a sitemap index in Search Console come down to location, nesting and misreading the report. Each one makes child sitemaps look ignored or makes the numbers look worse than they are, and each has a fix you can apply in the sitemap generator or the property settings.
- Hosting child sitemaps on a CDN or another subdomain. Google treats them as a different site, so they fail the same-site rule. Move them next to the index or set up cross-site submission.
- Nesting one sitemap index inside another. Search Console rejects nested indexes. List the child sitemaps directly, or submit the second index on its own.
- Reading Discovered pages as indexed pages. Discovery only means Google parsed the URL. Use "See index coverage" to see what happened to the URLs.
- Mixing www, non-www, http and https. One mismatched
locis enough to break a child. Generate every location from the same canonical base URL. - Checking the wrong property. Sitemaps submitted in one property do not show in another. Use a Domain property or submit the index in the URL-prefix property that matches it exactly.
- Setting every lastmod to today. Google uses
lastmodonly when it is accurate, so a date that always changes gets ignored. Update it only when the content of the child sitemap changes.
