Sitemap URLs Missing From the Search Console Pages Report (2026)

Q: How do I see which sitemap URLs actually got indexed?

Open **Page indexing**, click the dropdown at the top, and choose **All submitted pages** or **Specific sitemap URL**. The Sitemaps report's discovered count never tells you this.

Q: Do I need lastmod, and does Google trust it?

It's optional but recommended. Google only honors `lastmod` when it's verifiably accurate. If every entry's `lastmod` is set to today's date on every build, Google notices and ignores the field site-wide — so emit a real last-modified timestamp per URL.

Your sitemap is submitted and shows Success, but its URLs never appear in the Pages report. The exact checks that find the cause, with current GSC menu paths.

Published: May 19, 2026 Updated: Jun 21, 2026 Author: AI Productivity Guide Team 🌐 查看中文版本

Your sitemap.xml returns 200, lists 800 URLs, and Search Console → Sitemaps shows the status Success with “Discovered pages: 800” — yet the Page indexing report seems to ignore almost all of them.

Fastest answer: “Discovered pages” in the Sitemaps report only means Google parsed that many URLs out of the XML. It is not an index count and it is not a queue. To see what Google actually did with your sitemap URLs, open Page indexing (left nav, under Indexing), then use the dropdown at the top of the report and switch from All known pages to All submitted pages — or pick Specific sitemap URL and choose your sitemap. That view shows exactly how many sitemap URLs are Indexed vs Not indexed, broken down by reason. Nine times out of ten the URLs are there but sitting under a reason like “Crawled - currently not indexed” or “Page with redirect,” not missing.

If the Sitemaps report itself shows 0 discovered pages (not a low count — literally zero), that is a different, simpler bug: the file is malformed, on the wrong property, or the URLs don’t match a canonical Google trusts. Both situations are covered below.

Symptoms

sitemap.xml returns 200 and lists URLs in the browser
Sitemaps report status is Success but “Discovered pages” is 0, or far below the real URL count
Page indexing report shows your sitemap URLs as Not indexed, or you cannot find them at all
A specific URL’s URL Inspection result says it is not known from any sitemap

Which bucket are you in?

What the Sitemaps report shows	Most likely cause	Jump to
Status Couldn’t fetch	robots.txt blocks the file, wrong URL, or an unresolved manual action	Cause 8
Success, Discovered pages = `0`	Malformed XML, BOM, relative `<loc>`, or http/https mismatch	Causes 1, 5, 7
Success, discovered count far below real count	Oversized sitemap truncated at 50,000 URLs	Cause 6
Success, discovered count correct, but Pages report empty	URLs not canonical, return 404/redirect, or wrong property	Causes 2, 3, 4
Everything looks right, just submitted	Processing lag — wait 2-3 days	”When this is not on you”

First, confirm it’s actually a problem

Before editing anything, prove where the URLs went. This one step resolves most “missing” reports because the URLs usually aren’t missing at all.

Search Console → Indexing → Page indexing.
Click the page-source dropdown at the top (default All known pages) and choose All submitted pages, or Specific sitemap URL → your sitemap.
Read the Why pages aren’t indexed table. If your URLs appear there under reasons like “Crawled - currently not indexed,” “Discovered - currently not indexed,” “Page with redirect,” “Alternate page with proper canonical tag,” or “Duplicate without user-selected canonical,” then the sitemap is working — Google read the URLs and made an indexing decision. That is an indexing problem, not a sitemap problem.

To check a single URL’s provenance: paste it into the URL Inspection tool, expand Page indexing, and look at Discovery. It lists the Referring sitemaps Google associates with the URL. If your sitemap is listed there, Google accepted it. If it says no sitemap was found, the URL form in your sitemap doesn’t match the URL Google chose to index — go to Cause 2.

Common causes

1. Sitemap uses http but the site is https (or vice versa)

<url><loc>http://yourdomain.com/page/</loc></url>

Google crawls URLs exactly as listed in the sitemap (per the official build-a-sitemap spec). If your site serves https and the sitemap says http, Google follows the redirect, indexes the https URL, and the http entry counts as a redirect rather than a clean match.

How to confirm:

curl -s https://yourdomain.com/sitemap.xml | grep "<loc>" | head -5
# Every URL must already be https://

2. Trailing slash, case, or www inconsistency vs the canonical

<url><loc>https://yourdomain.com/article</loc></url>

But your canonical tag is https://yourdomain.com/article/ (with slash). Google treats those as two different URLs and indexes whichever your rel="canonical" points to, not the sitemap string. This is the single most common reason a “discovered” URL never shows as a clean submitted page.

How to confirm. Sample 5 sitemap URLs and compare each against its own canonical:

for url in $(curl -s https://yourdomain.com/sitemap.xml | grep -oE 'https://[^<]+' | head -5); do
  canonical=$(curl -sL "$url" | grep -oE '<link rel="canonical" href="[^"]+"')
  echo "sitemap:   $url"
  echo "canonical: $canonical"
  echo "---"
done

They must match exactly — protocol, www. vs apex, case, and trailing slash all count.

3. The sitemap lives on a different property than the one you’re viewing

Your Search Console verifies https://yourdomain.com/, but the sitemap is at https://www.yourdomain.com/sitemap.xml. To a URL prefix property those are two different sites, so the sitemap’s URLs never roll up into the report you’re reading.

How to confirm. Search Console → Settings → Ownership verification / the property switcher at top left. Note whether the property is a Domain property (covers every subdomain and protocol) or a URL prefix property (covers only that exact prefix).

4. URLs in the sitemap return 404 or redirect

The sitemap lists a URL, but the crawl hits 404 or 301. A 404 is dropped; a 301 gets folded into its redirect target, so the listed URL is never the indexed one.

How to confirm:

for url in $(curl -s https://yourdomain.com/sitemap.xml | grep -oE 'https://[^<]+' | head -20); do
  status=$(curl -sI -o /dev/null -w "%{http_code}" "$url")
  echo "$status $url"
done

All should be 200. Any 301 / 404 needs fixing.

5. Malformed XML that Google silently truncates

The sitemap protocol is strict, and Google tolerates some breakage by reading only the valid prefix:

<?xml version="1.0" encoding="UTF-8"?> must be the very first line — no byte-order mark (BOM), no leading whitespace, no blank line.
The <urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9"> namespace is required.
Tag values must be entity-escaped (a raw & in a URL breaks the file).
The file must be UTF-8 encoded.

How to confirm. Open the file in a browser (a parse error shows immediately) and run it through a validator such as XML Sitemaps Validator. To catch a BOM:

curl -s https://yourdomain.com/sitemap.xml | head -c 3 | xxd
# A leading "ef bb bf" is a UTF-8 BOM and must be removed

6. Sitemap file too large

A single sitemap is capped at 50,000 URLs or 50 MB uncompressed (current limit, confirmed in Google’s June 2026 docs). Behavior past the cap is the trap:

Over 50,000 URLs: Google ignores everything after the first 50,000.
Over 50 MB: Google may reject the whole file.

Neither triggers a Search Console error — the status still reads Success with a discovered count lower than your real URL total. That mismatch is the tell.

Fix: split into a sitemap index plus child sitemaps (see Step 5).

7. sitemap-index references with relative paths

<sitemapindex>
  <sitemap><loc>./sitemap-1.xml</loc></sitemap>  <!-- relative path, rejected -->
</sitemapindex>

<loc> must be a fully-qualified absolute URL. Google crawls the value exactly as written, so a relative path resolves to nothing and the child sitemap is never read.

8. Status is “Couldn’t fetch”

If the Sitemaps report says Couldn’t fetch rather than Success, Google never read the file at all. Common reasons:

robots.txt blocks the sitemap path (Google respects robots.txt even for sitemaps).
The submitted URL is wrong or returns a non-200 status.
The site has an unresolved manual action — sitemaps are not processed while one is open (Search Console → Security & Manual Actions → Manual actions).

How to confirm. Open the sitemap URL in a private browser window, then check https://yourdomain.com/robots.txt for a Disallow rule that catches it. “Couldn’t fetch” can also be stale; if you already fixed access, click the sitemap row and re-submit.

Shortest path to fix

Step 1: Open sitemap.xml in a browser and a validator

Browser:  https://yourdomain.com/sitemap.xml   (expect structured XML, no error notice)
Validate: https://www.xml-sitemaps.com/validate-xml-sitemap.html

If the XML is broken, fix it before going further — nothing downstream matters until the file parses.

Step 2: Sample 5 URLs for canonical consistency

Run the canonical comparison script from Cause 2. Fix any mismatch in protocol, www. vs apex, case, or trailing slash. The durable fix is to unify the source: your sitemap generator and your canonical-tag renderer should call the same urlFor() helper so they can never drift.

Step 3: Confirm the sitemap is on the right property

Search Console → Settings, and check the property type:

Domain property (yourdomain.com): covers every subdomain, protocol, and path.
URL prefix property (https://yourdomain.com/): covers only that exact prefix.

If the sitemap lives on www.yourdomain.com but the property is https://yourdomain.com/ (no www), either switch to a Domain property or add a separate URL prefix property for the www host.

Step 4: Confirm every URL returns 200

Run the curl status script from Cause 4. For each problem URL:

301: put the final destination URL in the sitemap directly.
404: remove it from the sitemap.

Step 5: Split large sitemaps

<!-- sitemap-index.xml -->
<?xml version="1.0" encoding="UTF-8"?>
<sitemapindex xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <sitemap><loc>https://yourdomain.com/sitemap-articles.xml</loc></sitemap>
  <sitemap><loc>https://yourdomain.com/sitemap-pages.xml</loc></sitemap>
</sitemapindex>

Keep each child sitemap well under 50,000 URLs and 50 MB.

Step 6: Re-submit, then verify by filter

Search Console → Sitemaps → delete the stale entry → re-enter the URL → Submit. Then go to Page indexing, set the dropdown to Specific sitemap URL, and watch the Indexed count climb over the next few days.

How to confirm it’s fixed

Sitemaps report shows Success and “Discovered pages” equals (or is close to) your real URL count.
In Page indexing filtered to All submitted pages, the bulk of URLs are Indexed, and the few that aren’t sit under reasons you understand.
URL Inspection on a sample URL shows your sitemap under Page indexing → Discovery → Referring sitemaps, and the canonical Google selected matches your sitemap’s <loc>.

When this is not on you

A freshly submitted sitemap is fetched almost immediately, but processing the URLs inside takes time — usually a few days, longer for large or low-authority sites. If you submitted within the last 48-72 hours and the file validates, give it time before deeper digging.

Easy to misdiagnose

“Success” means every URL is queued for indexing. No — it only means the file parsed.
“Discovered pages” equals the indexed count. Completely different numbers: the first is URLs parsed from the sitemap; the second is what entered the index. Compare them via the Page indexing filter, not the Sitemaps report.
A sitemap is in effect the moment you submit it. Fetch is fast; crawl and indexing of its URLs take days.
A low discovered count means Google rejected the sitemap. Sometimes it just means the report hasn’t refreshed; re-check after a couple of days.

Prevention

Generate the sitemap from the same source of truth as your canonical tags (one shared urlFor() helper) so URL forms can’t drift.
Validate the sitemap in CI: well-formed XML, no BOM, URL count under the cap, and every <loc> returning 200.
Match URL form (protocol, www, trailing slash) to the canonical exactly.
Split any single sitemap over ~5,000 URLs into a sitemap index early.
After each deploy, curl the sitemap once to confirm it’s 200 and the URL count is what you expect.

FAQ

Q: My Sitemaps report says Success but Discovered pages is 0. What’s wrong? A: Google parsed zero valid URLs. Usual culprits: a BOM or whitespace before the XML declaration, a missing urlset namespace, relative <loc> values, or an unescaped &. Open the file in a browser to see the parse error, then validate it.

Q: How do I see which sitemap URLs actually got indexed? A: Open Page indexing, click the dropdown at the top, and choose All submitted pages or Specific sitemap URL. The Sitemaps report’s discovered count never tells you this.

Q: How many URLs can one sitemap hold? A: Up to 50,000 URLs or 50 MB uncompressed (June 2026). Past that, Google reads only the first 50,000; use a sitemap index for more.

Q: Do I need lastmod, and does Google trust it? A: It’s optional but recommended. Google only honors lastmod when it’s verifiably accurate. If every entry’s lastmod is set to today’s date on every build, Google notices and ignores the field site-wide — so emit a real last-modified timestamp per URL.

Q: Should I submit one sitemap per language? A: Either works. Per-language (or per-section) sitemaps make it far easier to monitor indexing separately via the Specific sitemap URL filter.

Tags: #SEO #Google #Search Console #Indexing #Troubleshooting #Sitemap