Sitemap Valid but Pages Not Indexed? How to Find Which Ones

Search Console says your sitemap is valid. Zero errors, zero warnings, a recent read date, and a URL count that matches the file. Your pages still are not in Google.

Both things are true at once, and they are not in conflict, because a valid sitemap only proves the file parses. It says nothing about whether the URLs inside it are indexed. To find the gap you have to check the URL list against the index itself, which is a different question from the one Search Console just answered.

Why a valid sitemap tells you nothing about indexing

Sitemap validation checks the file: is the XML well-formed, are the URLs absolute and on the right host, is it within Google's size limits, are the optional tags in a format Google can read. Pass all of that and you get "Valid". Every one of those checks can pass on a sitemap listing 50,000 pages Google has never indexed.

Google is explicit about what the file is. A sitemap is a hint about which URLs exist on your site. It is not a request to index, and Google does not guarantee it will crawl or index every URL you list.

The confusion is made worse by the number sitting beside your sitemap in the report. That count is how many URLs Google read out of the file. It rises the moment you add URLs, whether or not any of them ever reach the index. The sitemaps report does not publish an indexed count anywhere, so there is no line in it that answers the question you actually have.

We inspected all 79 URLs in our own sitemap

Rather than describe the gap in the abstract, here is ours, measured on 25 August 2026.

Search Console reports our sitemap as Valid, 0 errors, 0 warnings, 79 URLs, last read that morning. We then ran every one of those 79 URLs through the URL Inspection API and recorded the coverage state Google returned for each.

72 were indexed. 7 were not.

URL	Status Google returned	Last crawled
/tools/bulk-redirect-checker	URL is unknown to Google	Never
/review/rapid-index-checker	URL is unknown to Google	Never
/tools/bulk-http-status-checker	Discovered – currently not indexed	Never
/tools/deindex-cause-diagnostic	Discovered – currently not indexed	Never
/features/bulk-url-category-check	Discovered – currently not indexed	Never
/review	Discovered – currently not indexed	Never
/about	Crawled – currently not indexed	2026-08-23

Nothing about that sitemap is broken. It validates, Google reads it daily, and the URL count is exactly right. Just under 9% of what it lists is missing from the index anyway.

Three details there matter more than the headline number.

Six of the seven had never been crawled. Not crawled and rejected. Never fetched at all. Sitting in a sitemap Google reads every day did not get them fetched.

Two were unknown to Google entirely. Google held no record of those URLs, on a day it had already downloaded the sitemap listing them. That is the clearest demonstration available that reading a sitemap and acting on it are separate events.

One had just been crawled and turned down. /about was fetched on 23 August and is still not indexed. That is a different problem with a different fix from the other six, and the only reason we know it is different is that we asked per URL.

We publish our own numbers here whether they flatter us or not, including a 97% impressions collapse we measured during the August 2026 rollout. This one does not flatter us either. It is simply what a healthy, valid sitemap actually looks like underneath.

What each status means, and where the fix lives

Once you have the list of missing URLs, each one carries a status naming the cause. Do not treat them as one problem. A URL blocked in robots.txt and a URL Google crawled and declined need opposite responses.

Status	What it means	Where the fix is
URL is unknown to Google	Google holds no record of this URL at all	Internal links from pages that already get crawled
Discovered – currently not indexed	Google knows it exists but has not fetched it	Crawl priority and server capacity
Crawled – currently not indexed	Fetched, then not kept	Usually value, not technical setup
Duplicate without user-selected canonical	Google grouped it with another page and chose that one	Canonical tags
Alternate page with proper canonical tag	Working as intended: you pointed it elsewhere	Nothing, unless the canonical is wrong
Excluded by 'noindex' tag	A meta robots tag or header is keeping it out	Your CMS or template (check it)
Blocked by robots.txt	Googlebot is not allowed to fetch it	Your robots file (check it)
Soft 404	Returns 200 but reads as empty or missing	Content, or the correct status code
Page with redirect	The URL redirects, so it is not the indexable one	Your sitemap: list destinations, not redirects

Two of those are not problems at all. "Alternate page with proper canonical tag" means your canonical is being honoured. "Page with redirect" on a URL that is supposed to redirect is correct behaviour, and the only thing worth fixing is that the redirecting URL is in your sitemap in the first place.

If you are not sure which of the nine you are looking at, the seven reasons Google is not indexing a site walks the diagnosis in priority order.

Why Search Console will not show you the whole picture

This is the part the guides to these statuses leave out, and it is why the reconciliation below is harder than it sounds.

The report runs behind. Search Console's indexing data is a few days old and the underlying state changes continuously, so when you open the report you are reading a description of last week. A page that dropped out on Monday will not show as dropped until later in the week. It is why almost nobody discovers deindexing in Search Console. They discover it in their traffic, then confirm it in Search Console afterwards.

The examples are a sample, not an inventory. The Page indexing report shows example URLs per status, not every URL in that state. On a small site the sample and the inventory are the same thing. On a 20,000-page programmatic site they are not, and the report quietly stops being a list of your problems and becomes a taste of them. You cannot fix what was never sampled, and nothing tells you what got left out.

The bulk workaround has a hard ceiling. The URL Inspection API is the documented way around the sampling problem, and it is capped at 2,000 inspections per property per day. It also only works on properties you have verified, so it is no help at all for auditing a client site you do not have access to yet, or a domain you are thinking about buying.

None of this is a reason to ignore Search Console. It is a reason not to mistake it for the inventory. It tells you reliably what kinds of problems you have. It will not reliably tell you every URL that has them, or tell you today.

How to reconcile your sitemap against the index

The method does not depend on any particular tool:

1. Get the URL list out of the sitemap, including every child file if you use a sitemap index. This list is your claim about what should exist.
2. Remove the URLs you excluded on purpose. Anything that 404s, redirects, canonicals elsewhere or carries a noindex is not a Google problem. It is a sitemap hygiene problem, and it should not be in the file.
3. Check what is left against the live index. This is the step that answers the actual question.
4. The difference is your list. Not statuses in aggregate, specific URLs.

Steps 2 and 3 are different checks, and it is worth being blunt about which of our tools does which, because the naming does not make it obvious.

Our sitemap checker does step 2. It finds your sitemap, validates it, then live-tests the URLs for HTTP status, redirects, robots.txt blocks and noindex headers. It catches the self-inflicted exclusions, the URLs you are asking Google to index while simultaneously telling it not to. It does not query Google's index, and it will not tell you whether a healthy URL is indexed.

Our bulk index checker does step 3. It takes the surviving URLs and checks them against live Google results, with no property verification and no daily inspection quota, so it works on any domain including ones you do not own.

Run in that order, the second list comes back short, honest, and made only of URLs where the problem is Google's judgment rather than your own configuration.

How to confirm a fix actually worked

Guides to these statuses tend to end at "click Validate Fix". That is where the real work starts.

Validation confirms the condition Google flagged is gone from the URLs it re-checks. It does not confirm those pages are now in the index, it does not cover every affected URL, and it is a one-time statement. A page indexed in September can be dropped in November, and nothing will tell you.

So verification is really two jobs.

Did it work? Re-run the same URL list through an index check a week or two after the fix and compare it against the list you started with. Same method, same list, different day. If the count of missing URLs fell, the fix worked. If it did not, you fixed the wrong thing, and you know that in two weeks instead of two quarters.

Is it still working? This one cannot be done by hand, which is the honest reason scheduled index monitoring exists as a category. Re-checking on a schedule and being told when a status changes is the only version of this that survives you getting busy. That is what SearchOptimo does: it re-checks the URLs from your sitemap on a schedule, keeps the history per URL, and sends de-indexing alerts the day a page drops out rather than the week you next remember to look.

When the answer is not a monitoring tool

Worth saying plainly, since the section above is a pitch and this one is not.

If your missing URLs come back as "Excluded by 'noindex' tag" or "Blocked by robots.txt", monitoring is not your fix and neither is any checker. You have a template or a robots file telling Google to stay out, and the repair is in your CMS. A tool can tell you that is what is happening, which is genuinely useful the first time, and after that the work is somewhere we cannot help.

The same goes for "Crawled – currently not indexed" on a page Google keeps declining. That is a judgment about the page, and no amount of resubmitting, pinging or monitoring changes a judgment. Monitoring earns its place on the other side of the fix, when you want to know whether it held.

Key takeaways

• A valid sitemap is a statement about a file. Indexing is a statement about pages. Passing the first predicts nothing about the second.
• The URL count beside your sitemap in Search Console is how many URLs Google read, not how many it indexed. That report has no indexed count in it.
• We inspected all 79 URLs in our own valid, zero-error sitemap on 25 August 2026. Seven were not indexed, and six of those seven had never been crawled.
• Search Console tells you which kinds of problems you have. Because of the reporting lag and the sampled examples, it will not reliably tell you every URL that has them.
• Reconcile in two passes: strip the URLs you excluded yourself, then check what survives against the live index. The difference is the only list worth working from.
• "Validate Fix" is not verification. Re-check the same list later, and keep checking, because index status moves in both directions.