Search Console's Page indexing report: what each status means and what to do
The Page indexing report in Google Search Console answers one question: which of the URLs Google knows about on your site are in its index, and why the rest are not. It is one of the most useful reports in Search Console, and one of the most misread. A large "Not indexed" number looks alarming, but it is often perfectly healthy.
This guide explains how to read the report, what each status means, and which ones deserve your time.
What the report actually shows
Open Indexing → Pages in Search Console. The chart splits known URLs into two groups: Indexed and Not indexed. Below it, the "Why pages aren't indexed" table groups the not-indexed URLs by reason, and each reason has a source: Website (something your site did) or Google systems (a decision Google made).
Click any reason to see example URLs and a trend over time. Click a URL to open it in the URL Inspection tool, which shows the most detailed information Google has about that single page.
Two things to keep in mind:
- The report covers URLs Google has discovered, including old URLs, parameter variations and links from other sites. Many of them should never be indexed.
- The data is not real time. It usually lags a few days behind what is happening on your site.
Is it a problem that pages aren't indexed?
Often, no. Google's own help documentation says it directly: don't expect every URL on your site to be indexed. Duplicates, redirected URLs, filtered or sorted variations, and pages you have deliberately excluded all belong in "Not indexed".
The real question is narrower: are the pages you want in Google actually in Google? That is why the most useful way to read this report starts from your own list of important pages.
Start from the pages that matter
Create an XML sitemap that lists only the canonical URLs you want indexed: your service or product pages, key categories, important articles. Submit it in Search Console. Then use the filter at the top of the Page indexing report to switch from All known pages to All submitted pages, or to that specific sitemap.
Now every "Not indexed" URL in the report is a page you said you wanted indexed. That turns a noisy report into a focused to-do list. If your site generates many page types, separate sitemaps per type (services, products, articles) make it easy to see which section has a problem.
Every status, and what to do about it
| Status | What it means | Usually needs action? |
|---|---|---|
| Crawled – currently not indexed | Google fetched the page but chose not to index it | Only if it's an important page |
| Discovered – currently not indexed | Google knows the URL but hasn't crawled it yet | Only if it persists for important pages |
| Duplicate without user-selected canonical | Google sees it as a duplicate and you haven't said which version is canonical | Yes, if duplicates are unintended |
| Duplicate, Google chose different canonical than user | You declared a canonical, Google picked another | Yes, check why |
| Alternate page with proper canonical tag | The page points to another canonical, as intended | No |
| URL marked noindex | The page carries a noindex directive | Only if it shouldn't |
| URL blocked by robots.txt | Crawling is blocked | Only if it shouldn't be |
| Page with redirect | The URL redirects elsewhere | No, check the target |
| Not found (404) | The URL returns 404 | Only if linked or in a sitemap |
| Soft 404 | The page looks like an error page but returns 200 | Yes |
| Redirect error | A broken, looping or overly long redirect | Yes |
| Server error (5xx) | The server failed when Google requested the page | Yes |
| Blocked (401 / 403 / other 4xx) | Access was refused | Yes, if the page should be public |
Crawled – currently not indexed
Google crawled the page and decided not to index it, at least for now. Google's documentation says no action is needed and that the page may be indexed later, and for unimportant URLs that is true. For an important page, treat it as a signal. The common causes are:
- The page adds little that isn't elsewhere. Thin content, near-duplicate location or product pages, or an article that repeats what already ranks.
- Weak internal linking. A page linked from nowhere except the sitemap looks unimportant.
- The site has a quality problem more broadly. When many pages sit in this status, the issue is usually site-wide, not page-specific.
Improve the page and its internal links rather than repeatedly requesting indexing. Requests don't change Google's assessment of the page.
Discovered – currently not indexed
Google knows the URL exists but hasn't crawled it. Google's help pages explain this often happens when crawling was rescheduled to avoid overloading the site. On a small site, a few URLs here is normal. A large and growing number usually means Google is finding more URLs than it considers worth crawling: faceted navigation, parameters, auto-generated pages, or a site that has grown faster than its authority. Reducing low-value URLs and strengthening links to important ones helps.
Duplicate without user-selected canonical
Google considers the page a duplicate of another URL, and you haven't declared a canonical. Decide which version should be indexed and say so consistently: a canonical tag on the duplicates, internal links pointing to the preferred URL, and only the preferred URL in your sitemap. If the pages are not meant to be duplicates, make their content genuinely different.
Duplicate, Google chose different canonical than user
You declared a canonical, but Google chose another URL. Canonical tags are strong hints, not commands. Google overrides them when other signals disagree: internal links point elsewhere, the sitemap lists another version, redirects contradict the tag, or the "canonical" page is not actually similar to the duplicate. Use URL Inspection to see which URL Google selected, then make all signals point the same way.
Alternate page with proper canonical tag
This is working as intended. The page points to a canonical that Google has accepted. You'll often see mobile, AMP, parameter or tracking variants here.
URL marked noindex
The page carries a noindex directive in a meta robots tag or an X-Robots-Tag header. If that's deliberate, for a thank-you page or an internal search result, nothing needs doing. If an important page is listed here, find where the directive comes from. It is a classic leftover from a staging site or a CMS setting, and it can remove pages from Google entirely.
URL blocked by robots.txt
Google did not crawl the URL because robots.txt disallows it. Remember that robots.txt controls crawling, not indexing. A blocked URL can still appear in Google if other pages link to it, usually without a description. That shows up as the warning "Indexed, though blocked by robots.txt". If you want a page kept out of Google, allow crawling and use noindex, so Google can actually see the instruction.
Page with redirect
The URL redirects somewhere else, so it isn't indexed itself. That's normal after URL changes. Check the target is indexed and that internal links point straight to the final URL instead of through redirects.
Not found (404) and soft 404
A 404 for a page that no longer exists is correct and harmless. Only act if the URL is linked from your own site, listed in a sitemap, or had valuable external links. In that case, redirect it to the closest relevant page.
A soft 404 is different: the page returns a normal 200 status, but looks like an error or an empty page to Google. Empty category pages, "no results" pages and thin placeholder pages are frequent causes. Return a real 404 or 410 for pages that don't exist, or add real content to pages that should.
Redirect error, server errors and blocked access
Redirect errors cover loops, chains that are too long, and redirects to invalid URLs. Fix them at the source, ideally with a single permanent redirect to the final URL.
Server errors (5xx) mean your server failed when Googlebot asked for the page. Occasional errors are normal; a pattern is not. Check the Crawl stats report under Settings for host problems, and your hosting or CDN logs for the cause.
401, 403 and other 4xx statuses mean access was refused. If the pages should be public, check authentication, firewall and bot-protection rules. Security tools sometimes block Googlebot by mistake.
After you fix something
- Inspect a sample URL. Use URL Inspection and Test live URL to confirm Google now sees the fixed version.
- Request indexing for a handful of important pages if you want them recrawled sooner.
- Click Validate fix on the issue once all affected pages are fixed. Google rechecks the URLs and reports progress. Google says validation typically takes up to about two weeks, and can take longer.
- Annotate the date of the fix in your own records, so you can connect it to changes in performance later.
Common misreadings to avoid
- Chasing the "Not indexed" total down to zero. On most sites that number is supposed to be large.
- Resubmitting pages again and again. Requesting indexing doesn't override Google's assessment of a page's value.
- Blocking duplicates with robots.txt. Blocked pages can't pass their signals to the canonical, and Google can't see their canonical tags.
- Ignoring source labels. Issues marked Website are yours to fix. Issues marked Google systems usually call for better content or clearer signals, not a technical fix.
The Page indexing report is at its best as a monitoring tool. Check it after every release, watch for sudden changes in any status, and investigate the important pages first. If a jump coincides with a deployment, the cause is almost always in that deployment.
