How to read the page indexing report, one reason at a time

The page indexing report is the only place that tells you why Google left pages out, across the whole site at once. Read it as two questions, not one: are the pages you care about in the indexed bucket, and is every reason in the not-indexed bucket a reason you chose. Most of what sits in that second bucket is supposed to be there. The triage table below says which rows are yours to fix.

Before you start

You need a verified Search Console property and a site with enough pages that checking them one at a time is no longer practical. If you only need to know the status of a single address, that is a different tool and a faster answer — how to read the URL Inspection tool covers it line by line. This chapter is the whole-site view, and it answers a question the single-URL tool cannot: which of your problems is happening 400 times.

Why "not indexed" is not an error list

The report's own description is modest: "See which pages Google can find and index on your site, and learn about any indexing problems encountered" (Page indexing report, Google Search Console Help, read 2026-09-07). It splits your known URLs into two buckets. Indexed means "these URLs were successfully indexed". Not indexed means "the URL is not indexed, either because of an indexing error, or because of a legitimate reason."

That last clause is the whole chapter. The two categories are mixed together in one bucket and one count, and the count going up is not by itself bad news. Google says so directly: "Don't expect every URL on your site to be indexed. Some URLs might be duplicates or might not contain meaningful information. Just be sure that the key pages on your site are indexed." And more pointedly: "Non-indexed URLs can be fine. Read and understand the specific reason for each non-indexed URL to confirm that the page shouldn't be indexed."

The number in the not-indexed bucket is not a score. The reason strings under it are the report.

A site with pagination, filters, redirects and a canonical strategy will accumulate thousands of legitimately excluded URLs, and a chart trending upward is what a growing site looks like. The failure mode is the opposite of panic — it is never opening the reasons, because the total looked stable.

Do it: read the page indexing report in this order

Five steps. Doing them out of order is how people end up fixing a row that was never a problem.

1. Check the indexed count first, not the not-indexed count. Ask whether it is roughly the number of pages you intend to have indexed. Finish line: a written expected number, and the gap between it and the report.
2. Open the not-indexed list and sort by page count. The reasons are ranked by how many URLs sit under each, and the top two or three usually account for most of the bucket. Finish line: the top three reasons written down with their counts.
3. Classify each of those reasons using the table below before touching anything. Finish line: every one of your top reasons is marked as expected or as yours to fix.
4. For any row you marked as yours, open its example URLs and inspect two or three individually. The report tells you the category; the single-URL tool tells you what happened to a specific address. Finish line: you can name the cause on a real URL, not just the category.
5. Fix the cause, then use Validate fix on that row. Finish line: the row shows a validation in progress, and you have written down the date you started it.

Step five comes with a documented waiting period, so set expectations before you start it: "Validation typically takes up to about two weeks, but in some cases can take much longer."

Deliverable: the reason triage table

Google's own definition for each status, and what it means for you. The right-hand column is the one to read first — five of these ten rows are normal on a healthy site.

Two rows deserve extra care because they are the ones people try hardest to fix with the wrong tool. Crawled - currently not indexed has no lever attached to it: Google states in the same breath that there is "no need to resubmit this URL for crawling". Resubmitting is the most common response and it is explicitly not the answer. Discovered - currently not indexed is different — Google names a cause, and it is about your server, so the useful move is to look at response times rather than at the page.

The other trap is a limit on the report itself, not on your site. "The list of example URLs in the report is limited to 1,000 items, and isn't guaranteed to show all URLs in a given status." The counts are the data; the URL lists are samples. Do not treat an example list as an inventory, and do not conclude a row is fixed because the addresses you recognise stopped appearing in it.

Three ways this goes wrong

The first is treating the not-indexed total as a health metric and watching it instead of the reasons. It rises when you add pagination, when you set canonicals correctly, and when you redirect old URLs — three things you did on purpose. Watch the indexed count against your expected number, and watch the composition of the reasons.

The second is fixing the largest row because it is largest. On most sites the biggest row is Page with redirect or Alternate page with proper canonical tag, and Google's own text for the second one ends with "there is nothing you need to do". Size ranks the rows by volume, not by whether they are problems.

The third is validating before fixing. Validate fix asks Google to re-check the URLs in that row, and starting it while the cause is still live spends up to two weeks arriving at the same answer. Confirm the fix on two or three example URLs individually first, then validate the row.

Where this stops

Four limits. The first two are about what the report will not tell you at all.

1. It reports on URLs Google knows about. Pages nobody links to and no sitemap lists do not appear as a problem here, because they are not in the report at all. Finding those is a different job with a different input.
2. Indexed does not mean ranking, and this report says nothing about traffic. A page can sit in the indexed bucket for months without an impression, and the report for that question is a different one.
3. The URL lists are capped at 1,000 examples per status and are not guaranteed to be complete, so this report is for finding categories and rough sizes, not for exporting a task list.
4. We are not going to tell you how long a fix takes to show up beyond Google's own "up to about two weeks, but in some cases can take much longer". We have not measured it on a controlled sample, and neither has anyone quoting you a firmer number.

Two of these rows point straight at chapters that fix them. The noindex row and the robots.txt row are both about deliberate exclusion, and choosing between those two mechanisms is when to noindex a page. The Discovered and Crawled rows are both about waiting, and what the realistic windows look like is in how long does it take to get indexed. If the report shows pages arriving but never being kept, the thing worth checking is what a crawler is handed in the first place — see what QueryWin reads from a page.

Common questions

What does "Crawled - currently not indexed" mean?

Google fetched the page and decided not to index it, at least for now. The documentation says it "may or may not be indexed in the future" and adds that there is "no need to resubmit this URL for crawling". There is no switch that moves a page out of this row, which is why it frustrates people. It is a judgement about the page, so the work is on the page.

Is a high not-indexed count bad?

Not by itself. Google's guidance is to expect it: "Don't expect every URL on your site to be indexed. Some URLs might be duplicates or might not contain meaningful information." Redirects, alternates with correct canonicals and deliberately excluded pages all land there. Read the composition rather than the total.

How long does Validate fix take?

Google says validation "typically takes up to about two weeks, but in some cases can take much longer". Start it only after you have confirmed the fix on individual URLs, because a validation run against an unfixed cause spends that entire window returning the same result.

Why does the report show fewer URLs than my site has?

Two separate reasons, and they are easy to confuse. The report only covers URLs Google has discovered, so pages with no links and no sitemap entry are absent rather than flagged. Separately, the example lists are capped at 1,000 per status and are not guaranteed to be complete, so a short list does not mean a small row — the count above it is the number to read.

Should I use this report or the URL Inspection tool?

Both, in that order. This report tells you which categories of problem you have and how big each one is; the single-URL tool tells you what happened to one specific address. Going straight to individual inspection on a large site means checking addresses one at a time without knowing which pattern is worth checking.