Page Indexing Report (GSC)

TL;DR — The Page Indexing report in Google Search Console tells you how many of your pages Google has indexed (can show in search) versus not indexed, and for the not-indexed ones it tells you why. It used to be called the Index Coverage report. “Not indexed” sounds scary but usually isn’t — a lot of those URLs are supposed to be left out.

What the Page Indexing report is

When you open Google Search Console and click Pages under Indexing in the left menu, you land on the Page Indexing report. Google describes it simply: it lets you “see which pages Google can find and index on your site, and learn about any indexing problems encountered.”

It splits all the URLs Google knows about on your site into two buckets:

• Indexed — these pages can appear in Google Search.
• Not indexed — these pages aren’t in the index, either because something’s broken or because there’s a perfectly good reason (the page is a duplicate, you blocked it, you told Google not to index it, and so on).

Below that, a table called “Why pages aren’t indexed” lists the reasons and how many URLs fall under each one. That’s the part you actually work from.

Why “not indexed” usually isn’t a crisis

Here’s the thing most people miss the first time they open this report: not indexed doesn’t mean broken. Google says it plainly in the report’s own help — “Not indexed is not necessarily bad.” You shouldn’t expect every URL on your site to be indexed. Tag pages, filtered versions of a product listing, old redirected URLs, duplicates — Google leaving those out is the report working correctly.

So when you see a big “not indexed” number, don’t panic. Read which reasons are behind it before you change anything.

It’s the wrong tool for checking one page

This is an overview of your whole site. If you want to know whether one specific URL is indexed, this isn’t the report for it — you use the URL Inspection tool (the search bar at the top of Search Console). Google is explicit about this. The report is for trends and groupings; URL Inspection is for one page at a time.

Do you even need it?

If your site has fewer than 500 pages, Google says you “probably don’t need to use this report” — a site:yoursite.com search in Google is enough to spot-check what’s indexed. The report earns its keep on bigger sites where you can’t eyeball everything.

Want the full version — how to read every column, what all 16 statuses mean, how “Validate fix” works, and how to diagnose a sudden drop in indexed pages? Switch to the Advanced tab.

TL;DR — The Page Indexing report (formerly Index Coverage; “Pages” under “Indexing” in GSC) is an aggregate view of every URL Google knows about on your property, split into Indexed and Not indexed, with the not-indexed URLs grouped by reason in the “Why pages aren’t indexed” table. It’s not for single pages — that’s URL Inspection. The mindset that matters: not indexed is not necessarily bad — canonical/duplicate, noindex, robots, and intentional 404s are correct outcomes; Google says you should only expect your canonical pages to be indexed. Filter by Source = Website to find what you can fix, work the pre-sorted table top-down, and use Validate fix (~2 weeks typical) to request a recrawl. The report lags reality. Sites under 500 pages probably don’t need it.

What the report actually is (and its old name)

Google’s one-liner is the cleanest definition: the report lets you “see which pages Google can find and index on your site, and learn about any indexing problems encountered.” More precisely, it “shows the Google indexing status of all URLs that Google knows about in your property.” It’s an aggregate, property-wide report — not a per-URL tool.

If you’ve been doing SEO for more than a couple of years, you knew this as the Index Coverage report. Google renamed it to Page indexing in 2022 (it shows as “Pages” in the left nav), so a lot of older guides — and a lot of people’s muscle memory — still call it “Coverage.” Same report. I’m spelling that out because people searching the old name need to know they’re in the right place. (The rename was first spotted in a Google I/O 2022 demo and rolled out later that year; before that, a January 2021 data-quality update had already reworked several of the statuses, which is why some old screenshots won’t match what you see today.)

How to read the report

The summary view has a few parts worth understanding before you start clicking.

Indexed vs. Not indexed. The two totals above the chart. Google notes these are “complete and accurate from Google’s perspective, but small discrepancies can occur for various reasons” — so don’t expect them to perfectly equal your URL count. You can click “View data about indexed pages” for the historical indexed count and a sample of up to 1,000 indexed URLs.

The “Why pages aren’t indexed” table. This is the heart of it. It “shows issues that prevented URLs from being indexed on your site,” sorted by what Google thinks are the most important issues to address. Start at the top — the ordering is already a priority list.

The Source column — your fix filter. Each issue is sourced to either Google or the website, and Google’s guidance is direct: “The Source value in the table shows whether the source of the issue is Google or the website. In general, you can fix only issues where the source is listed as ‘Website’.” So Source = Website plus a validation state of “failed” or “not started” is your real to-do list. Google-source statuses (like a duplicate it chose to consolidate) usually aren’t yours to “fix.”

The “Improve page experience” table. A separate table for “issues that didn’t prevent page indexing, but we recommend that you fix them.” These are warnings, not blockers.

The sitemap filter. Above the chart you can scope the report to All known pages, All submitted pages, Unsubmitted pages only, or a specific sitemap. (Note: “A URL is considered to be submitted by a sitemap even if it was also discovered through some other mechanism.”) This filter is genuinely useful — more on that under validation.

The example URL lists are capped. When you open a status, the sample of affected URLs is “limited to 1,000 items, and isn’t guaranteed to show all URLs in a given status, even when less than 1,000 items.” Treat the examples as a sample, not a complete export of everything in that bucket.

Triage order, if you only have ten minutes. Scope the report to the sitemap that represents your intended URL inventory, so you’re reading it against the pages you actually want indexed. Scan the totals for any unexpected change first — a drop or spike is more urgent than a steady-state number. Filter to Source = Website for the issues you can actually act on. Within that filtered list, prioritize whatever’s hitting a business-critical template or URL pattern over an isolated one-off. Then fix the whole pattern — not just one URL — before you validate.

Report vs. URL Inspection — use the right one

The biggest practical distinction on this page. Google: “This report isn’t used to investigate the index status of specific pages. To find the index status of a specific page, use the URL Inspection tool.”

• Page Indexing report = aggregate trends, grouped by reason, property-wide.
• URL Inspection = one URL’s live/indexed state, the canonical Google chose, and a “Test live URL” option.

When a status confuses you, pull a sample URL out of it and inspect that URL. The two tools are meant to be used together.

A note on lag — the report is behind reality

This one saves a lot of false alarms. The report doesn’t update in real time; it reflects the last time Google crawled each URL, and the counts move when Google recrawls (Google: it “updates your instance count whenever it crawls a page with known issues, whether or not you explicitly requested fix validation”). Google’s John Mueller has described the indexing report as lagging behind — his read is that it’s more a matter of timing, where URLs show up in the report and then get indexed over time, so the report is essentially catching up to a state that’s already changed. Don’t over-react to a number that may just be stale.

One limitation worth knowing before you lean on URL Inspection’s “Test live URL” to settle an argument: the live test confirms whether Google can currently crawl and index that URL right now — it doesn’t tell you which canonical Google will choose among a set of duplicates. Canonical selection is a separate indexing decision made against the indexed data, not something the live test evaluates. For canonical/duplicate statuses specifically, the indexed result in URL Inspection (not the live test) is the signal to trust, and it can still lag your latest change.

Where to go next — every status, grouped

The “Why pages aren’t indexed” table is the map to the rest of this section. Each status below is its own deep dive (they’re in the sidebar too). I’ve grouped them by what’s actually going on, because the right reaction is completely different depending on the group — some you fix, some you confirm and leave alone.

Not indexed — Google’s choice (often nothing to fix)

• Discovered – currently not indexed — Google found the URL but hasn’t crawled it yet. Usually a crawl-demand or site-quality signal, not a one-page bug.
• Crawled – currently not indexed — Google crawled the page and chose not to index it (yet). A large bucket here often points at quality or duplication, site-wide.

Blocked by you (intentional — confirm it’s deliberate)

• Blocked by robots.txt — your robots.txt told Google not to crawl it.
• URL marked ‘noindex’ — Google found a noindex directive when it tried to index the page.

HTTP errors (these you usually fix)

• Blocked due to unauthorized request (401) — the page asked Googlebot to authenticate.
• Blocked due to access forbidden (403) — access wasn’t granted to the crawler.
• Blocked due to other 4xx issue — a 4xx that isn’t one of the named ones.
• Server error (5xx) — your server returned a 500-level error when the page was requested.
• Not found (404) — the URL returned a 404 when requested.

Canonical & duplicates (mostly correct — verify the chosen canonical)

• Alternate page with proper canonical tag — this page correctly points at its canonical, which is indexed. Working as intended.
• Duplicate without user-selected canonical — Google clustered it as a duplicate and chose a different page as canonical, and you never declared one.
• Duplicate, Google chose different canonical than user — you declared a canonical, but Google picked a different URL. (See canonicalization — the fix is aligning your signals, not adding a stronger tag.)

Redirects (one is normal, one is a bug)

• Page with redirect — a non-canonical URL that redirects to another page. This is normal; the destination is what gets indexed.
• Redirect error — a broken redirect: a chain that’s too long, a loop, an empty or bad target URL, or one that exceeds the max URL length. This one you fix.

Warnings (indexed, but worth attention)

• Indexed, though blocked by robots.txt — the page got indexed despite your robots.txt block (links to it were enough). Google can’t read its content or any noindex you put there — a classic crawl-vs-index gotcha.
• Page indexed without content — indexed, but Google couldn’t read meaningful content (often a rendering or cloaking-like issue).

I’m naming each status the way Google labels it so the per-status articles auto-link as they publish. The recurring theme: the canonical/duplicate, noindex, robots, and intentional 404 buckets are frequently correct — Google literally says “You should not expect all URLs on your site to be indexed, only the canonical pages.” The buckets to actually chase are the HTTP errors, redirect errors, and unexpectedly large “crawled/discovered not indexed” piles.

Fixing and validating

Once you’ve fixed the real issues (Source = Website), you tell Google to re-check:

1. Fix every instance of the issue on your site first.
2. Open the issue details and click “Validate fix.”
3. Don’t click it again until validation succeeds or fails.

Timing: “Validation typically takes up to about two weeks, but in some cases can take much longer, so please be patient.” The request moves through states (Not started → Started → Looking good → Passed, or Failed, or N/A if Google found the issue fixed on its own before you ever started). You don’t strictly have to click validate at all — Google can detect fixes on its own — but validation gives you a tracked result.

The speed trick: validate against a subset. Submit a sitemap of just your most important pages, filter the report to that sitemap, then request validation — Google notes “a validation request against a subset of your affected URLs can complete faster.”

Diagnosing drops, spikes, and “more not-indexed than indexed”

A few patterns Google itself calls out, and that I look for first:

• Indexed pages dropped with no errors showing. You probably blocked existing pages — a new robots.txt rule, a noindex, or a login requirement. Look for a matching spike in a non-indexed status.
• More not-indexed than indexed. Usually a robots.txt rule blocking a big section, or a flood of duplicates from filter/sort parameters (?type=dress, ?color=green, ?sort=price). That’s a faceted navigation and canonicalization problem more than an indexing one.
• A sudden error spike. Often a template change that introduced an error across many URLs, or a submitted sitemap full of URLs that are blocked or noindexed.

A few things to keep straight

• Indexed ≠ ranking. Indexed only means eligible to appear in Search. Whether it ranks depends on the query and many other factors.
• 100% coverage isn’t the goal. Per Google, only your canonical pages should be indexed — a healthy site has plenty of intentionally not-indexed URLs.
• Validate fix doesn’t re-index instantly. It queues a recrawl of known affected URLs; budget ~2 weeks.
• GSC data has limits. Example lists cap at 1,000; totals can drift slightly; and the report lags. (My own GSC data study — Anonymized Queries Make Up Nearly Half of GSC Traffic — is a good reminder that Search Console is a powerful but incomplete picture.)

A one-liner on Bing

Bing has no single “Page Indexing” equivalent. The closest aggregate view is Site Explorer in Bing Webmaster Tools (browse your site as a folder tree broken down by indexed, error, warning, and excluded pages), and URL Inspection in Bing covers the single-URL case. Use Site Explorer for the bird’s-eye view, URL Inspection for one page.

This page is the hub for the Page Indexing report; the per-status deep dives sit under it. For the whole pipeline — discovery, crawling, rendering, indexing, and serving — see the How Search Works cluster.

AI summary

A condensed take on the Advanced version:

• What it is: the Google Search Console Page Indexing report (formerly Index Coverage; “Pages” under “Indexing”). It shows the indexing status of every URL Google knows about on your property, split into Indexed and Not indexed.
• It’s aggregate, not per-URL. For a single page, use URL Inspection — Google says the report “isn’t used to investigate the index status of specific pages.”
• Not indexed is not necessarily bad. Canonical/duplicate, noindex, robots, and intentional 404s are correct outcomes; Google says you should only expect your canonical pages to be indexed.
• The “Why pages aren’t indexed” table is pre-sorted by importance — work it top-down. Filter by Source = Website to find what you can actually fix (Google-source issues generally aren’t yours).
• 16 statuses, grouped: Google’s-choice not-indexed (discovered/crawled – currently not indexed); blocked-by-you (robots.txt, noindex); HTTP errors (401, 403, other 4xx, 5xx, 404); canonical/duplicate (alternate, duplicate w/o canonical, Google chose different canonical); redirects (page with redirect = normal vs. redirect error = broken); warnings (indexed though blocked by robots.txt, page indexed without content).
• Fix → Validate fix (~2 weeks typical). Speed trick: filter to a sitemap of your top pages and validate the subset.
• The report lags reality — Mueller has described it as a report that’s catching up over time. Don’t over-react to a stale number.
• Diagnostics: indexed drop + no errors = you blocked something; more not-indexed than indexed = robots block or parameter duplicates; error spike = template change or a bad sitemap.
• Small sites (<500 pages) probably don’t need it — a site: search suffices.
• Bing: no direct equivalent — Site Explorer for the aggregate view, URL Inspection for one page.

Official documentation

Primary-source documentation from the search engines.

Google

• Page indexing report — Search Console Help: the buckets, the Source column, every status, the sitemap filter, and the Validate fix flow.
• Index Coverage Data Improvements (Jan 2021) — the data-quality update that reworked several statuses (removed “crawl anomaly,” added “indexed without content,” changed “submitted but blocked” to “indexed but blocked”).
• URL Inspection Tool — the per-URL companion to this report.

Bing / Microsoft

• Bing Webmaster Tools — URL Inspection — Bing’s per-URL index/SEO/markup view.
• Bing Webmaster Tools — Site Explorer (Refreshed Webmaster Tools) — the closest aggregate analogue to GSC’s Page Indexing report.

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 the report is and shows

• “See which pages Google can find and index on your site, and learn about any indexing problems encountered.” — Search Console Help. Jump to quote
• “The Page indexing report shows the Google indexing status of all URLs that Google knows about in your property.” Jump to quote

Google — report vs. single-page, and who can fix

• “This report isn’t used to investigate the index status of specific pages. To find the index status of a specific page, use the URL Inspection tool.” Jump to quote
• “The Source value in the table shows whether the source of the issue is Google or the website. In general, you can fix only issues where the source is listed as “Website”.” Jump to quote

Google — “not indexed” isn’t necessarily bad

• “Not indexed is not necessarily bad.” Jump to quote
• “You should not expect all URLs on your site to be indexed, only the canonical pages.” Jump to quote

Google — who needs it, validation timing

• “If your site has fewer than 500 pages, you probably don’t need to use this report.” Jump to quote
• “Validation typically takes up to about two weeks, but in some cases can take much longer, so please be patient.” Jump to quote

Gary Illyes, Google — on “crawled – currently not indexed” and site quality (SERP Conf 2024, relayed by Search Engine Journal)

• “And the general quality of the of the site, that can matter a lot of how many of these crawled but not indexed you see in search console. If the number of these URLs is very high that could hint at general quality issues.” Read the coverage

John Mueller, Google — on report lag (relayed by Search Engine Journal)

• “It’s just a report that’s kind of lagging behind.” Read the coverage

Working the Page Indexing report — checklist

A repeatable pass for triaging the report instead of staring at it:

• Note the Indexed vs. Not indexed totals and the trend — is anything moving?
• Open the “Why pages aren’t indexed” table and work it top-down (it’s pre-sorted by importance).
• Filter your attention to Source = Website — those are the issues you can actually fix.
• For each real issue, pull a sample URL and run it through URL Inspection to confirm what’s happening on that page.
• Separate the intentional statuses (noindex, robots-blocked, alternate w/ proper canonical, page with redirect) from the broken ones (5xx, 404, redirect error, unexpected 4xx) — only chase the broken ones.
• For canonical/duplicate statuses, verify the Google-chosen canonical in URL Inspection before “fixing” anything (see canonicalization).
• If crawled / discovered – currently not indexed is large, treat it as a site-quality / crawl-demand signal, not a per-page bug.
• Cross-check a drop in indexed pages against a spike in a not-indexed status (you may have blocked something).
• Fix all instances, then click Validate fix — and don’t click it again until it resolves.
• To validate faster, filter to a sitemap of your top pages and validate that subset.
• Remember the report lags — give changes ~2 weeks before judging them.

The mental models

1. Report = aggregate; URL Inspection = single page. The Page Indexing report tells you patterns across the site. URL Inspection tells you the truth about one URL (live status, chosen canonical, render). Always pair them: spot a pattern in the report, confirm the cause with Inspection.

2. Not indexed ≠ broken. The default reaction to a big not-indexed number should be “let me read the reasons,” not “let me fix everything.” Canonical/duplicate, noindex, robots, and intentional 404s are correct. Google only expects your canonical pages to be indexed.

3. Source = Website is your to-do list. The Source column splits issues into “Google’s call” and “your call.” You can only move the website ones. Filtering to Source = Website (plus validation state failed/not started) turns a scary table into an actionable list.

4. Sort order is a priority list. Google pre-sorts the “Why pages aren’t indexed” table by importance. Don’t invent your own order — start at the top and go down.

5. Validate fix is a recrawl request, not a switch. Clicking it asks Google to re-check known affected URLs; it takes ~2 weeks and can fail. The trick to speed it up is scoping it to a sitemap of your most important pages.

6. The report is always a little behind. It reflects the last crawl per URL and updates on recrawl. Treat any single reading as a lagging snapshot, not live truth.

Page Indexing report — cheat sheet

The two reports people confuse

The 16 statuses, grouped

Fast facts

• Old name: Index Coverage report (renamed to Page indexing in 2022).
• Source = Website = the issues you can fix.
• Validate fix ≈ 2 weeks; scope it to a small sitemap to go faster.
• Example URL lists cap at 1,000; totals can drift slightly; the report lags.
• Indexed ≠ ranking — indexed only means eligible to appear.
• <500 pages? You probably don’t need this report — use a site: search.

Common issues

Symptom → likely cause → fix, for the patterns that actually send people back to this report.

Login, access-denied, or empty app pages are being indexed

Worked example: /account/invoices/123 is meant to require a login. For a logged-out crawler it returns 200 OK, a normal indexable robots directive, and a branded HTML shell whose main content says “Sign in to continue.” Internal links or an old sitemap expose thousands of invoice URLs. Google is not bypassing the login—it is indexing the crawlable 200 shell the application deliberately served.

Inspect several URLs while logged out and compare HTTP status, canonical, robots directives, and rendered main content. The fix is usually template-level: require authentication before serving the resource, return the correct 401, 403, 404, or 410 outcome for the intended access model, remove the URLs from sitemaps and crawlable navigation, or serve crawlable noindex if the public shell must remain reachable. Verify both the live response and the indexed state; fixing one sample URL does not prove the route pattern is fixed.

Indexed count dropped, no new errors showing

• Symptom: the “Indexed” total falls between visits, but the “Why pages aren’t indexed” table doesn’t show a matching spike in an error status.
• Likely cause: you blocked pages that were previously indexed — a new robots.txt disallow rule, a noindex shipped in a template, or a login/paywall requirement added to a section of the site.
• Fix: check for a matching spike in a non-error, not-indexed status (blocked by robots.txt, noindex, or discovered/crawled – currently not indexed) rather than the HTTP-error statuses. Confirm on a sample URL with URL Inspection, and check the live robots directives with the robots-txt-tester (/tools/robots-txt-tester).

”More not indexed than indexed”

• Symptom: the not-indexed total is larger than the indexed total, and it isn’t a brand-new site.
• Likely cause: either a robots.txt rule blocking a large section, or a flood of near-duplicate URLs from filter/sort parameters (?color=green, ?sort=price) that Google is folding into “duplicate” statuses.
• Fix: check the parameter pattern against your canonical tags with the canonical-checker (/tools/canonical-checker), then confirm the affected URLs really are duplicates by comparing their rendered content directly. This is a faceted-navigation/canonicalization problem wearing an indexing costume, not a report bug.

A sudden spike in one HTTP-error status

• Symptom: 401, 403, 404, or 5xx counts jump across many URLs at once, usually after a deploy.
• Likely cause: a template change that broke a shared component (auth check, redirect rule, error page), or a newly submitted sitemap full of URLs that are blocked, noindexed, or already gone.
• Fix: pull a sample of affected URLs from the status detail and re-check their live status codes with the http-status-checker (/tools/http-status-checker). If it’s sitemap-sourced, audit the sitemap itself with the sitemap-validator (/tools/sitemap-validator) before resubmitting.

”Redirect error” (not the normal “Page with redirect”)

• Symptom: the report shows Redirect error, distinct from the expected Page with redirect status.
• Likely cause: a redirect chain that’s too long, a redirect loop, an empty or malformed target URL, or a target URL that exceeds Google’s max URL length.
• Fix: trace the actual hop sequence with the redirect-chain-mapper (/tools/redirect-chain-mapper) and shorten it to a single hop to the final URL.

”Validate fix” comes back Failed

• Symptom: you fixed the issue, clicked Validate fix, and it resolves to Failed instead of Passed.
• Likely cause: either the fix didn’t actually reach every affected URL (a CDN cache, a staging-only deploy, or a template fix that missed some URL patterns), or Google recrawled before the fix propagated.
• Fix: spot-check a handful of the originally affected URLs directly (view source or an HTTP-status/robots check, not just the browser render) to confirm the fix is live everywhere, then re-request validation — you don’t need to wait for the full cycle to restart if the underlying issue is confirmed fixed.

Validation tests

Proof that a fix you made actually changed the report’s underlying reality — not just that the report says so.

Confirm a blocked page’s live status matches expectations

• Test to run: http-status-checker (/tools/http-status-checker) or curl -I against the affected URL.
• Expected result: the status code you intended — 200 if you meant to unblock it, or a deliberate 301/404 if you meant to remove it.
• Failure interpretation: if it still returns the old error (401/403/5xx), the fix hasn’t shipped everywhere (check CDN cache, load balancer, or environment).
• Monitoring window: immediate — HTTP status is live, not delayed.
• Rollback trigger: status doesn’t match intent after a cache purge and a few minutes’ wait — revert the change and re-diagnose before touching production again.

Confirm a robots.txt fix actually unblocks the URL

• Test to run: robots-txt-tester (/tools/robots-txt-tester) against the specific URL path.
• Expected result: the tester reports the URL as allowed for Googlebot.
• Failure interpretation: still blocked means the rule wasn’t removed, a more specific rule is still matching, or the wrong robots.txt (staging vs. production) was checked.
• Monitoring window: immediate for the file itself; allow a normal crawl cycle (days, not hours) before expecting the GSC status to update.
• Rollback trigger: the tester still shows the URL blocked after confirming you edited the live, production robots.txt — treat as unresolved and keep debugging.

Confirm a canonical fix resolved the way you intended

• Test to run: canonical-checker (/tools/canonical-checker) on the affected URL, followed by URL Inspection in GSC for the Google-selected canonical.
• Expected result: the <link rel="canonical"> tag matches the URL you want indexed, and URL Inspection shows Google agreeing with your declared canonical.
• Failure interpretation: if Google still shows a different “Google-selected canonical” than your declared one, your fix addressed the tag but not the underlying duplication signals (internal links, sitemap entries, redirects all still need to agree).
• Monitoring window: 2–4 weeks — canonical selection is one of the slower signals to re-settle.
• Rollback trigger: Google’s selected canonical still disagrees with yours after 4+ weeks and a Validate fix cycle — treat the underlying signals (not just the tag) as still conflicting.

Confirm a redirect fix removed the chain/loop

• Test to run: redirect-chain-mapper (/tools/redirect-chain-mapper) on the affected URL.
• Expected result: a single hop straight to the final destination URL with a 200.
• Failure interpretation: more than one hop, or a loop back to an earlier URL, means the redirect rule wasn’t consolidated — you’re likely chaining a new rule on top of an old one instead of replacing it.
• Monitoring window: immediate for the chain itself; a normal recrawl cycle before the GSC status updates.
• Rollback trigger: the chain is still longer than one hop after the fix — revert and consolidate the redirect rules at the source.

Confirm the “Validate fix” request actually passed

• Test to run: the Validate fix button on the specific status in GSC’s Page Indexing report (scope to a sitemap of your priority URLs to get a faster read).
• Expected result: the validation state moves to Passed (or N/A, meaning Google confirmed the fix independently).
• Failure interpretation: Failed means Google rechecked and still found the issue on at least some URLs — go back to the underlying fix, don’t just re-click Validate.
• Monitoring window: “typically up to about two weeks,” per Google — can run longer.
• Rollback trigger: two consecutive Failed results on the same status after confirming the underlying fix is live — escalate to checking whether the fix actually reaches every affected URL pattern, not just the sample you tested.

How to measure

The standing KPIs for keeping an eye on this report over time, not one-off checks.

Indexed page count (trend, not a snapshot)

• What it tells you: whether Google’s indexed footprint of your site is growing, flat, or shrinking.
• How to pull it: the “Indexed” total at the top of the Page Indexing report, or the historical chart under “View data about indexed pages.”
• Benchmark / realistic range: no universal number — depends entirely on how many URLs you want indexed (your canonical page count), which varies by site. Track the trend against your own canonical URL count rather than chasing 100% coverage; Google explicitly says only canonical pages should be indexed.
• Cadence: monthly, or immediately after a large content or URL-structure change.

”Why pages aren’t indexed” total, by Source = Website

• What it tells you: the size of your actual, actionable to-do list — issues Google says you (not Google) can fix.
• How to pull it: filter the “Why pages aren’t indexed” table by Source = Website and sum the affected-URL counts across statuses with a “Failed” or “Not started” validation state.
• Benchmark / realistic range: depends on site size and history — there’s no honest universal target. Establish your own baseline on your next full pass through the table, then track whether that number goes down over successive checks.
• Cadence: monthly for most sites; weekly during an active cleanup or after a large migration.

HTTP-error status count (401/403/404/5xx)

• What it tells you: whether pages you expect to serve are actually broken for Googlebot — the group of statuses that’s almost always worth fixing.
• How to pull it: the individual status rows in the report, cross-checked with the http-status-checker (/tools/http-status-checker) on a sample of affected URLs.
• Benchmark / realistic range: zero is the honest target for URLs you intend to keep live — any nonzero count on canonical pages is worth investigating; a nonzero count on already-removed pages (expected 404s) is normal and depends on your content lifecycle.
• Cadence: check after every deploy that touches routing, auth, or templates; otherwise monthly.

Validate-fix pass rate

• What it tells you: whether your fixes are actually landing across all affected URLs, or only partially.
• How to pull it: track each Validate fix request’s outcome (Passed / Failed / N/A) in the status detail view over time.
• Benchmark / realistic range: no fixed target — a healthy pattern is most requests resolving to Passed or N/A on the first attempt. Repeated Failed results on the same status is the signal to watch, not a specific percentage.
• Cadence: per fix cycle — check back roughly two weeks after each Validate fix request.

Tools

The Page Indexing report tells you what Google thinks is wrong; these tools help you confirm and fix the underlying cause.

This site’s tools

• gsc-workbench (/tools/gsc-workbench) — work with your own GSC data (via the Search Console API) alongside the concepts on this page.
• gsc-regex-tester (/tools/gsc-regex-tester) — build and test the regex filters GSC’s Performance and Page Indexing reports accept, useful for isolating a URL pattern behind a status.
• http-status-checker (/tools/http-status-checker) — confirm the live status code (401/403/404/5xx) behind an HTTP-error status before or after a fix.
• redirect-checker (/tools/redirect-checker) and redirect-chain-mapper (/tools/redirect-chain-mapper) — check a single redirect or trace a full chain when you see Redirect error.
• canonical-checker (/tools/canonical-checker) — check the declared canonical tag on a URL flagged in the canonical/duplicate group.
• robots-txt-tester (/tools/robots-txt-tester) — verify whether a specific URL is actually blocked before treating Blocked by robots.txt as intentional or a bug.
• sitemap-validator (/tools/sitemap-validator) and xml-sitemap-generator (/tools/xml-sitemap-generator) — audit or rebuild the sitemap you’ll use to scope a faster Validate-fix request.
• site-audit-lite (/tools/site-audit-lite) — a broader crawl-based sanity check when a Page Indexing pattern (large error spike, mass duplication) looks site-wide rather than isolated to a few URLs.

Third-party tools

• Google Search Console — the Page Indexing report itself, plus URL Inspection for the single-URL companion view named throughout this article.
• Bing Webmaster Tools — Site Explorer (aggregate view) and URL Inspection (single-URL view), Bing’s closest equivalents.
• Screaming Frog — crawl your own site the way Googlebot would to cross-check status codes, redirects, and canonical tags at scale before trusting a GSC sample.

Resources worth your time

My related writing

• How to Fix “Discovered - currently not indexed” — the deep dive on one of the most-misread statuses in this report.
• How to Remove URLs From Google Search (5 Methods) — ties to the noindex / removal-tool side of the report.
• Anonymized Queries Make Up Nearly Half of GSC Traffic — my GSC data study; a good reminder that Search Console is powerful but incomplete.
• The Beginner’s Guide to Technical SEO — where indexing and GSC fit in the bigger picture.

My speaking

• How Search Works (SlideShare) — my walkthrough of crawling, rendering, indexing, and ranking, which is the context the whole Page Indexing report sits inside. (My standing disclaimer applies: “This is my understanding of systems… not going to be 100% complete or accurate.”)

Official

• Google — Page indexing report and Index Coverage Data Improvements (2021).

From around the industry

• r/TechSEO — the community for indexing and coverage-report debugging.
• Google Explains Reasons For Crawled Not Indexed (Search Engine Journal) — covers Gary Illyes at SERP Conf 2024 explaining why high “crawled not indexed” numbers can hint at site-wide quality issues.
• Mueller Asked About Lag in Google Search Console Indexing Report (Search Engine Journal) — John Mueller on why the report lags and shouldn’t trigger an over-reaction.
• Google Search Console Coverage Report Renamed to Pages Report (Search Engine Roundtable) — Barry Schwartz’s first sighting of the Index Coverage → Page indexing rename at Google I/O 2022.
• Index Coverage Data Improvements (Google Search Central Blog) — the Jan 2021 update that removed “crawl anomaly,” added “indexed without content,” and reworked several statuses — explains why older screenshots don’t match today’s report.
• Google Search Console Help — Page indexing report — the primary official reference: buckets, the Source column, all statuses, the sitemap filter, and the Validate fix flow.

Quiz

Test what you remember about reading the Page Indexing report.

Page Indexing report

The Google Search Console report (formerly Index Coverage) showing how many of your URLs are indexed vs. not indexed, and grouping the not-indexed ones by reason.

Parent concept: Indexing · Related: Crawling, Indexing, Canonicalization

Page Indexing report

The Page Indexing report — formerly the Index Coverage report, and labeled “Pages” under “Indexing” in the Google Search Console left nav — shows which URLs Google can find and index on a site. It groups them into an Indexed bucket (eligible to appear in Search) and a Not indexed bucket, with a “Why pages aren’t indexed” table that breaks the not-indexed URLs down by reason so you can find and fix indexing problems.

It is an aggregate, property-wide report — not a tool for checking a single page. For one URL’s live status and Google-chosen canonical, you use the URL Inspection tool instead.

A key thing to internalize: “not indexed” is not necessarily bad. Many statuses (canonical/duplicate, noindex, robots-blocked, intentional 404s) are correct outcomes, and Google says you should not expect every URL on your site to be indexed — only the canonical pages. If your site has fewer than 500 pages, Google says you probably don’t need this report at all.

Parent concept: Indexing · Related: Crawling, Indexing, Canonicalization

Changelog