Page Indexing (Index Coverage) Report

TL;DR — The Page Indexing report in Google Search Console (it used to be called the Index Coverage report) tells you which of your pages are in Google’s index, which aren’t, and why. “Not indexed” sounds scary, but a lot of those pages are supposed to be left out. Find the reason, decide whether it’s actually a problem, and only fix the ones that matter.

What this report is

Open Google Search Console, click Indexing → Pages, and you’re looking at the Page Indexing report. Google renamed it from “Index Coverage” back in 2022, but the old name stuck — so if you searched for the “index coverage report” or the “coverage report,” this is the same thing.

It does one job: it takes every URL Google already knows about on your site and sorts it into two piles. That “already knows about” part matters — it’s not a full inventory of every URL that exists on your site, only the ones Google has found so far, and the example URLs it lists under each reason are a capped sample, not a complete export.

• Indexed — Google has these pages in its index, so they can show up in search results.
• Not indexed — Google knows about these but isn’t including them right now, and it tells you the reason for each.

”Not indexed” is not the same as “broken”

This is the part most people get wrong. They see a big “Not indexed” number and panic. But Google itself says you shouldn’t expect every URL to be indexed, and a healthy site has plenty of pages that are intentionally left out:

• A page that redirects somewhere else.
• A duplicate that points to the “real” version with a canonical tag.
• A page you deliberately tagged noindex (like a thank-you page).

All of those show up under “Not indexed” and all of them are working exactly as they should. So the first question is never “how do I fix this?” — it’s “does this actually need fixing?”

The two reasons people ask about most

Two not-indexed reasons cause the most confusion, and they sound almost identical:

• “Crawled - currently not indexed” — Google visited the page and decided not to index it (yet). Most often that’s a quality/value signal, but treat it as the leading hypothesis to check against the actual page, not a guaranteed cause.
• “Discovered - currently not indexed” — Google knows the page exists but hasn’t even visited it yet. Most often that’s about capacity, but low perceived importance or thin internal linking can look the same — check the page before assuming which one it is.

Same-sounding labels, generally different problems. The Advanced version has the full table of every reason and what to do about each.

How to actually fix something

When you’ve fixed the underlying cause of a real problem, click the Validate fix button on that reason. Google then re-checks a sample of the affected pages. It can take a couple of weeks, so be patient — and make sure you’ve truly fixed the cause before you click, or validation just fails. Note that a passed validation just means the report’s status caught up with reality — it doesn’t guarantee the page will rank, get traffic, or get cited in AI answers.

To check one specific page in detail, use the URL Inspection tool (it tells you the live status of a single URL). And if you only care about the pages in a certain sitemap, you can filter the report by that sitemap. Want the full breakdown of all twelve not-indexed reasons? Switch to the Advanced tab.

TL;DR — The Page Indexing report (renamed from Index Coverage at Google I/O in May 2022) covers URLs Google already knows about — not a full site inventory — and splits them into Indexed and Not indexed, then buckets the not-indexed ones by reason using a capped sample of example URLs per issue, not a complete export. Reading it well means knowing that most reasons are pages working as intended — Google says “Don’t expect every URL on your site to be indexed.” The two reasons worth real attention are “Crawled - currently not indexed” (most often a quality/value verdict — fix at the site level, not page-by-page) and “Discovered - currently not indexed” (most often a crawl-capacity/importance problem — fix crawl health and internal links); treat either label as the leading hypothesis to test against the actual pages, not a certain diagnosis. Use Validate fix after fixing the cause; it samples pages and can take ~two weeks, and passing it confirms the report caught up with reality — it doesn’t guarantee indexing, rankings, traffic, or AI-search visibility. Pair the report with the URL Inspection tool and Sitemaps filtering.

What the report is, and the rename

The Page Indexing report is Google Search Console’s answer to “which pages can Google find and index on my site, and what’s stopping the rest?” In Google’s own words, it lets you “See which pages Google can find and index on your site, and learn about any indexing problems encountered.”

Google previewed the renamed “Pages” / “Page indexing” report at Google I/O in May 2022, retiring the old “Index Coverage” name. The data itself had been overhauled a year earlier: on January 11, 2021 Google shipped a set of Index Coverage data improvements, announced as “significant improvements to this report so you’re better informed on issues that might prevent Google from crawling and indexing your pages.” As of this writing, Google’s UI and Help docs use only “Page indexing” — I still call out “Index Coverage” because a large share of people search that legacy name, not because the two names are still interchangeable in Google’s own documentation.

Indexed vs Not indexed is descriptive, not a scorecard

Before looking at any totals: the report only covers URLs Google already knows about in the property — it’s not a guaranteed inventory of every URL on your site — and the example URLs listed under each reason are a capped sample (up to 1,000 for the Indexed list, per current Help text), not a complete export. Keep that scope in mind whenever you read a count.

The report sorts every known URL into Indexed (eligible to appear in Search) and Not indexed (everything Google is holding back, grouped by reason). The mistake I see constantly is treating that “Not indexed” count as a problem to drive to zero. It isn’t. Google is explicit: “Don’t expect every URL on your site to be indexed.” A healthy site has a large pile of intentionally not-indexed URLs — canonicalized duplicates, redirects, deliberately noindexed utility pages, gated content. Many of the “errors” in this report are pages working exactly as designed.

So before fixing anything, ask which bucket a reason falls into: working as intended, a directive you set, or an actual problem.

Every “Not indexed” reason — what it means and what to do

Most competing articles only cover the two “currently not indexed” reasons. Here’s all twelve, with Google’s verbatim definitions, in the Cheat Sheets tab as a “reason → meaning → fix” table. The short version, grouped by bucket:

Working as intended (usually no action):

• Alternate page with proper canonical tag — “This page correctly points to the canonical page, which is indexed, so there is nothing you need to do.”
• Page with redirect — the URL itself won’t be indexed; the redirect target might or might not be. Verify the target is right, otherwise leave it.
• Excluded by ‘noindex’ tag — Google found a noindex directive and obeyed it. Only “fix” this if the page was meant to be indexed. (The report UI shows “Excluded by ‘noindex’ tag”; older Help text phrased it “URL marked ‘noindex’” — match whichever you see.)
• Blocked due to unauthorized request (401) — expected for genuinely gated content; a problem only if a public page got locked behind auth.

Canonicalization (decide if Google chose right):

• Duplicate without user-selected canonical — Google picked another page as canonical and won’t serve this one. Set an explicit canonical / consolidate.
• Duplicate, Google chose different canonical than user — your canonical signal was overridden. This is common and not a mistake on your part; strengthen signals (canonical, internal links, content) toward your preferred URL.

Actual problems (fix if the page should exist):

• Not found (404) — “404 responses are not necessarily a problem, if the page has been removed.” Fix only if the URL should resolve.
• Soft 404 — the page returns a “not found” message but a 200 status code. Return a real 404/410, or add genuine content.
• Blocked by robots.txt — unblock if it should be crawled. Remember robots.txt blocks crawling, not indexing.
• Server error (5xx) — your server returned a 500-level error. Investigate hosting; often transient or load-related.

The two that need their own section — Crawled - currently not indexed and Discovered - currently not indexed — below.

Crawled vs Discovered — the distinction to nail

These two labels look like twins and Google’s own reason documentation tells you to review the specific reason and the page’s context rather than assume one fixed cause — so treat what follows as the most likely explanation to test against your actual pages, not a universal diagnosis that applies to every URL carrying the label.

“Discovered - currently not indexed” is most often a capacity problem. Google knows the URL exists but hasn’t crawled it yet. Google’s definition: the page “was found by Google, but not crawled yet. Typically, Google wanted to crawl the URL but this was expected to overload the site.” In the Ahrefs guide on “Discovered - currently not indexed” (which I reviewed), we put it plainly: “‘Discovered - currently not indexed’ means Google knows about the URL but hasn’t yet crawled or indexed it.” The commonly cited drivers are crawl budget and perceived importance — “If your crawlable URLs exceed your crawl budget, you may see the ‘Discovered - currently not indexed’ warning,” and “Google often sees URLs without any or many internal links as unimportant and may not index them.” Those are hypotheses to check, not a checklist that applies identically to every URL: look at the specific page’s internal links, crawl logs, and server response before picking a fix. Reduce crawl waste, speed up the site, and add internal links (and, for the pages that truly matter, request indexing and build links) once you’ve confirmed which of those is actually happening.

“Crawled - currently not indexed” is most often a quality/value verdict. Google’s definition: the page “was crawled by Google but not indexed. It may or may not be indexed in the future.” In other words — Google saw it and passed. In the Ahrefs guide on “Crawled - currently not indexed”: “Google has successfully visited your page but has chosen not to include it in its search index,” and it “typically points to some kind of quality issue.” That’s a strong pattern, not a certainty for every affected URL — some pages carry the label for reasons closer to duplication or timing than quality. The single most useful reframe here comes from John Mueller: this is rarely about one page. As he put it, “you can’t force pages to be indexed — it’s normal that we don’t index all pages on all websites. It’s not an issue with ‘that page’, it’s more site-wide. Creating a good site structure and making sure the site is of the highest quality possible is essentially the direction.” So start by inspecting a sample of the actual affected pages, then work at the site level: raise overall quality, consolidate thin pages, improve structure — not patch one URL and move on.

The clean mental split, as a starting hypothesis rather than a fixed rule: Discovered = crawl-budget/capacity (Google hasn’t gotten to it). Crawled = quality/value (Google got to it and declined). Confirm against your own examples before committing to a fix.

A real audit pattern

When you see “Crawled - currently not indexed” at scale, treat it as a site-wide audit, not a page-by-page chase. I’ve done this on the Ahrefs blog — thousands of crawled pages, working through which low-value or outdated ones to prune, consolidate, or improve rather than trying to force every URL into the index. That pruning mindset is the practical expression of Mueller’s “it’s more site-wide” point: when a chunk of your site reads as low value, the lever is the site, not the individual URL.

How to use Validate fix

When a reason represents a genuine problem and you’ve fixed the underlying cause, click Validate fix on that issue. The mechanics matter:

• It samples, not exhaustively. “When you click Validate Fix, Search Console immediately checks a few pages.”
• It can surface unrelated issues mid-run. “If validation finds other unrelated issues, these issues are counted against that other issue type and validation continues.”
• It’s slow. “Validation typically takes up to about two weeks, but in some cases can take much longer.”
• The state machine runs Started → Passed / Failed / Looking good.

The cardinal rule: fix the underlying cause first. Clicking Validate before you’ve actually fixed anything just burns two weeks ending in “Failed.”

One more thing to be clear on: a passed validation, a favorable report status, a successful URL Inspection, or a submitted sitemap — none of these guarantee indexing, rankings, traffic, or AI-search visibility/citation. They only confirm that the specific signal they check (a directive, a status, a canonical) now matches what you intended. Indexing is necessary for a page to compete in Search; it’s never sufficient on its own.

The sampling caveat, and the sibling reports

One limitation to internalize: the report shows only a capped sample of example URLs per issue, not the full list. The counts are complete, but the example URLs aren’t — so don’t assume the dozen URLs shown are the only ones affected.

That’s exactly why you pair this report with two siblings. The URL Inspection tool is how you check the live index state of a single URL — the report gives you the pattern, URL Inspection confirms one page (and is where you request indexing or a re-crawl). And you can filter the report by a specific sitemap from the Sitemaps report to scope it to just the URLs you actually care about, which cuts through the noise on large sites. The report is the diagnosis layer of the broader indexing picture; these two narrow it down.

A few myths worth killing

• “100% indexed is the goal.” No — “Don’t expect every URL on your site to be indexed.”
• “Crawled - currently not indexed is a penalty or bug.” No — it’s a value judgment; fix site-wide quality.
• “robots.txt disallow and noindex do the same thing.” No — robots.txt blocks crawling; a blocked page can still be indexed URL-only. To remove a page, allow crawling and use noindex.
• “Repeatedly clicking Request indexing forces indexing.” It can’t force indexing of low-value or duplicate pages.
• “A 404 in the report is always bad.” 404s for removed pages are fine and expected.

AI summary

A condensed take on the Advanced version:

• The report (Google Search Console → Indexing → Pages) covers URLs Google already knows about — not a full site inventory — and shows which are indexed, which aren’t, and why. It was renamed from “Index Coverage” to “Page indexing” at Google I/O, May 2022; Google’s current docs use only the new name, but people still search the legacy one.
• It splits everything into Indexed vs Not indexed, then groups not-indexed URLs by reason using a capped sample of example URLs, not a complete export. The Not indexed count is not a problem to zero out — Google: “Don’t expect every URL on your site to be indexed.”
• Many reasons are working as intended: alternate page with proper canonical, page with redirect, intentional noindex, gated 401.
• The two confusing reasons usually point opposite directions, but treat each as a hypothesis, not a verdict. Discovered - currently not indexed = most often crawl-budget/capacity (Google hasn’t crawled it yet). Crawled - currently not indexed = most often quality/value (Google crawled it and declined). Mueller: “it’s more site-wide” — fix site quality, not one page — but confirm against the actual affected pages first.
• Validate fix samples pages, can surface other issues mid-run, and takes ~two weeks. Fix the cause first. Passing it doesn’t guarantee indexing, rankings, traffic, or AI-search visibility — it only confirms the checked signal now matches your intent.
• The report only shows a capped sample of example URLs per issue. Pair it with the URL Inspection tool (single-URL live state) and Sitemaps filtering (scope to URLs you care about).

Official documentation

Primary-source documentation from Google.

Google

• Page indexing report — the canonical Help doc: every not-indexed reason definition, the Validate fix flow, the “don’t expect every URL” guidance, and the URL Inspection + Sitemaps cross-references.
• Index Coverage Data Improvements (Jan 11, 2021) — the pre-rename data overhaul that shaped today’s report.
• URL Inspection tool — check the live index state of a single URL and request indexing.
• Sitemaps report — submit sitemaps and filter the Page Indexing report by one of them.

Quotes from the source

On-the-record statements from Google. Each link jumps to the quoted passage on the source page where the substring is reachable.

Google Search Console Help — what the report is and how to read it

• “See which pages Google can find and index on your site, and learn about any indexing problems encountered.” — Google Search Console Help. Jump to quote
• “Don’t expect every URL on your site to be indexed.” — Google Search Console Help. Jump to quote

Google Search Console Help — the two “currently not indexed” reasons

• “The page was crawled by Google but not indexed. It may or may not be indexed in the future.” (Crawled - currently not indexed) — Google Search Console Help.
• “The page was found by Google, but not crawled yet. Typically, Google wanted to crawl the URL but this was expected to overload the site.” (Discovered - currently not indexed) — Google Search Console Help.

Google Search Console Help — Validate fix

• “When you click Validate Fix, Search Console immediately checks a few pages… If validation finds other unrelated issues, these issues are counted against that other issue type and validation continues.” — Google Search Console Help.
• “Validation typically takes up to about two weeks, but in some cases can take much longer.” — Google Search Console Help.

Google Search Central Blog — the 2021 data overhaul

• “Based on the feedback we got from the community, today we are rolling out significant improvements to this report so you’re better informed on issues that might prevent Google from crawling and indexing your pages.” — Google Search Central Blog, “Index Coverage Data Improvements,” Jan 11, 2021. Read the post

John Mueller, Google — “Crawled - currently not indexed” is site-wide

• “you can’t force pages to be indexed — it’s normal that we don’t index all pages on all websites. It’s not an issue with ‘that page’, it’s more site-wide. Creating a good site structure and making sure the site is of the highest quality possible is essentially the direction.” — John Mueller, Search Advocate, Google.

Every “Not indexed” reason — reason → meaning → fix

Google’s verbatim definitions, the bucket each falls into, and what to actually do.

Crawled vs Discovered, in one line each (starting hypothesis — confirm against your own examples)

• Crawled - currently not indexed = Google saw it and declined → most often quality/value (fix site-wide).
• Discovered - currently not indexed = Google hasn’t visited it yet → most often crawl-budget/capacity (fix crawl health + importance).

Label drift: the report UI shows “Excluded by ‘noindex’ tag”; older Help text said “URL marked ‘noindex’.” Same thing.

Reading the Page Indexing report — checklist

A pass to work through before you “fix” anything:

• Open Indexing → Pages in Google Search Console.
• Don’t panic at the “Not indexed” total — it’s descriptive, not a scorecard.
• For each reason, decide its bucket first: working as intended, a directive you set, or an actual problem.
• Confirm the working-as-intended ones (alternate canonical, page with redirect, intentional noindex, gated 401) and leave them alone.
• For canonicalization reasons, check whether Google chose the URL you wanted; strengthen signals only if it didn’t.
• Triage “Crawled - currently not indexed” as a site-wide quality issue, not page-by-page.
• Triage “Discovered - currently not indexed” as a crawl-capacity / importance issue (crawl health + internal links).
• Remember the report shows only a sample of example URLs — use the URL Inspection tool to confirm any single page’s live state.
• Filter the report by a specific sitemap to scope it to URLs you care about.
• Fix the underlying cause before clicking Validate fix — then expect ~two weeks.

The mental models

1. Indexed vs Not indexed is descriptive, not a target. The Not indexed count is not a number to drive to zero. Google says not to expect every URL to be indexed. Read the report to understand your site, not to score it.

2. Sort every reason into one of three buckets.

• Working as intended — alternate canonical, page with redirect, intentional noindex, gated 401. No action.
• A directive you set — robots.txt block, noindex. Only “fix” if it was a mistake.
• An actual problem — soft 404, 5xx, unintended 404, the two “currently not indexed” reasons. These earn your attention.

3. Crawled ≠ Discovered — but treat both as hypotheses, not verdicts. Crawled - currently not indexed = Google visited and declined → most often quality/value (fix site-wide, per Mueller’s “it’s more site-wide”). Discovered - currently not indexed = Google hasn’t visited yet → most often crawl-budget/capacity (fix crawl health and importance signals). Confirm against the actual affected pages before committing to a fix; almost everything else follows once you’ve got the right diagnosis.

4. Diagnose, then confirm, then scope. The report = the pattern (which reasons, roughly how many). The URL Inspection tool = the live state of one URL. The Sitemaps filter = scope to URLs you actually care about. Use all three; don’t reason from the sample alone.

5. Cause first, Validate second. Validate fix samples pages and takes ~two weeks. Clicking it before you’ve fixed the root cause just delays a “Failed.”

What should you do with a “Not indexed” URL?

Page Indexing mistakes that create busywork

Optimizing for 100% indexed

Why it’s wrong: redirects, duplicate alternates, deleted URLs, gated pages, and intentional noindex pages can all belong outside the index. Do instead: define the set of URLs that should be canonical and indexable, then measure coverage of that set.

Treating crawled and discovered as the same problem

Why it’s wrong: “Discovered — currently not indexed” means Google has not crawled the URL; “Crawled — currently not indexed” means it fetched the URL and did not select it. Do instead: investigate crawl capacity and importance for discovered URLs, then quality, value, and duplication for crawled URLs.

Blocking a noindexed URL in robots.txt

Why it’s wrong: robots.txt can prevent Google from crawling the page and seeing the noindex directive. Do instead: allow crawling while Google processes noindex, or use the correct removal/status-code strategy for the situation.

Repeatedly requesting indexing

Why it’s wrong: the request is a recrawl hint, not a command to include a page. Repeated clicks do not repair weak value, conflicting canonicals, or blocked access. Do instead: fix the underlying reason, verify the live result, then submit once.

Fixing every 404 in the report

Why it’s wrong: a real 404 or 410 is the right response for a permanently removed URL with no replacement. Do instead: restore URLs that should exist, redirect only to a genuinely equivalent replacement, and leave intentional removals alone.

Prove an indexing fix took effect

Confirm the live page is eligible

Test to run — Use URL Inspection’s live test after changing status codes, directives, access, rendering, or canonicals. Expected result — the page is fetchable, the intended canonical/directives are visible, and no unintended block or server error appears. Failure interpretation — the deployed page still differs from the intended configuration. Monitoring window — Immediate for the live test. Rollback trigger — Revert if the change blocks, noindexes, redirects, or canonicalizes intended pages incorrectly.

Confirm Google processed the fix

Test to run — Start Validate fix for the affected issue and monitor sampled URLs, while spot-checking key URLs with URL Inspection. Expected result — sample URLs pass and the affected issue count trends down as Google recrawls. Failure interpretation — the fix is incomplete across templates or Google has not processed enough URLs yet. Monitoring window — Multiple crawls/report refreshes; indexing is not an immediate signal. Rollback trigger — Stop the rollout if a growing set of previously indexed, intended URLs moves into the issue.

Reconcile the intended sitemap cohort

Test to run — Filter Page Indexing by the submitted sitemap and compare its intended URLs with the sitemap report, crawl data, and index checks. Expected result — canonical indexable sitemap URLs are indexed or moving through the expected processing state, while exclusions are explainable. Failure interpretation — the sitemap contains redirects, non-canonicals, errors, or low-value URLs, or important URLs lack crawl/index signals. Monitoring window — Review after recrawl and on the next regular report cycle. Rollback trigger — Revert a sitemap generation change that removes or replaces the intended canonical URL set.

Tools for working the report

• Google Search Console — Page Indexing report — Indexing → Pages; the report this whole article is about.
• URL Inspection tool (GSC) — check the live crawl/render/index state of a single URL, and request indexing or a re-crawl. The report tells you the pattern; this confirms one page.
• Sitemaps report (GSC) — submit sitemaps, then filter the Page Indexing report by a specific sitemap to scope it to the URLs you care about.
• Crawlers / site audits — Ahrefs Site Audit and Screaming Frog SEO Spider surface duplicates, redirect chains, soft 404s, and blocked URLs so you can cross-reference what the report flags.
• Ahrefs Webmaster Tools — free crawl + audit for sites you verify.

Resources worth your time

My related writing (Ahrefs)

• How to Fix “Discovered - currently not indexed” — the crawl-budget/importance reason, in depth (I’m a reviewer on this one).
• What “Crawled - Currently Not Indexed” Means in Google Search Console — the quality/value reason and how it differs from Discovered.
• Indexed, though blocked by robots.txt — why a robots.txt block doesn’t remove a page from the index.
• The Beginner’s Guide to Technical SEO — where indexing fits in the bigger picture.

From around the industry

• Page indexing report — Google’s own Help doc is the primary reference; keep it open while you read your report.
• Index Coverage Data Improvements (Jan 11, 2021) — Google Search Central Blog post announcing the 2021 data overhaul that shaped today’s report.
• Google Makes 4 Changes to Index Coverage Report — Search Engine Journal’s coverage of the January 2021 improvements, with the Google rollout quote and context.
• Crawled Currently Not Indexed Possibly A Sign Of A Google Quality Issue — Search Engine Roundtable’s report on John Mueller’s “it’s more site-wide” framing for this status.
• Google Search Console coverage to Pages reports rename — Search Engine Roundtable’s coverage of the Index Coverage → Page Indexing rename.
• Search Engine Journal — Technical SEO — broader Technical SEO coverage including indexing topics and GSC updates.
• r/TechSEO — the community for crawl/index debugging.

Videos

• Google Search Central (YouTube) — the How Google Search Works series and Search Console explainers from the Search Relations team, including indexing troubleshooting. Channel

The standing KPI for indexing health

The raw “Indexed” count in the report is a vanity number on its own — a site can have thousands of indexed URLs and still have the wrong ones indexed. The KPI that actually tracks health is the ratio of pages you want indexed to pages that are.

Intended-indexable coverage ratio

• Metric — Indexed pages ÷ pages you intend to be indexable — i.e. of the URLs that should rank (canonical, in your sitemap, valuable), how many are actually in the index.
• What it tells you — Whether your important pages are reachable and accepted by Google. A ratio that drifts down — or a “Not indexed” bucket that fills with URLs you did want — is an early warning that beats watching the total count.
• How to pull it — GSC Page Indexing report (Indexed vs. Not indexed, broken out by reason); spot-check individual URLs with the Google Index Checker; and reconcile crawled vs. indexed vs. sitemapped URLs with the Indexation Reconciler to see which side the gap is on.
• Benchmark / realistic range — Situational — it depends entirely on how many low-value URLs your CMS generates, so there’s no honest universal target. The right bar: the pages that should be indexed are, and the “Not indexed” bucket is deliberate (parameters, filters, thin variants) rather than accidental. Establish your own intended-indexable count as the baseline.
• Cadence — Weekly during a migration or a large content release (when the ratio moves fast), otherwise monthly.

Test yourself: the Page Indexing report

Five quick questions on diagnosing indexed and excluded URLs. Pick an answer for each, then check.

Index Coverage Report

The Google Search Console report (renamed from "Index Coverage" in 2022) that shows which URLs Google has indexed, which it hasn't, and why. It splits your known URLs into Indexed and Not indexed, grouping the not-indexed ones by reason.

Related: Google Search Console, URL Inspection tool, Sitemaps report, Indexing

Index Coverage Report

The Page Indexing report is the Google Search Console report that shows which URLs on your site Google has crawled and indexed, which it hasn’t, and the reason for each. It was called the Index Coverage report until Google renamed it “Page indexing” in 2022, so you’ll still see plenty of people searching for “index coverage report” or just “coverage report.”

The report splits your known URLs into two buckets: Indexed (eligible to appear in Search) and Not indexed. The not-indexed URLs are then grouped by reason — things like “Crawled - currently not indexed,” “Excluded by ‘noindex’ tag,” “Page with redirect,” and “Duplicate without user-selected canonical.” Each reason links to a sample list of affected URLs.

A big part of reading this report well is knowing that not indexed is not automatically a problem. Many of the reasons are pages working exactly as intended — canonicalized duplicates, intentional redirects, deliberately noindexed pages. Where a reason genuinely is a fix, the report gives you a Validate fix button that asks Google to re-check. Pair it with the URL Inspection tool to confirm a single page’s live state, and filter it by your Sitemaps report to scope it to the URLs you actually care about.

Related: Google Search Console, URL Inspection tool, Sitemaps report, Indexing

Changelog