The Page indexing report explained: why pages aren't indexed

The Page indexing report in Google Search Console (Indexing → Pages) shows how many of the URLs Google knows on your site are indexed, and gives a reason for every one that is not. Some reasons are faults you should fix, such as a 404 on a live page, a server error or a stray noindex tag. Many are not faults at all: redirects, canonicalised duplicates and alternate URLs are meant to stay out of the index. Reading the report well mostly means telling those two groups apart.

Where is the report, and what does the chart show?

Open a property in Search Console and choose Indexing → Pages. The top of the report is a chart of two totals over time, indexed and not indexed. Below it, a table headed “Why pages aren’t indexed” has one row per reason, each with a source, a validation status and a count of affected pages. Click a row for its trend and a list of example URLs.

Two details save confusion later. The example list is capped at 1,000 rows, and Google says it is not guaranteed to show every affected URL even below that. And a filter above the chart switches between “All known pages” (the default), “All submitted pages”, “Unsubmitted pages only” and a single sitemap. To see how the pages you care about are doing, filter to the sitemap that lists them; the default view mixes in every parameter URL and old redirect Google has come across.

Every common reason, and whether to act

The report’s Source column marks each row as coming from your website or from Google, and Google’s help notes that the issues you can generally fix are the ones whose source is the website. The table below groups the reasons by where the cause usually sits; the Source column in your own report is the authority.

Reason	Cause usually sits with	What it means	Act or ignore
Server error (5xx)	Your site	Googlebot got a 500-level response	Act if the page matters; check Settings → Crawl stats
Redirect error	Your site	A loop, a chain that is too long, or a bad URL in the chain	Act
URL blocked by robots.txt	Your site	A robots.txt rule stops Googlebot crawling it	Act if you want it indexed; ignore if deliberate
URL marked ‘noindex’	Your site	A noindex rule in a meta tag or HTTP header	Act if accidental; ignore if deliberate
Soft 404	Your site	The page reads as “not found” but returns a success code	Act: return a real 404 or 410, or give it real content
Blocked due to unauthorized request (401)	Your site	Googlebot was asked to log in	Ignore for private pages; act if the page should be public
Blocked due to access forbidden (403)	Your site	The server refused Googlebot	Act if public; often a firewall or bot rule
Not found (404)	Your site	The URL returns 404	Ignore if removed on purpose; 301 it if it moved
Page with redirect	Your site	The URL redirects; its target may be indexed	Ignore, unless it is a page you meant to keep
Alternate page with proper canonical tag	Your site, working as intended	The page points to a canonical that is indexed	Ignore
Duplicate without user-selected canonical	Both	A duplicate with no declared canonical; Google picked one	Declare a canonical if Google’s pick is wrong
Duplicate, Google chose different canonical than user	Google	Google disagrees with the canonical you declared	Investigate with URL Inspection
Crawled – currently not indexed	Google	Crawled, but not added to the index	Improve the page, or accept it
Discovered – currently not indexed	Google	Known, but not crawled yet	Check server health and internal links; wait

In your report the noindex row may read “Excluded by ‘noindex’ tag” rather than the help page’s wording. It is the same reason.

Below the main table, an “Improve page experience” section lists URLs that are indexed but have a problem. “Indexed, though blocked by robots.txt” means Google indexed a URL it was not allowed to crawl, usually because other pages link to it. To get it out, remove the robots.txt block and add noindex: Google’s documentation says noindex cannot work on a page robots.txt blocks, because Googlebot never fetches it. “Page indexed without content” means Google could not read what was on the page, which deserves an immediate URL inspection.

The three reasons that need judgement

Most rows are mechanical: something on your server says no, and either you meant it or you did not. Three rows are Google’s decisions, and they generate most of the questions.

“Crawled – currently not indexed” means Googlebot fetched the page and Google chose not to index it. Google’s help says it may or may not be indexed in the future, and that there is no need to resubmit it. It is usually a verdict on the page’s value, so the fix is the page, not the Request indexing button. Crawled – currently not indexed goes through the causes.

“Discovered – currently not indexed” means Google knows the URL but has not crawled it, which is why its last crawl date is blank. Google’s explanation is that typically, crawling it was expected to overload the site, so the crawl was rescheduled. See Discovered – currently not indexed.

“Duplicate, Google chose different canonical than user” is the canonical row worth reading. “Alternate page with proper canonical tag” means Google agreed with your canonical; this one means it did not. Inspect a URL and compare the User-declared canonical with the Google-selected canonical; internal links, redirects or a sitemap pointing at the other version are the usual culprits. Alternate page with proper canonical tag covers the harmless sibling.

How does “Validate fix” work?

Once you have fixed every instance of a reason, open its row and click Validate fix. Google recrawls the affected URLs and reports progress as a status: Not started, Started, Looking good, Passed or Failed. You get an email when Google has confirmed the fix on all URLs.

1. Fix every instance first, then start validation.
2. Click Validate fix once, and not again until the run has passed or failed.
3. Give it time. Google says validation typically takes up to about two weeks, and sometimes much longer.
4. If it fails, find the URL that caused the failure in the validation details, fix it and start again.

On a large site, Google suggests validating against a sitemap of your most important pages, which can finish faster. For one important URL, the URL Inspection tool tells you its state without waiting for a validation run.

What is normal?

Google’s help is plain about this: you should not expect every URL on your site to be indexed, just the canonical ones. A healthy property can show more not-indexed URLs than indexed ones, because every redirect, parameter variant and retired URL Google has seen gets counted somewhere.

Three things deserve attention. A falling indexed total, since Google says that ideally the indexed count rises gradually as a site grows. A sudden jump in a website-side reason after a deploy, which usually means a template change: a noindex left over from staging, a canonical pointing every page at the home page, a firewall rule refusing Googlebot. And an important page turning up under any reason at all, easiest to catch by filtering to your main sitemap.

Everything else can wait for a quiet afternoon. A fixed issue stays in the table until ninety days pass without a recurrence, so an old row is not necessarily a live problem.

Where QueryWatch fits

QueryWatch is an independent app, not affiliated with Google, and it does not reproduce this report: the Search Console API has no endpoint for the Page indexing breakdown. What the app covers is the URL-level half. The free tier includes 5 URL inspections a day, showing a page’s index verdict, coverage state, last crawl and canonical, plus your sitemap list. On Pro you can mark key pages as watched and get a push alert when one changes its index verdict or coverage state, and another when a sitemap’s error count rises. Search Console alerts has the details, and Clicks dropped. Now what? shows where an inspection fits in a traffic investigation.

The reference for every reason is Google’s own Page indexing report help page.