Search Console Page Indexing Report: Every Status Explained

You opened Search Console and saw a long list of pages marked “Not indexed”. Now you want to know which of them actually matter. Here’s the short answer. The page indexing report shows every URL Google knows about on your site. It splits them into indexed and not indexed, and gives a reason for each page left out. Most of those reasons are normal. A few point to real problems you should fix.

What the Page Indexing Report Actually Shows

You’ll find the report under Indexing > Pages in Search Console. If you’re new to the tool, our beginner’s guide to the Search Console reports that matter shows where everything sits.

The summary page has three main parts:

• A chart of indexed and not indexed pages over time.
• A “Why pages aren’t indexed” table. It lists each reason, how many URLs it affects, and its validation status.
• A separate warnings table for pages that are indexed but have an issue worth a look, such as “Indexed, though blocked by robots.txt”.

Each reason has a Source column that says either “Website” or “Google”. Website means something on your side caused it, such as a noindex tag or a server error. Google means Google made the call, such as choosing not to index a crawled page. Usually you can only fix issues with the source Website directly.

Use the Sitemap Filter First

At the top of the report is a dropdown set to “All known pages” by default. Switch it to “All submitted pages” to see only URLs in your sitemaps. In my view, this is the most useful filter in the whole report, and it’s the first thing I change.

“All known pages” includes every parameter URL and stray duplicate Google has found. The submitted view shows the problems on the pages you actually care about.

Know the Report’s Limits

• The example list for each reason shows up to 1,000 URLs. Google doesn’t promise it shows every affected URL.
• The report shows Google’s last crawl, which can be weeks old. A page may already be fixed even though it still appears under an issue.
• The report doesn’t check single pages live. For that, you need the URL Inspection tool.

Every “Why Pages Aren’t Indexed” Reason Explained

For each status, the key question is simple: did you want this page to be indexed?

Crawled – Currently Not Indexed

Google fetched the page, looked at it, and decided not to add it to the index for now. There’s no technical error. It’s a judgement call.

Should you act? Only for pages you really want in search. Tag pages, thin archive pages and filtered URLs often land here, and that’s fine.

How to fix it for important pages:

• Make the page clearly more useful than similar pages on your site and elsewhere. Thin or near-copy content is the most common cause.
• Link to it from relevant, well-linked pages. A page with no internal links sends a weak signal. Orphan pages (pages no other page links to) are a frequent cause.
• Check rendering with Test live URL. If key content loads only through JavaScript that fails, Google may see a nearly empty page.
• Request indexing only after you’ve made a real change. Asking again for an unchanged page rarely helps. I see people do this over and over, and it wastes time.

Discovered – Currently Not Indexed

Google knows the URL exists, usually from a link or sitemap, but hasn’t crawled it yet. The “Last crawled” date in URL Inspection will be empty. Google usually reschedules the crawl because fetching it right away might have overloaded your server, or because it didn’t see the URL as a priority.

Should you act? On a small site with a handful of URLs here, wait. On a large site with thousands of important URLs stuck here, look at how well Google can crawl the site.

How to fix it:

• Check Crawl Stats (Settings > Crawl stats) for slow response times or server errors.
• Cut low-value URLs that compete for crawling, such as endless filter combinations and session parameters.
• Add more internal links to the pages you want crawled first.

Duplicate Without User-Selected Canonical

Google sees this page as a copy of another URL, and you haven’t set a canonical (the main version you want Google to use). So Google picked one version itself and left this one out.

Should you act? Not if Google picked the right version. Inspect the URL and look at “Google-selected canonical”. If that’s the page you would have chosen, you’re done.

How to fix it if Google chose wrong: add a rel="canonical" tag pointing to your preferred URL. Keep internal links and sitemaps in line with that choice. Use redirects where the copy has no reason to exist. If the page isn’t really a copy, make its content different. Our article on what Google really does with duplicate content explains how it picks a canonical.

Duplicate, Google Chose Different Canonical Than User

You set a canonical, but Google decided another URL is the better choice. Google treats your canonical tag as a strong hint, not an order.

How to fix it: in URL Inspection, compare the user-declared canonical with the Google-selected one. Then check that your signals agree. Internal links, sitemap entries, hreflang and redirects should all point to the same preferred URL. If the declared canonical isn’t really similar to the page, Google will often ignore it. In my experience, mixed signals are behind this status most of the time.

Alternate Page With Proper Canonical Tag

This page correctly points to another URL as its canonical, and Google has accepted that. Examples include AMP versions and URLs with tracking parameters.

Should you act? No. This is the canonical tag working as it should.

Excluded by ‘noindex’ Tag (URL Marked ‘noindex’)

Google found a noindex instruction in a meta robots tag or an X-Robots-Tag HTTP header, so it left the page out.

Should you act? Scan the list. Login pages, thank-you pages and internal search results belong here. Product pages, blog posts and service pages don’t.

How to fix it: remove the tag or header. Then run Test live URL to confirm Google no longer sees it. Common causes include a CMS “discourage search engines” setting left on after launch, an SEO plugin applying noindex to a whole post type, or a staging header copied to the live site. I usually see that last one after a site launch. Check the HTTP header too, because it won’t show in the page source:

curl -I https://www.example.com/page/
X-Robots-Tag: noindex

Blocked by robots.txt

Your robots.txt file tells Googlebot not to crawl this URL. Google respects that, so it can’t see the page content.

Should you act? Only if you want the page in search. If so, remove or narrow the Disallow rule.

One important point: robots.txt controls crawling, not indexing. If you want to keep a page out of Google, blocking it is the wrong tool. Allow crawling and add noindex instead, because Google has to crawl the page to see the noindex.

Not Found (404)

The URL returned a 404 status. Google found it through a link, an old sitemap, or because the page used to exist.

Should you act? Usually not. A 404 for a page you deleted with no replacement is the correct response. It doesn’t harm the rest of your site.

When to fix it: if the content moved, add a 301 redirect to the new URL. If you see 404s for URLs that should exist, look for broken internal links or a sitemap that lists dead URLs. Our guide to 301 vs 302 redirects covers which one to use.

Soft 404

The page returns a 200 “success” status, but to Google it looks like an error or empty page. Typical examples are “no products found” category pages, out-of-stock pages with almost no content, and custom error pages that return 200.

How to fix it:

• If the page is really gone, return a real 404 or 410 status.
• If it moved, redirect it.
• If it’s a real page, give it enough content so it no longer looks empty.

Page With Redirect

The URL redirects somewhere else, so it isn’t indexed. The destination may be indexed instead.

Should you act? No, if you meant the redirect. Just confirm the destination URL is indexed.

Redirect Error

This is different from “Page with redirect”. Here, Google couldn’t follow the redirect at all. Causes include redirect loops, chains that are too long, a URL longer than the maximum length, or an empty or bad URL in the chain.

How to fix it: trace the redirect step by step with a browser developer tool or curl -IL. Then point the original URL straight at the final destination in a single hop.

Server Error (5xx)

Your server returned a 500-level error when Googlebot asked for the page. That might mean a crash, a timeout, or a firewall or CDN rule that blocks Googlebot.

How to fix it: check the host status section in Crawl Stats. Look at server logs for the affected URLs. Confirm your security settings aren’t slowing down or blocking Googlebot. Ongoing 5xx errors can also make Google slow down crawling of the whole site. So I treat this as a top priority.

Blocked Due to Unauthorized Request (401)

The server asked Googlebot to log in. Googlebot never logs in, so it can’t see the page.

Should you act? Only if the page should be public. Staging sites and member areas belong behind a login. If a public page shows up here, remove the login requirement for it.

Blocked Due to Access Forbidden (403)

The server refused access with a 403. Google notes this is an odd response for Googlebot, because it never sends login details. In practice, this often comes from a firewall, bot protection or hosting rule that wrongly treats Googlebot as a bad bot.

How to fix it: allow access for signed-out visitors. Or allow verified Googlebot requests in your firewall or CDN settings.

URL Blocked Due to Other 4xx Issue

This is a catch-all for other 4xx responses. Inspect a sample URL to see the exact status code. Then decide if it’s on purpose.

Warnings: Indexed Pages That Still Need a Look

These appear in the separate table below the main one. The pages are indexed, but something is off.

Indexed, Though Blocked by robots.txt

Google indexed the URL without crawling it, usually because other pages link to it. It can appear in results, but often with no useful snippet, because Google can’t read the content.

How to fix it: decide what you want. If the page should be in search, remove the robots.txt block so Google can crawl it properly. If it shouldn’t be in search, remove the block and add noindex. Leaving it blocked doesn’t remove it.

Page Indexed Without Content

Google indexed the URL but couldn’t read its content. Causes include a file format Google doesn’t support, content Google can’t render, or cloaking (showing Google different content from users). Inspect the URL and check the rendered screenshot in Test live URL.

Which Statuses to Ignore and Which to Fix

Use this as a quick sorting guide. “Depends” means check if the affected URLs are pages you want in search.

How to Diagnose a URL With URL Inspection

The page indexing report tells you which group a URL is in. URL Inspection tells you why that one URL is there. Paste any URL into the search bar at the top of Search Console to inspect it. To check many URLs at once, the URL Inspection API can do it in bulk.

The default view shows Google’s indexed data, not the live page. Look at these fields:

• Discovery: which sitemaps and referring pages led Google to the URL.
• Last crawl and crawl allowed: when Google last fetched it, and if robots.txt allowed it.
• Indexing allowed: if a noindex was found.
• User-declared and Google-selected canonical: this is where duplicate issues become clear.

Then click Test live URL. This fetches the page as it is now. You can confirm a noindex has gone, a redirect works or a block has been lifted. Note that the live test doesn’t check canonical choice or quality. So a pass doesn’t guarantee indexing.

If the live test looks good, Request indexing puts the URL in Google’s crawl queue. There’s a daily limit per property, so I save it for important pages. For many URLs, an updated sitemap is the better route.

How Validate Fix Works

Once you’ve fixed every case of an issue, open that reason in the report and click Validate fix. Search Console then rechecks the affected URLs.

A few things to know:

• Google first checks a small sample of pages. If the problem still exists there, validation stops early.
• Validation usually takes up to about two weeks, and sometimes much longer. Don’t click the button again while it’s running.
• The status moves through stages such as Started, Looking good, and then Passed or Failed. A single URL that still has the issue can cause a Failed result.
• If it fails, fix the remaining URLs and start a new validation. Only pending and failed URLs are rechecked.
• Validating while filtered to a sitemap of your key pages can finish faster.

Validate Fix only makes sense for issues where the source is your website. There’s little point validating “Crawled – currently not indexed” or “Discovered – currently not indexed” unless you’ve made big changes. Those reflect Google’s choices, not a clear error.

An issue stays in the report until 90 days after its last case disappears. So a row that hangs around doesn’t always mean the fix failed.

A Practical Routine for the Page Indexing Report

Here is the order I work through the report on any site:

1. Switch the filter to submitted pages. Start with URLs you told Google matter.
2. Sort reasons by source. Handle Website issues first: server errors, 401s, 403s, soft 404s, redirect errors, and noindex or robots.txt blocks you didn’t intend.
3. Open each reason and scan the examples. Look for patterns in the URLs, such as one folder, one template or one parameter.
4. Inspect two or three sample URLs. Use Test live URL to confirm the cause, and to check your fix once it’s live.
5. Fix at the template or rule level. One plugin setting or one robots.txt line often explains thousands of URLs.
6. Click Validate fix and leave it to run.
7. Review the Google-sourced statuses last. Improve content and internal links for important pages stuck under crawled or discovered.

For the full list of definitions, Google’s own Page indexing report help page is the one I keep bookmarked.

Conclusion

The page indexing report is not a to-do list where every row is an error. Most not-indexed URLs are redirects, duplicates, deleted pages or pages you left out on purpose. Your job is to find the important pages that are left out by mistake and fix the cause.

Filter to submitted pages and fix the issues your website caused first. Confirm each fix with URL Inspection, then run Validate Fix. If “Discovered – currently not indexed” keeps growing on a large site, your next step is to read up on crawl budget. Then trim the low-value URLs competing for Googlebot’s attention.