Search Console Coverage Report: Fix, Wait, or Ignore

Search Console's coverage report, now called the page indexing report, files every URL Google knows about under three statuses: not indexed, indexed with a warning, and indexed. Under "not indexed" sits a long list of reasons. Google also ships a column telling you which of those reasons aren't yours to fix, and almost nobody uses it. [1]

That column is the fastest way to cut the report down to something you can act on, and it's the part every guide on this report leaves out.

Below: what the three statuses mean now, the two sentences in Google's own help page that disqualify most of the list, and the mapping we run in production that collapses every reason string into one of three verbs.

TL;DR:

• Google's Source column says whether an issue came from your site or from Google. The instruction beside it is blunt: "In general, you can fix only issues where the source is listed as 'Website'." [1]
• The table is "sorted by what we think are the most important issues to address," [1] which is Google's sense of importance. It has no idea which of your pages earn clicks.
• "Not indexed" isn't a synonym for broken. Google's own definition allows for "a legitimate reason." [1]
• Three verbs cover the whole state list: fix it, wait, or leave it alone. On most sites the third group is the biggest.

What does the coverage report actually show?

It shows counts, grouped by reason. Google's current documentation splits every known URL into Not indexed, a small warning tier (indexed but with a problem worth knowing about), and Indexed. Under the not-indexed status sit the specific reasons: server errors, redirects, robots.txt blocks, noindex tags, soft 404s, crawled-not-indexed, discovered-not-indexed, and several flavors of duplicate. [1]

One thing to check before you trust any guide you're reading, including one that ranks well: if it describes four categories called Valid, Valid with warnings, Excluded, and Error, it's describing a version of this report that no longer exists. Those four names appear nowhere in Google's current documentation. Google simplified the classification in June 2022, in a post titled "Simplifying Search Console reports with an updated item classification." [2] Plenty of pages ranking for "coverage report" today still teach the old vocabulary, which is a decent proxy for how recently they were checked.

The rename matters less than the regrouping. What you're looking at now is a list of causes, and a cause is not an instruction.

Which coverage states are yours to fix?

The ones where Google says the source is your website. This is the column people scroll past: "The Source value in the table shows whether the source of the issue is Google or the website." And then the part worth pinning to the wall: "In general, you can fix only issues where the source is listed as 'Website'." [1]

Read that as what it is. Google ships a field in its own report that marks a chunk of the rows as not your problem. A redirect Google resolved, a duplicate it folded into a canonical it picked, an alternate page with a proper canonical tag: those are Google's systems working, recorded as report rows because the report records everything, not because there's an action attached.

The practical effect is a fast first cut. Before reading a single URL, you can drop every row Google has already attributed to itself, and what's left is the part where opening your editor could change something. That's usually a much shorter list than the headline number suggests, and it explains the most common reaction to this report, which is to look at a four-digit not-indexed count and close the tab.

What the column can't do is rank what's left. It tells you which rows are actionable, not which are worth acting on.

Why is the report sorted the way it is?

By Google's judgment of severity, which Google states outright: "The table is sorted by what we think are the most important issues to address." [1] That's an honest sentence and a useful one, because it tells you exactly whose priorities you're reading. They aren't yours.

Google's ordering knows about error classes. A 5xx outranks a soft 404, which outranks a duplicate. What it cannot know is which of your URLs matter, because the page indexing report has no traffic data in it. A server error on a URL nobody has ever visited sorts above a noindex tag on the page that earns a third of your clicks.

So the report's sort order is a technical severity ranking wearing the costume of a priority list. Those are different things, and the gap between them is the whole reason a coverage report gets read top-down once and then abandoned. The ordering you actually want is severity crossed with what the page was earning, and that second input sits in a different Search Console report entirely, which is why ranking unindexed pages by what they were costing you has to happen outside this one.

This is the same shape as treating a large not-indexed count as a list of page-level jobs when it's really one site-level signal. The report is describing itself accurately. It's just answering a question next to the one you asked.

Does "not indexed" mean something is broken?

No, and Google's own definition says so in the same breath: "Not indexed: The URL is not indexed, either because of an indexing error, or because of a legitimate reason." [1] The status covers both a page you broke and a page you deliberately excluded, with no visual difference between them.

Legitimate reasons are common and mostly boring. A noindex tag you added on purpose. A staging path in robots.txt. A tag archive that shouldn't rank. A ?sort=price variant Google correctly folded into the clean URL. Every one of those is the system working, and every one of them counts toward the number that made you open the report.

Two statuses are genuinely ambiguous and need separate reading, because they look identical in the count and have opposite first moves. Google crawled the page and declined to keep it is a judgment about your content. Google found the URL and hasn't fetched it means nobody has evaluated anything yet. Same bucket in the report, different jobs on your desk.

The honest default for everything else is to decide once and record the decision, so the same row stops presenting itself as new work every month.

How do the states collapse into three actions?

Into fix, wait, or leave alone. That's the mapping our own indexing check runs, and it's deliberately coarser than Google's list because the reason string is only interesting insofar as it changes what you do next. Every coverage state Google emits lands in one of three groups:

• Fix it (the block is on your site). A 404 or "not found", a soft 404, a noindex tag, a robots.txt block, a server error or 5xx. These are the rows where Google's Source column says Website, and they're the only group where an edit today changes the outcome. Read them first regardless of where the report sorted them.
• Wait (nobody acts yet). Crawled and not kept, discovered and not crawled, and URLs Google has no record of at all. Nothing here is broken in a way you can patch, and on a young site this group resolving itself is the normal outcome. Doing work here is how people spend a week on a page that was only ever queued.
• Leave it alone (Google is handling it). Redirects, alternate pages with a proper canonical, duplicates where Google picked a canonical. This is usually the largest group by a wide margin and needs no work whatsoever. It's also the group that makes the headline count frightening.

Worth noticing what happened there. Google's Source column is a two-way split, your site or Google's systems, and our grouping came from that same axis. But there's a third case its binary has no room for: the pages where neither party acts and that's correct. A queued URL isn't Google's issue to fix and it isn't yours either. Splitting "wait" out from "fix" is the single change that stops a coverage report from generating busywork, because those two look the same in Google's report and are opposites in practice.

The grouping is intentionally boring. Nine plain-English labels, each carrying the one action that goes with it, so the answer to "what do I do about this row" is on the row.

Where does this grouping get it wrong?

In one specific place, and it's worth stating because it's a limit in our own code rather than a general caveat. The mapping matches Google's state strings by substring, so a state we don't recognize falls through to a default. That default is wait, the do-nothing group.

That's a deliberate choice with a real cost. It fails safe, in the sense that an unfamiliar status never manufactures a task or tells you to edit a page based on a string nobody has read. But it also means a genuinely new blocking state that Google introduces tomorrow gets quietly filed as "nothing to do" until someone updates the mapping. Under-alarming is the better failure for a tool that runs daily and unattended, and it is still a failure.

The substring matching itself exists because these labels move. Google reworded this whole report once already, and matching on "robots" rather than the exact sentence Google shipped this quarter is what keeps a rename from silently emptying a group. It's a defense against exactly the churn that left half the internet's guides describing Valid and Excluded.

Three more limits ride along, and they apply to every tool in this category:

• The report is not per-page. Google says so directly: "This report isn't used to investigate the index status of specific pages." [1] It gives counts and a sample. For one URL you want the inspection panel and its four ways of misleading you.
• Coverage is reconstructed, not read. The full page indexing report exists only in the Search Console interface and is exposed by no API. Every tool here, ours included, rebuilds it by inspecting the URLs it knows about, which come from your sitemap.
• You may not need it at all. Google's own line: "If your site has fewer than 500 pages, you probably don't need to use this report." [1] Most people reading a coverage-report guide are well under that, which is why checking the handful of pages you actually care about beats reading the report at all.

Reading coverage without opening the report

By hand this is a sorting job you do once. You open the report, meet a number, expand a group, get URLs with no priority order and no traffic attached, and close it. The classification is fine. The problem is that it stops one step short of a decision, every time, and that step is the same step every time.

QueryScope does the grouping and the ranking in your editor, which is where the missing input lives: your agent has the repo open, so the noindex tag, the canonical, and the internal links it's reasoning about are right there. The states arrive already split into fix, wait, and leave alone, with the pages that were earning clicks named first rather than sorted by error class. Separating the blocks worth fixing from the noise is the job that turns a four-digit count into a morning.

Whatever you use, the move is the same: cut the rows Google attributed to itself, split what's left into fix and wait, and record the ones you're deliberately leaving out. For the one-line meaning of each coverage state and its caveat, the Search Console glossary covers them individually.

Sources

• Google Search Console Help, Page indexing report ("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'"; "The table is sorted by what we think are the most important issues to address"; "Not indexed: The URL is not indexed, either because of an indexing error, or because of a legitimate reason"; "This report isn't used to investigate the index status of specific pages"; "If your site has fewer than 500 pages, you probably don't need to use this report"). [1]
• Google Search Central Blog, Simplifying Search Console reports with an updated item classification, June 2022 (the announcement of the updated item classification; the current status names are quoted from the help page above, not from this post). [2]