Sitemaps Report

TL;DR — The Sitemaps report is the spot in Google Search Console where you hand Google your sitemap and check that it read it. You paste in the sitemap URL, hit Submit, and the report tells you whether Google could fetch it and how many URLs it found inside. Important: getting Google to read your sitemap is not the same as getting your pages indexed.

What the Sitemaps report is

A sitemap is a list of your site’s URLs that you hand to search engines so they don’t have to find every page by following links. The Sitemaps report in Search Console is where you submit that list and watch what Google does with it.

For each sitemap you’ve submitted, the report shows four things:

• Type — is this a single sitemap, or a sitemap index (a sitemap of sitemaps)?
• Last read — the date Google last fetched the file.
• Status — did it work?
• Discovered URLs — how many URLs Google read out of the file.

How to submit a sitemap

1. Open Search Console and pick your property.
2. In the left menu, click Sitemaps.
3. Type your sitemap’s URL into the box (for example sitemap.xml).
4. Click Submit.

That’s it. Google adds it to the list and reads it. You only need to do this once per sitemap — Google re-checks it on its own afterward.

What the statuses mean

• Success — Google fetched and processed the sitemap with no problems.
• Has errors — Google got the file but found something wrong inside it.
• Couldn’t fetch — Google couldn’t even download the file (maybe it’s blocked, missing, or the server errored).

The thing most people get wrong

Submitting a sitemap does not get your pages indexed. It helps Google discover your URLs faster, but Google decides for itself what to crawl and what to keep. The “Discovered URLs” number is just how many URLs Google read from the file — not how many it indexed.

To see how many of those pages actually made it into Google, you check a different report (the Page Indexing report) and filter it by your sitemap. The Sitemaps report tells you Google read your list; Page Indexing tells you what happened next.

Want the full version — sitemap indexes, size limits, the “Couldn’t fetch” troubleshooting tree, and why the old ping trick is dead? Switch to the Advanced tab.

TL;DR — The Sitemaps report is a submission and diagnostic surface, not an indexing report. It confirms Google read your sitemap (or sitemap index), shows the type, last-read date, a status (Success / Has errors / Couldn’t fetch), and a Discovered URLs parse count. Submitting aids discovery but guarantees nothing — Google is explicit that there’s “no guarantee that a page URL discovered in a sitemap has been or will be crawled or indexed.” To see what got indexed, filter the Page Indexing report by sitemap. Per-file limits are 50MB uncompressed or 50,000 URLs; split bigger sites under a sitemap index. Keep lastmod accurate — faking it gets the signal ignored — and forget the old ping endpoint, which now 404s.

What the report actually is

The Sitemaps report is where you submit sitemaps and monitor how Google processes them. Google’s own framing keeps it modest: “‘Submitting’ a sitemap means telling Google where to find the file on your site.” That’s the whole job — it points Google at a file. Everything else in the report is feedback about whether Google could read that file and what it found inside.

What it is not is an indexing report. I’ll keep coming back to this because it’s the mistake I see most: the report living next to “Indexing” in the Search Console menu makes people read “Discovered URLs” as “indexed pages.” It isn’t.

How to submit — and the other ways to register a sitemap

In the UI: Search Console → Sitemaps → paste the sitemap URL → Submit. Done.

But Search Console isn’t the only way to make Google aware of a sitemap. You can also point to it from a Sitemap: line in your robots.txt, which any crawler can read. The thing you should not still be doing is hitting the old unauthenticated ping endpoint (https://www.google.com/ping?sitemap=…) — Google deprecated it in June 2023 and it now returns a 404. Plenty of plugins and guides still tell you to ping; that code does nothing now (it just 404s — it won’t harm your site, it’s simply useless). The freshness signal that replaced pinging is an accurate lastmod (more on that below).

Resubmitting, deleting, and the API

You don’t need to resubmit a sitemap on every deploy. Once it’s in the report, Google recrawls it on its own schedule, and a one-off hiccup — a timeout, a transient 5xx — tends to clear itself on the next attempt without you doing anything. Resubmit deliberately in two cases: you made a large change to the sitemap’s contents (a big batch of new URLs, a restructure), or you fixed a persistent fetch or content error and want Google to pick it up sooner than the normal schedule would.

Deleting a sitemap from the report only removes that row from your dashboard — Google doesn’t forget the file or the URLs it listed just because you deleted the entry. If the goal is to stop Google from accessing, crawling, or indexing something, deleting the sitemap row is the wrong tool; reach for the control built for that job (a robots.txt block, noindex, a removal request, or authentication).

Everything the report does — list, fetch status, submit, delete — is also available through the Search Console Sitemaps API, which is the way to go if you’re automating submission from a CMS or build pipeline instead of clicking through the UI. It requires the same owner/verified-user permissions as the UI.

One scoping note that trips people up: this report only shows sitemaps submitted through the report itself or the API. If Google found your sitemap another way — most commonly a Sitemap: line in robots.txt — Google can still read and use it, but it won’t show up as a row here. The report is also scoped to the current property: if you’ve split https:// and www/non-www (or different subdomains) into separate Search Console properties, a sitemap submitted to one won’t appear in another’s report even though it’s the “same” site to a visitor.

Submitting a sitemap index (and why)

You can submit a single sitemap or a sitemap index — a sitemap that lists other sitemaps. The report shows the type for each: Sitemap, Sitemap index, RSS, or Atom.

You reach for an index whenever you split your URLs across multiple files, which you’re forced to do past the size limits below. A sitemap index also gives you cleaner reporting: split by section (products, blog, categories) and you can read discovery and indexing per section instead of as one undifferentiated blob.

Supported formats

Google supports the formats defined by the sitemaps protocol. The practical trade-offs:

If you need image, video, or news metadata in the sitemap, you need XML. Whatever the format, the file must be UTF-8 encoded with absolute, fully-qualified URLs.

Reading the report

Four columns do the work:

• Type — Sitemap, Sitemap index, RSS, or Atom.
• Last read — when Google last fetched the file. Stale here can mean Google hasn’t bothered re-reading (often fine) or can’t reach it.
• Status — “Success: The sitemap was loaded and processed successfully with no errors. Has errors: The sitemap could be fetched, but has one or more errors. Couldn’t fetch: The sitemap could not be fetched for some reason.” Note the split, because it tells you where to start troubleshooting: Has errors means Google got the file but choked on the contents — fetch the file yourself and validate its XML/text syntax and entries. Couldn’t fetch means it never got the file at all — check reachability first (a robots.txt block, 404/5xx, redirect, wrong content-type, or timeout) before you touch the file’s syntax. Either way, a status flip to Success only tells you the file is readable again — check the Page Indexing report (filtered by this sitemap) to see whether the affected URLs have actually caught up downstream.
• Discovered URLs — “The number of page URLs that were parsed from the sitemap. If this is a sitemap index, the number is the count of all URLs in all child sitemaps.” This is a parse count, full stop. If your sitemap also lists videos, Google reports those separately as Discovered videos — same idea, a parse count for video entries, and just as much not a guarantee that the specific video Google indexed is the one your sitemap pointed to.

The big caveat: discovery is not indexing

This is the line to tape to your monitor. Google, in the Sitemaps report documentation itself: “There is no guarantee that a page URL discovered in a sitemap has been or will be crawled or indexed by Google.” And in the broader Sitemaps overview: “A sitemap helps search engines discover URLs on your site, but it doesn’t guarantee that all the items in your sitemap will be crawled and indexed.”

So “Discovered URLs: 4,812” tells you Google parsed 4,812 URLs out of your file. It tells you nothing about how many are indexed. For that, you go next door.

Connecting to Page Indexing and URL Inspection

The single most useful move in this whole workflow is under-documented: “You can filter the Page indexing report by sitemap to see how many page URLs in this sitemap have been indexed.” That filter is how you measure the submitted-vs-indexed gap — submit a clean sitemap of only the URLs you want indexed, then read the Page Indexing report scoped to that sitemap and you’ve got a tidy “of the things I asked for, here’s what got in, and here’s why the rest didn’t” view.

For a single URL, the URL Inspection tool gives you crawl, render, index, and canonical status. The mental model: Sitemaps report says Google read your list; Page Indexing and URL Inspection say what happened after.

Size limits and the sitemap index

The hard numbers:

• “All formats limit a single sitemap to 50MB (uncompressed) or 50,000 URLs.”
• “If you have a larger file or more URLs, you must break your sitemap into multiple sitemaps,” and then optionally wrap them in a sitemap index file.
• A sitemap index file “may have up to 50,000 loc tags” — i.e. it can list up to 50,000 child sitemaps.
• “You can submit up to 500 sitemap index files for each site in your Search Console account.”

Each child sitemap is still individually capped at 50MB / 50,000 URLs. So the ceiling is large but finite — and it’s why automated, programmatically-split sitemaps beat anything hand-maintained.

Getting lastmod right

lastmod is the field people abuse, and it backfires. Google: “The <lastmod> value should reflect the date and time of the last significant update to the page.” It’s used to help schedule recrawls of URLs Google already knows about — so it’s a real signal, which is exactly why faking it doesn’t pay.

John Mueller has said repeatedly that setting every page’s lastmod to today isn’t an SEO hack — Google trusts a site’s lastmod more or less all-or-nothing, so inaccurate dates get the whole signal distrusted and ignored, and your genuinely-updated pages get harder to spot. The whole point of the freshness signal is wasted if the dates can’t be believed. Set lastmod from your real last-modified timestamp, automatically, and leave it alone.

Common mistakes

• The sitemap is blocked. If robots.txt disallows the sitemap’s path, or the URL 404s/5xx/redirects/times out or serves the wrong content-type, you’ll see Couldn’t fetch. Walk that list top to bottom.
• Listing URLs you don’t actually want indexed. Noindexed, non-canonical, or redirected URLs in a sitemap send mixed signals — the sitemap says “index this,” the page says “don’t.” List only canonical, indexable, 200-status URLs.
• Treating exclusion as removal. Leaving a URL out of the sitemap does not deindex it. Use noindex (with crawling allowed) or a removal — exclusion from a sitemap is not a deindexing tool.
• Trusting <priority> / <changefreq>. Google ignores both. Don’t spend time tuning them.

A quick word on Bing while we’re here: Bing Webmaster Tools has its own sitemap submission, and Bing (plus Yandex and others) also supports IndexNow for pushing changed URLs instantly — which Google does not use for general pages. Different plumbing, same idea: tell the engine where things are and what changed.

AI summary

A condensed take on the Advanced version:

• The Sitemaps report = submit + diagnose, not index. You submit a sitemap (or sitemap index) and it shows Type, Last read, Status, and Discovered URLs.
• Discovered URLs is a parse count — URLs read out of the file (all children if it’s an index), not indexed pages.
• Three statuses: Success (fetched + processed clean), Has errors (fetched but bad contents), Couldn’t fetch (never downloaded).
• Submitting helps discovery, guarantees nothing. Google: “no guarantee that a page URL discovered in a sitemap has been or will be crawled or indexed.”
• To see what got indexed, filter the Page Indexing report by sitemap; use URL Inspection for a single URL.
• Formats: XML (most versatile), RSS/Atom, plain text (URLs only). UTF-8, absolute URLs.
• Limits: 50MB uncompressed or 50,000 URLs per file; a sitemap index lists up to 50,000 child sitemaps, 500 index files per property.
• Keep lastmod accurate — faking it gets the signal distrusted (Mueller).
• The ping endpoint is dead (deprecated 2023, now 404s); submit via Search Console or a robots.txt Sitemap: line instead.
• Resubmit only for a reason — a large content change or a fixed persistent error; Google recrawls submitted sitemaps on its own otherwise.
• Deleting a sitemap from the report removes the row, not Google’s knowledge of the file or its URLs; use robots.txt/noindex/removal for that.
• The report is scoped to submission method and property — robots.txt-only discovered sitemaps and sitemaps submitted to a different property variant won’t show up here, even though Google can still use them. Everything’s also available via the Sitemaps API for automation.

Official documentation

Primary-source documentation, all from Google.

• Sitemaps report (Search Console Help) — the report itself: how to submit, the type/status columns, and Discovered URLs.
• Sitemaps overview (Search Central) — what a sitemap is and the discovery-not-indexing caveat.
• Build and submit a sitemap (Search Central) — supported formats, the 50MB/50,000-URL limits, UTF-8, and lastmod.
• Manage your sitemaps with sitemap index files (Search Central) — splitting large sitemaps; the 50,000-child and 500-index-file limits.
• Sitemaps ping endpoint is going away (Search Central Blog, June 2023) — the ping deprecation and why lastmod replaces it.
• Search Console Sitemaps API — list, get, submit, and delete sitemaps programmatically instead of through the UI.

Quotes from the source

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

Google — what submitting and the report mean

• “‘Submitting’ a sitemap means telling Google where to find the file on your site.” — Google Search Console Help, Sitemaps report. Jump to quote
• “Success: The sitemap was loaded and processed successfully with no errors. Has errors: The sitemap could be fetched, but has one or more errors. Couldn’t fetch: The sitemap could not be fetched for some reason.” — Google Search Console Help, Sitemaps report. Jump to quote
• “The number of page URLs that were parsed from the sitemap. If this is a sitemap index, the number is the count of all URLs in all child sitemaps.” — Google Search Console Help, Sitemaps report. Jump to quote

Google — discovery is not indexing

• “There is no guarantee that a page URL discovered in a sitemap has been or will be crawled or indexed by Google.” — Google Search Console Help, Sitemaps report. Jump to quote
• “A sitemap helps search engines discover URLs on your site, but it doesn’t guarantee that all the items in your sitemap will be crawled and indexed.” — Google Search Central, Sitemaps overview. Jump to quote
• “You can filter the Page indexing report by sitemap to see how many page URLs in this sitemap have been indexed.” — Google Search Console Help, Sitemaps report. Jump to quote

Google — formats, limits, and lastmod

• “XML sitemaps are the most versatile of the sitemaps formats.” — Google Search Central, Build and submit a sitemap. Jump to quote
• “All formats limit a single sitemap to 50MB (uncompressed) or 50,000 URLs.” — Google Search Central, Build and submit a sitemap. Jump to quote
• “You can submit up to 500 sitemap index files for each site in your Search Console account.” — Google Search Central, Manage your sitemaps with sitemap index files. Jump to quote
• “The <lastmod> value should reflect the date and time of the last significant update to the page.” — Google Search Central, Build and submit a sitemap. Jump to quote

Submitting a sitemap — checklist

Run this once when you set up a property, then again any time you add or rebuild a sitemap:

• The sitemap loads in a browser at a stable, absolute URL (200 status, no redirect).
• robots.txt does not disallow the sitemap’s path.
• The file is UTF-8 encoded with absolute, fully-qualified URLs.
• It lists only canonical, indexable, 200-status URLs — no noindexed, redirected, or non-canonical pages.
• Each file is under 50MB uncompressed and 50,000 URLs (split into a sitemap index if not).
• lastmod reflects real last-update timestamps (and isn’t bulk-set to today).
• Submitted in Search Console → Sitemaps (or the Sitemaps API if automated), and referenced from a Sitemap: line in robots.txt.
• Submitted to the correct property — check the report if you run separate https:///www or subdomain properties.
• Status reads Success (not Has errors / Couldn’t fetch).
• Discovered URLs (and Discovered videos, if applicable) roughly matches the count you expect.
• Page Indexing report filtered by this sitemap to read the submitted-vs-indexed gap.
• Resubmit only after a large content change or a fix to a persistent error — not on every deploy.

Sitemaps report — cheat sheet

Statuses

Columns

• Type — Sitemap · Sitemap index · RSS · Atom
• Last read — date Google last fetched the file
• Discovered URLs — count of URLs parsed from the file (all children if an index) — not indexed pages. Video entries get their own Discovered videos parse count.

Limits

• Per file: 50MB uncompressed or 50,000 URLs
• Sitemap index: up to 50,000 child sitemaps
• Per property: up to 500 sitemap index files

Fast facts

• Submitting aids discovery; it does not guarantee crawl or index.
• “Discovered URLs” ≠ indexed — filter Page Indexing by sitemap to see indexed.
• Ping endpoint (/ping?sitemap=): deprecated since 2023, now 404s.
• Submit via Search Console or robots.txt Sitemap: line.
• The report only lists sitemaps submitted via the report/API — robots.txt-only discovery doesn’t add a row. It’s also scoped to the current property.
• Deleting a sitemap removes the row, not Google’s memory of the file or URLs.
• Automate submission with the Sitemaps API instead of the UI if scripting it.
• <priority> and <changefreq>: ignored by Google.
• Removing a URL from the sitemap does not deindex it.

The mental models

1. Three surfaces, three questions. Keep the reports in their lanes and the confusion disappears:

• Sitemaps report → Did Google read my list?
• Page Indexing report (filtered by sitemap) → How many of those URLs got indexed, and why not the rest?
• URL Inspection → What happened to this one URL?

2. Discovered ≠ indexed. “Discovered URLs” is a parse count. It rises when Google reads more URLs from your file; it says nothing about indexing. Never report it as an indexing number.

3. Has errors vs Couldn’t fetch. The fork is “did Google get the file?” Couldn’t fetch = a fetch/access problem (robots block, 404, 5xx, redirect, wrong content-type, timeout) — fix reachability first. Has errors = Google got it but the contents are malformed — fix the file.

4. The sitemap is a request, not a guarantee. You’re saying “these are the URLs I’d like considered.” Make that request clean: only canonical, indexable URLs, with honest lastmod. A clean sitemap of exactly the URLs you want indexed turns the Page-Indexing-filtered-by-sitemap view into a precise scorecard.

5. Automate the file, don’t hand-maintain it. Generate sitemaps from your known canonical URLs so they self-update and stay inside the size limits — splitting into a sitemap index as you grow. Hand-edited sitemaps drift out of sync with the site, which is how noindexed and redirected URLs end up listed.

6. Statuses are snapshots, not verdicts. Couldn’t fetch and Has errors describe the last fetch attempt, not a permanent state. Fix the underlying problem — reachability for Couldn’t fetch, file contents for Has errors — and Google’s normal recrawl schedule picks it up on its own. Resubmit only to prompt an earlier check, after a large content change or once you’ve fixed a persistent error.

Tools for submitting and diagnosing sitemaps

• Google Search Console — Sitemaps report — submit sitemaps and read type, last-read, status, and Discovered URLs.
• Google Search Console — Page Indexing report — filter by submitted sitemap to see how many of those URLs are indexed (and why the rest aren’t).
• URL Inspection (GSC) — per-URL crawl, render, index, and canonical status.
• Bing Webmaster Tools — Bing’s own sitemap submission; also supports IndexNow for pushing changed URLs (Google does not use IndexNow for general pages).
• Your CMS / sitemap generator — the file should be generated automatically from canonical URLs so it self-updates and stays within the 50MB / 50,000-URL limits; large sites should split under a sitemap index.

Sitemap practices that create bad signals

Reporting Discovered URLs as indexed pages

Why it fails: Discovered URLs is the number Google parsed from the sitemap, not the number it indexed.

Do instead: Filter the Page Indexing report by that sitemap and report indexed and excluded URLs from the downstream index view.

Submitting noindexed, redirected, or non-canonical URLs

Why it fails: The sitemap asks Google to consider a URL while the URL or another signal says not to index that version.

Do instead: Generate the file from canonical, indexable URLs that return 200 and remove entries when their intended state changes.

Updating every lastmod value to today

Why it fails: A timestamp that does not represent a significant page update makes the freshness signal unreliable.

Do instead: Populate lastmod from the actual content-update timestamp and leave unchanged URLs unchanged.

Hand-maintaining large sitemap files

Why it fails: Manual lists drift, exceed file limits, and retain URLs that were redirected, canonicalized, or removed.

Do instead: Generate child sitemaps automatically and organize them under a sitemap index when a file approaches 50MB uncompressed or 50,000 URLs.

Calling the retired sitemap ping endpoint

Why it fails: Google’s old unauthenticated ping endpoint was deprecated and now returns 404.

Do instead: Submit in Search Console or declare the sitemap with a Sitemap: line in robots.txt.

Removing a URL from the sitemap to deindex it

Why it fails: Sitemap omission is not a removal directive; Google can continue to discover and index the URL elsewhere.

Do instead: Use a crawlable noindex, a 404/410, authentication, or the appropriate removal process for the URL’s intended state.

Prove a sitemap change worked

Test the file response and format

• Test to run: Fetch the submitted sitemap URL and validate the generated file’s encoding, absolute URLs, and XML or text syntax.
• Expected result: The URL returns 200, exposes the intended sitemap content, and stays below the format’s file and URL limits.
• Failure interpretation: A redirect, access rule, server error, bad encoding, or malformed payload can prevent Google from processing the file.
• Monitoring window: Immediate after deployment and cache refresh.
• Rollback trigger: Revert the generator change if it makes the sitemap unreachable, malformed, or unexpectedly drops a valid section.

Test Search Console processing

• Test to run: Open Search Console → Sitemaps after submitting the exact file or index URL.
• Expected result: Status becomes Success, Last read advances after Google fetches it, and Discovered URLs is close to the count produced by your generator.
• Failure interpretation: Couldn’t fetch points to access or response trouble; Has errors means Google downloaded the file but found content problems.
• Monitoring window: Check after Google next reads the file; use the server response as the immediate deployment signal.
• Rollback trigger: Roll back if a new release changes a previously successful sitemap to Couldn’t fetch or introduces widespread parse errors.

Test the intended URL set downstream

• Test to run: Filter the Page Indexing report by the changed sitemap and inspect a sample of added and removed URLs with URL Inspection.
• Expected result: Added URLs are canonical and indexable, removed URLs are absent for an intentional reason, and no sitemap entry conflicts with its page state.
• Failure interpretation: The generator is sourcing the wrong inventory or pages carry conflicting canonical, status, or robots directives.
• Monitoring window: Evaluate after Google recrawls the changed URLs; sitemap discovery is not proof of indexing.
• Rollback trigger: Revert or correct the feed when the new sitemap adds large sets of redirected, noindexed, non-canonical, or erroring URLs.

Test yourself: Search Console Sitemaps report

Five quick questions on submission, statuses, limits, and indexing. Pick an answer for each, then check your result.

Sitemaps report

The Google Search Console report where you submit sitemaps and watch how Google processes them — type, last read date, status, and how many URLs were discovered. It confirms Google read your list; it doesn't prove anything got indexed.

Related: Google Search Console, Index Coverage Report, XML sitemap

Sitemaps report

The Sitemaps report in Google Search Console is where you submit a sitemap (or a sitemap index) and monitor how Google processes it. For each sitemap it shows the type, the date Google last read the file, a processing status, and a count of how many URLs Google parsed from it. As Google’s documentation puts it, “‘Submitting’ a sitemap means telling Google where to find the file on your site.”

The single most important thing to understand is that this is a submission-and-diagnostic surface, not proof of indexing. The “Discovered URLs” number is a parse count — URLs read out of the file — not a count of indexed pages. Submitting a sitemap helps Google discover URLs, but it never guarantees crawling or indexing.

To see what actually happened after discovery, pair it with its sibling reports: the Page Indexing report (which you can filter by submitted sitemap) tells you how many of those URLs got indexed and why the rest didn’t, and the URL Inspection tool gives you per-URL crawl, render, and canonical status.

Related: Google Search Console, Index Coverage Report, XML sitemap

Changelog