Google’s Sitemaps report in Search Console has quietly become a much narrower tool than the one most SEO guides describe. It tells you whether Google could fetch and parse your sitemap, when it last read it, and how many URLs it found inside. It no longer tells you how many of those URLs got indexed, and that single missing column is behind most of the confusion people run into.
If your mental model of this report came from the legacy Search Console, it is worth resetting. Below is what each field actually means today, how to read the statuses without over interpreting them, what the common errors are caused by, and how sitemap index files behave when your site outgrows a single file.
Where the report lives and what it shows
In the current Search Console, the left navigation groups reports. Expand Indexing and click Sitemaps. The screen has two halves: a submission box at the top and a table of previously submitted sitemaps underneath.
Google’s documentation lists the columns as Sitemap URL, Type, Submitted, Last read, Status, Discovered pages and Discovered videos. Here is what each one is actually telling you.
| Column | What it means | What it does not mean |
|---|---|---|
| Sitemap URL | The exact URL you submitted. Redirects are not followed. | Not a canonical version. If you moved the file, resubmit. |
| Type | Sitemap, Sitemap index, RSS, Atom or Unknown. | Unknown does not always mean broken, but check it. |
| Submitted | The date you last submitted it through this screen. | Not the last time Google looked at it. |
| Last read | The most recent successful fetch by Google. | Not a crawl of the URLs inside it. |
| Status | Success, Has errors, or Couldn’t fetch. | Success says nothing about indexing or quality. |
| Discovered pages | How many URLs Google parsed out of the file. | Not how many were crawled, and definitely not indexed. |
| Discovered videos | Video URLs parsed, when video markup is present. | Not video indexing status. |
The report itself displays at most 1,000 submission entries, which is only an issue for very large multi property setups.
Discovered is not indexed, and that is the whole point
The single most common misreading is treating Discovered pages as a health metric. It is a parsing count. If your sitemap lists 4,200 URLs and the report says 4,200 discovered, all that means is that the XML was valid and Google counted the entries.
To find out what Google actually indexed, open Indexing, then Pages. At the top of that report there is a filter for pages by sitemap. Select your sitemap and the entire Pages report, both the indexed count and the full list of reasons pages were excluded, now applies only to URLs from that file.
That view is far more useful than anything on the Sitemaps screen. It tells you how many submitted URLs are indexed, and it groups the rest into reasons such as Crawled currently not indexed, Discovered currently not indexed, Duplicate without user selected canonical, Alternate page with proper canonical tag, and Excluded by noindex tag.
Reading the three statuses honestly
Success means Google fetched the file and parsed it without errors. It is a statement about XML and HTTP, not about your content. A sitemap full of 404s can and will report Success.
Has errors means Google retrieved the file but hit parsing problems. Click into the row and Google lists the specific issues with line numbers. Common causes are unescaped ampersands in URLs, a stray byte order mark before the XML declaration, URLs on a different host than the sitemap, dates that are not valid W3C datetime, and tags from a namespace you never declared.
Couldn’t fetch means Google never got the file. In practice this is nearly always one of four things: the URL is wrong, robots.txt blocks it, the server returned a 4xx or 5xx, or a firewall or bot protection service is blocking Googlebot. Verify it yourself before assuming a Google problem:
curl -I https://example.com/sitemap_index.xml
curl -s https://example.com/robots.txt | grep -i sitemap
curl -s -A "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" \
-o /dev/null -w "%{http_code}\n" https://example.com/sitemap_index.xmlIf the last command returns anything other than 200 while a normal request returns 200, you are blocking Googlebot at the edge. That is a hosting or WAF setting, not a Search Console problem.
http to https or changed the file name and left a 301 in place, resubmit the final URL rather than relying on the redirect.Sitemap index files and the hard limits
A single sitemap may contain at most 50,000 URLs and may not exceed 50MB uncompressed. Past either limit you need a sitemap index: a file that lists other sitemap files. An index may itself reference up to 50,000 sitemaps.
<?xml version="1.0" encoding="UTF-8"?>
<sitemapindex xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
<sitemap>
<loc>https://example.com/sitemap-posts.xml</loc>
<lastmod>2026-08-28T09:14:00+00:00</lastmod>
</sitemap>
<sitemap>
<loc>https://example.com/sitemap-products.xml</loc>
<lastmod>2026-09-01T11:02:00+00:00</lastmod>
</sitemap>
</sitemapindex>Submit the index file, not the children. Search Console lists the index in the table and, once Google has read it, the individual child sitemaps appear as their own rows so you can see which section has a problem.
Also declare the sitemap in robots.txt. It costs one line and it is how search engines other than Google find it:
User-agent: *
Allow: /
Sitemap: https://example.com/sitemap_index.xmlHow often Google re reads a sitemap
Google does not publish a schedule, and anyone quoting a fixed interval is guessing. What is observable is that the frequency tracks how much Google values the site and how often the file genuinely changes. Busy news sites see their sitemaps read many times a day. A small brochure site may go a week or more between reads.
The Last read column is your evidence. If it is weeks stale on a site that publishes daily, the useful questions are whether the file’s lastmod values are honest, whether the server is slow or intermittently erroring, and whether the site is producing enough new content to justify frequent revisits.
Accurate lastmod matters more than most people think. Google has said it uses the value when it is consistently reliable, and ignores it when a site stamps every URL with today’s date on every regeneration. Many CMS plugins do exactly that. If yours does, either fix it or drop the element entirely; a missing lastmod is better than a lying one.
Troubleshooting
Discovered pages is far lower than the URL count in your file. Google stopped parsing at an error. Open the row for the specific issues, and validate the XML locally. A single unescaped & in a query string will truncate the parse.
Status flips between Success and Couldn’t fetch. This is an availability pattern, not a sitemap pattern. Check server logs for 5xx responses and look at whether your host rate limits crawlers during peak hours.
An old sitemap you deleted still shows in the report. Removing it from the report only stops Search Console tracking it. Make sure the file itself returns 404 or 410, otherwise Google may keep reading it.
The report says Success but nothing is getting indexed. The sitemap is doing its job; the problem is elsewhere. Go to Indexing, Pages, filter by that sitemap, and read the exclusion reasons. Thin content, duplicate canonicals and noindex tags are the usual culprits, and none of them show up on the Sitemaps screen.
You submitted a sitemap for URLs on another domain. Cross submission requires that both hosts be verified and the sitemap be discoverable from robots.txt on the target host. Otherwise Google ignores the entries. Keep sitemaps on the same host as the URLs they list. If your CMS generates the file for you, confirm the plugin is writing the live domain and not a staging hostname left over from a migration, a mistake we see often in WordPress site moves.
Frequently asked questions
Does a Success status mean my pages are indexed?
No. Success means Google fetched the file and parsed the XML without errors. Indexing is a separate decision made per URL. Check Indexing, Pages, filtered by that sitemap, to see how many submitted URLs are actually indexed and why the rest are not.
Why does the report no longer show an indexed count?
Google moved indexing reporting into the Pages report, where it can show the reason each URL was excluded rather than a bare number. Filtering the Pages report by sitemap gives you the same figure with far more diagnostic detail attached.
How many URLs can one sitemap contain?
Up to 50,000 URLs and up to 50MB uncompressed. Beyond that, split the file and reference the pieces from a sitemap index, which may itself list up to 50,000 sitemaps. Gzip compression counts against the uncompressed size, not the compressed one.
Should I submit sitemaps in Search Console or just list them in robots.txt?
Do both. The robots.txt line makes the file discoverable to every crawler. Submitting in Search Console is what gives you the report, the status, the parsing errors and the sitemap filter in the Pages report.
How often should I resubmit my sitemap?
You should not need to. Google rechecks submitted sitemaps on its own schedule. Resubmit only when the file’s URL changes, or after fixing a fetch or parsing error, when you want a fresh read rather than waiting for the next automatic one.
Do sitemaps help small sites?
Less than people assume. A site with good internal linking and a few dozen pages is fully discoverable without one. Sitemaps earn their value on large sites, on sites with weakly linked sections, and as a diagnostic surface in the Pages report.
The bottom line
Treat the Sitemaps report as a delivery receipt. It confirms the file arrived, was readable, and contained a certain number of URLs. It is genuinely good at that job, and it is the fastest way to catch a robots.txt block or a broken deployment. It was never designed to answer questions about indexing.
The moment your question becomes “why are these pages not in Google”, move to Indexing, Pages and use the sitemap filter. Google’s own Sitemaps report documentation is the reference for column definitions and error types, and the sitemaps.org protocol is the authority on the XML itself. If you are also chasing organic query data, our guide to finding search queries in Google Analytics 4 covers how Search Console data reaches your Analytics property.
