Page indexing report: every 'not indexed' reason and its fix

The page indexing report in Google Search Console shows how many of the URLs Google knows on your site are indexed, and gives a reason for every URL that is not. Most sites have some not-indexed URLs for good reasons, so the job is to find the reasons that hit pages you want in search results and fix only those.

Below is every reason the report can show, in Search Console's own wording, with the fix and whether it needs one at all. Each reason links to a full guide.

What is page indexing in Search Console?

Indexing is the step after crawling: Google fetches a page, processes its content and stores it in the Google index, where it becomes eligible to appear in Search and Discover. The page indexing report is the site-wide view of that step. It counts your indexed and not-indexed URLs and groups the not-indexed ones by reason.

To open it, select your property, then click Pages in the Indexing section of the left menu. The summary page has four parts:

• A chart of indexed and not-indexed totals. Each bar is the running total as of that date, not the number of pages Google processed on that day.
• The "Why pages aren't indexed" table. Every row has a Reason, a Source (Website or Google) and a Validation state. Google's help says that, in general, you can fix only the issues whose source is Website.
• The "Improve page experience" table, for warnings that did not stop indexing. "Indexed, though blocked by robots.txt" lives here: Google indexed the URL from links alone because the block stopped it reading the page. The indexed though blocked by robots.txt guide covers that case.
• The "View data about indexed pages" link, with the history of your indexed count and up to 1,000 example indexed URLs.

A sitemap filter above the chart switches between All known pages (the default), All submitted pages, Unsubmitted pages only and one specific sitemap. Filtering to All submitted pages shows only the URLs you asked Google to index, which is usually the list you care about.

Google's help is blunt about small sites: with fewer than 500 pages you probably do not need this report. Search site:yourdomain.com, then inspect your homepage and key pages in URL Inspection.

Why are pages not indexed in Search Console?

Search Console files every not-indexed URL under a reason in the "Why pages aren't indexed" table. Fifteen reasons can appear there, from server errors and robots.txt blocks to duplicates and redirects. Several of them describe a site working as intended. The table maps each reason to its cause, whether you should act, and the fix.

Which not-indexed reasons need no action?

Page with redirect and Alternate page with proper canonical tag are usually the report working as intended. Old http:// URLs, retired slugs and parameter URLs such as ?utm_source= or ?sort=price that point at a clean canonical belong in those rows. So do noindex, robots.txt and 404 rows on pages you meant to hide or remove.

Google's help says it directly: having a page marked duplicate or alternate "is usually a good thing; it means that we've found the canonical page and indexed it." For Duplicate without user-selected canonical it goes further and calls the status "not an error, but is working as intended."

Judge each row by its example URLs rather than its count. Open the row and read them. If none of them is a page you want a searcher to land on, leave the row alone. If even one is, find the cause in the template or rule that produced it, because one bad robots.txt line or one layout carrying a stray noindex often explains the whole row.

Two patterns deserve attention even when every row looks expected. Google says a drop in indexed pages without a matching rise in errors can mean you are blocking existing pages with robots.txt, noindex or a required login. And a Not found (404) row only lists URLs that returned 404 in the past month, so a URL leaves that row once a month passes without it returning 404 to Google.

How do you read the report without being misled?

Treat the report as a delayed sample of your site. Each example list stops at 1,000 URLs and is not guaranteed to show every affected URL even below that number. Google's short guide adds that changes take a few days to reach the report, and each URL's status comes from Google's last crawl, not from your live page.

That lag explains a lot of confusing rows. If a row still lists a URL you already fixed, check its crawl date in the URL details before assuming the fix failed; the crawl probably came before your change. Google's help notes the reverse case too: a URL that URL Inspection lists as indexed but the report does not was probably indexed recently and will show up in the report soon.

A few more rules keep you from chasing ghosts:

• You cannot search or filter the report by URL. For one URL, use URL Inspection.
• The totals will not exactly match your own page count, and Google says small discrepancies can occur.
• An issue stays in the table until 90 days after its last instance disappears. If it comes back within those 90 days, it reopens with its original "First detected" date.
• You do not need to watch it daily. Google suggests checking monthly, or after large changes, and emails you when errors spike.

How does Validate fix work?

Validate fix asks Google to recrawl every URL known to have an issue and confirm it is gone. Google says it typically takes up to about two weeks, and in some cases much longer, because only the affected URLs are queued and each needs a fresh crawl. You get an email when it passes or fails.

Run it in this order:

1. Fix every instance first. Validation stops as soon as Google finds a single remaining instance.
2. Run Test live URL on two or three affected pages to confirm the fix is live.
3. Open the issue's details page and click Validate fix, once. Google asks you not to click it again until validation has passed or failed.
4. Search Console immediately checks a few pages. If the issue is still on any of them, validation ends and the state does not change.
5. Follow progress from See details on the issue page, which lists every URL queued and its result.

To finish faster, submit a sitemap that holds only your important pages, filter the report by that sitemap, then validate. A request against that subset can complete sooner than one covering every affected URL.

Each URL also gets its own state: Pending, Passed, Failed, or Other when Google could not reach it (Other counts as passed). A new validation rechecks only Pending and Failed URLs, plus any new instances found since.

URL Inspection: indexed result or Test live URL?

URL Inspection opens on Google's indexed result: what Google saw at its last crawl and why the URL is or is not on Google. Test live URL fetches the page now. Use the indexed result to learn Google's current decision, and the live test to confirm a fix before you request indexing.

The live test does not check duplicates or canonical choice, sitemaps, referring pages, quality, manual actions or removals, so a clean live test does not mean the page will be indexed. For redirects, the indexed result describes the URL you entered, while the live test follows the redirect and tests the target without saying so.

URL Inspection has a daily limit per property, Request indexing has its own quota, and asking twice for the same URL does not get it crawled any faster. Google says crawling can take anywhere from a few days to a few weeks.

Check what your pages send before Google's next crawl

The report shows what Google found days ago. To check what your pages send right now, run the free scan on LaunchScaler: you give it a URL, it needs no account, and it runs 156 checks across 6 of its 7 categories at no cost. Its search checks read the same signals this report reacts to: robots.txt rules that block a page, noindex in the meta robots tag or the X-Robots-Tag header, a noindex hidden behind a robots.txt block, canonicals that point at redirected or 404 URLs, soft 404s, long redirect chains, and a sitemap that is missing or lists non-canonical URLs. It reads your live site rather than Google's index, so fix what it flags, run Test live URL on one affected page, then click Validate fix on the matching row.