The Search Console Page Indexing Report: What Each Status Means

Do you need this report?

Google's Page indexing report help page is blunt about it: "If your site has fewer than 500 pages, you probably don't need to use this report." For a small business site, Google suggests searching with the site: operator instead (for example site:example.com, or site: followed by the exact address of a page) and only turning to the report if those searches come back empty. It also warns: "If you don't understand indexing, this report will confuse or frustrate you–trust us."

The report is still worth a look after a launch, a redesign or a move to a new domain, or when a page that matters does not show up. For one specific page, though, Google points you elsewhere: "This report isn't used to investigate the index status of specific pages." Use the URL Inspection tool for that, covered below. If you have not set up Search Console yet, start with our Search Console guide for business owners.

How to read it

The summary page shows a chart of indexed and not indexed pages, a Why pages aren't indexed table and an Improve page experience table for issues that did not stop indexing. Each URL is either Indexed or Not indexed. Two columns in the reasons table decide what you do next:

• Source. It "shows whether the source of the issue is Google or the website." Google adds that, in general, you can fix only issues whose source is Website.
• Validation. Whether you have asked Google to check a fix. Google says to prioritise issues whose validation state is failed or not started and whose source is Website.

Three things to keep in mind before you worry about any number:

• "Don't expect every URL on your site to be indexed. Some URLs might be duplicates or might not contain meaningful information."
• "Non-indexed URLs can be fine." Google lists good reasons: "an expected robots.txt rule on your site, a noindex tag on the page, a duplicate URL, or a 404 for a page that you've removed and have no replacement for."
• Example lists in the report are capped at 1,000 rows and do not necessarily show every affected URL.

The dropdown above the chart filters by sitemap: all known pages, all submitted pages, unsubmitted pages only, or one specific sitemap. Filtering to your sitemap is a quick way to see whether the pages you actually care about are indexed. Our guide to robots.txt and XML sitemaps covers what belongs in that sitemap.

Crawled or Discovered: currently not indexed

These two statuses are easy to misread, and neither is an error in itself.

Crawled - currently not indexed. Google's description: "The page was crawled by Google but not indexed. Google doesn't index all pages across the web, so this is a common message for many sites and doesn't necessarily indicate an issue that needs attention." For important pages, Google says to use the URL Inspection tool to check whether something on your site is getting in the way, such as blocking its crawlers. There is no setting that forces indexing. Two things worth checking: whether the page is substantially different from your other pages (Google's help asks the same of pages marked as duplicates), and whether it is linked from pages Google already indexes. Our guide to internal links covers how to give a page a clear path in.

Discovered - currently not indexed. "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; therefore Google rescheduled the crawl. This is why the last crawl date is empty on the report." On a small site this usually clears with time. If it lingers on many pages, check that the server responds quickly and reliably; our guide to website speed and hosting covers the server side.

You will read a lot about crawl budget in connection with these statuses. Google's crawl budget guide is written for large sites ("1 million+ unique pages" with content that changes about weekly, or "10,000+ unique pages" with content that changes daily) and sites with many URLs stuck in Discovered. If your pages tend to be crawled the same day they are published, Google says "you don't need to read this guide."

Duplicates and canonicals

When several URLs show the same content, Google picks one to index, the canonical. Google's canonicalization overview defines it as "the process of selecting the representative – canonical – URL of a piece of content." Three statuses come from this process:

• Alternate page with proper canonical tag. The page points to the canonical, which is indexed, "so there is nothing you need to do."
• Duplicate without user-selected canonical. The page does not say which version is preferred, so "Google has chosen the other page as the canonical for this page, and so will not serve this page in Search." Google calls this "working as intended". If Google picked the wrong version, mark your preferred canonical; if the page is not really a duplicate, make its content differ substantially.
• Duplicate, Google chose different canonical than user. You marked this page as canonical but "Google thinks another URL makes a better canonical." Inspect the URL and compare the user-declared and Google-selected canonical. Google adds a rule worth remembering: "A duplicate page must be similar to the canonical."

To steer the choice, Google's guide on how to specify a canonical URL ranks the signals: redirects are "A strong signal that the target of the redirect should become canonical", rel="canonical" link annotations are "A strong signal that the specified URL should become canonical", and sitemap inclusion is "A weak signal". Use them together and keep them consistent: the same preferred URL in the canonical tag, your internal links and your sitemap. Google's report help names filter and sort parameters (type=dress, color=green, sort=price) as a common source of large numbers of duplicates.

One limit to know: the live test in URL Inspection does not check this. Google says "duplicate or canonical conditions are not tested in the live test."

Blocked, noindex and redirects

These statuses usually mean the site is doing what it was told. Check that the instruction was intended.

• URL marked ‘noindex’. "If you do not want this page indexed, congratulations! If you do want this page to be indexed, you should remove the 'noindex' directive." The directive can sit in a meta tag or an HTTP header. After a launch, check that no noindex was carried over from a staging site.
• URL blocked by robots.txt. Google notes this "does not guarantee that the page won't be indexed through some other means." Google's noindex documentation explains why the two do not mix: for noindex to work, the page "must not be blocked by a robots.txt file", because a crawler that cannot fetch the page never sees the rule.
• Page with redirect. "This is a non-canonical URL that redirects to another page. As such, this URL will not be indexed." Old addresses that you redirected on purpose belong here; nothing to fix. Our guide to 404 pages and redirects covers setting them up.

Errors you can fix

• Server error (5xx). "Your server returned a 500-level error when the page was requested." Google suggests checking the host status in the Crawl Stats report and using URL Inspection to try to reproduce it, noting that "server errors can be transient". A firewall or DoS protection that blocks Googlebot can also cause this.
• Redirect error. A chain that was too long, a redirect URL that exceeded the maximum length, or a bad or empty URL in the chain.
• Soft 404. The page shows a not-found message but does not return a 404 status code. Return a real 404 for missing pages, or add content so a real page is not mistaken for one.
• Not found (404). Google's advice: "In general, we recommend fixing only 404 errors that you link to yourself or list in a sitemap. If a page has been moved, you should return a 3XX redirect to the new page." The report only shows URLs that returned 404 in the past month.
• Blocked due to unauthorized request (401) and access forbidden (403). A login or permission rule stops Googlebot. Google points out that "Googlebot never provides credentials", so a 403 on a public page is a server mistake.

If the number of indexed pages drops without a matching rise in errors, Google says you "might be blocking access to your existing pages via robots.txt, 'noindex' or a required login." Look for a spike in non-indexed URLs on the same date.

Indexed, but with a warning

Indexed, though blocked by robots.txt means Google indexed the page from links pointing to it without fetching it, so any snippet "will probably be very limited". If you want it out of Search, "robots.txt is not the correct mechanism to avoid being indexed"; remove the block and use noindex. Page indexed without content means Google "could not read the content", for example because the page is cloaked or in a format Google cannot index.

Validate fix: what happens next

After you fix every instance of an issue, open it and click Validate fix. Google first checks a few pages; if the problem is still there, validation stops. Otherwise it works through the known affected URLs ("Only URLs with known instances of this issue are queued for recrawling, not the whole site") and emails you when it passes or fails. Google says: "Validation typically takes up to about two weeks, but in some cases can take much longer". Do not click Validate fix again until the current run has finished.

You do not have to validate at all: "Google updates your instance count whenever it crawls a page with known issues, whether or not you explicitly requested fix validation." It also makes little sense for statuses you caused on purpose, such as pages you block in robots.txt.

For a single page you changed, Google's URL Inspection tool shows the indexed version, lets you test the live URL and has a Request indexing button. Google's recrawl guide notes "there's a quota for submitting individual URLs and requesting a recrawl" and that asking "multiple times for the same URL won't get it crawled any faster." For many changed pages, submit a sitemap with updated <lastmod> dates instead.

A routine for a business site

1. After launch or a redesign, inspect the home page and your main service pages and confirm they are indexed.
2. Once a month, open the report filtered to your submitted sitemap. Every page in it should be indexed or have a reason you agree with.
3. Read the reasons with source "Website" first. Fix noindex, robots.txt rules or redirects that were not intended.
4. For Crawled or Discovered pages that matter, improve the page and link to it from related pages, then request indexing once.
5. Make your canonical tags, internal links and sitemap agree on one URL per page.
6. Validate fixes for real errors and wait for the email before you start another run.

Frequently asked questions

Is "Crawled - currently not indexed" a penalty?

No. Google describes it as a common message for many sites that does not necessarily need attention, because Google does not index every page it crawls. For pages that matter, check them with URL Inspection, make sure they are not near-copies of other pages and link to them from related pages.

How long does Discovered - currently not indexed last?

Google gives no fixed time. It says the crawl was rescheduled, typically because crawling was expected to overload the site. On a small site it usually clears as Google crawls; if it lasts, check that your server responds quickly and reliably.

Should every page on my site be indexed?

No. Google says not to expect every URL to be indexed: duplicates, redirected URLs, pages with noindex and removed pages should stay out. What matters is that your key pages, in their canonical version, are indexed.

Why does a page I fixed still show an error?

The report shows what Google found at the last crawl. Check the crawl date in URL Inspection; if your fix came later, test the live URL and request indexing, or use Validate fix for the whole issue.

Do I need to click Validate fix?

No. Google updates the counts whenever it recrawls affected pages. Validating gives you progress tracking and an email when Google confirms the fix, which is useful after fixing real errors.

Want a site built so the right pages get indexed, with clean URLs, consistent canonicals and an XML sitemap from day one? See our website development service and all our services, or email [email protected].