The Page indexing report: every status, what needs action and how to validate fixes

What the Page indexing report shows

Open it in Search Console under Indexing → Pages. It is a report about groups of URLs, not about one page. It answers three questions: how many of your pages are indexed, why the others are not, and whether that changed after last week's release.

The summary page has four parts:

• The chart with two totals: Indexed and Not indexed, and their history over time.
• Why pages aren't indexed: one row per reason, with the number of affected URLs, a trend line, the Source and the Validation state.
• Improve page experience: issues that did not stop indexing but are worth fixing. The two warnings described later in this lesson appear here.
• View data about indexed pages: the history of your indexed count and an example list of indexed URLs.

Click a row to open its details page: a chart for that reason alone and a table of example URLs. Each example row lets you open the URL, copy it or send it straight to URL Inspection. The details page also holds the Validate fix button.

Three limits to keep in mind

• Examples are a sample. The example table stops at 1,000 rows and does not promise to list every URL with that reason, even when the count is lower. Use it to find patterns, not as a complete inventory.
• You cannot look up one URL. There is no search box for a specific address in this report. For a single page you use URL Inspection.
• The data trails the live site. Each URL is shown as Google saw it at its last crawl. If you fixed a page yesterday and Google has not recrawled it, the old status stays. Always check the crawl date before you decide a fix did not work.

The Source column

Each reason is attributed either to Website or to Google systems. Website means something on your side caused it: a status code, a robots.txt rule, a noindex, a redirect. Google systems means the decision was Google's, such as choosing not to index a crawled page. You fix Website issues directly; with Google systems issues you can only change the conditions that led to the decision.

What Google officially says

Google also says not to expect 100% coverage: only the canonical pages should be indexed. New content “can take a few days” to be indexed. And for small sites, “If your site has fewer than 500 pages, you probably don't need to use this report.” There, a site: search and URL Inspection on your key pages usually tell you enough.

Reading the chart and the sitemap filter

“Ideally you should see a gradually increasing count of indexed pages as your site grows.” What you look for are breaks in that line, and above all a fall in indexed pages that mirrors a rise in not indexed pages.

Google's own troubleshooting matches this picture: “If you see a drop in total indexed pages without a corresponding increase in errors, you might be blocking access to your existing pages via robots.txt, 'noindex' or a required login.” Look at the sparkline next to each reason to find the one whose rise lines up with the drop. Sudden error spikes have a similar story: they “might be caused by a change in your template that introduces a new error”, or by a new sitemap full of blocked URLs.

The sitemap filter

The dropdown above the chart changes which URLs the whole report counts:

• All known pages (default): every URL Google knows, from sitemaps, links or anywhere else.
• All submitted pages: only URLs listed in a sitemap you submitted in the Sitemaps report or referenced in robots.txt.
• Unsubmitted pages only: URLs Google found by other means and that are not in any submitted sitemap.
• A specific sitemap: only the URLs in that one sitemap or sitemap index.

A URL counts as submitted even if Google also found it through links. In practice, All submitted pages is the most useful view. Your sitemap is your list of pages you want indexed, so a submitted URL that is not indexed is a real contradiction. The unsubmitted view is mostly noise: parameter URLs, old addresses, links from other sites. If you split your sitemap by page type (products, categories, articles), the filter shows you the indexing rate of each type separately. The lesson XML sitemaps covers how to build that split.

Every not-indexed reason, explained

These are the reasons Google lists for URLs that are not indexed, in Google's order. For each one: what it means, whether you need to act, and which lesson in this course goes deeper. The one question behind every entry is the same: do you want this URL in search? If you do not, a not-indexed status is the result you wanted.

Server error (5xx)

“Your server returned a 500-level error when the page was requested.” Googlebot could not get the page because the server failed, timed out or was busy. Action: yes, if it is more than a one-off. Check the host status in the Crawl Stats report, look for firewalls or bot protection that block Googlebot, and fix slow or overloaded pages. Server errors can be transient, so a live test may pass even though Google's crawl failed. More in Status codes, soft 404, 410.

Redirect error

Google could not follow the redirect: the chain was too long, it looped, the URL grew past the maximum length, or the chain contained a bad or empty URL. Action: yes. Point every old URL straight at its final destination in one hop. More in Redirects and site migrations.

URL blocked by robots.txt

A Disallow rule stops Googlebot from fetching the page. Action: only if you want the page indexed, in which case remove the rule. If you want it out of search, robots.txt is the wrong tool: “To ensure that a page is not indexed by Google, remove the robots.txt block and use a 'noindex' directive.” For URLs you block on purpose, such as cart or internal search pages, this status is fine. More in robots.txt and AI crawlers.

URL marked ‘noindex’

Google crawled the page and found a noindex in a robots meta tag or an X-Robots-Tag header. Google's comment is short: “If you do not want this page indexed, congratulations!” Action: only if the page should be indexed. Then find where the noindex comes from (template, CMS setting, plugin, server header), remove it, confirm with a live test that Indexing allowed? now says yes, and request indexing. More in Meta robots and X-Robots-Tag.

Soft 404

The page shows a not-found message or almost nothing useful, but returns 200 OK. Typical cases are empty categories, “no results” pages and deleted products that show a friendly error. Action: yes. If the page is really gone, return 404 or 410. If it should exist, give it real content. If it moved, redirect it. URL Inspection's live test has a screenshot that shows how Google rendered the page, which helps when the content is loaded by JavaScript. More in Status codes, soft 404, 410.

Blocked due to unauthorized request (401)

“The page was blocked to Googlebot by a request for authorization (401 response).” Action: only if the page should be public. Staging sites and account areas are supposed to return 401. If a public page does it, remove the login requirement. Opening the URL in a private browser window shows you what Googlebot gets.

Not found (404)

The URL returned 404. Google found it through a link or because the page existed before. Google says “404 responses are not necessarily a problem, if the page has been removed without any replacement.” Action: only for 404s you cause yourself. Google's advice: “In general, we recommend fixing only 404 errors that you link to yourself or list in a sitemap.” If the content moved, use a 301 to the new address. Googlebot will keep trying a 404 URL for a while, less and less often, and the report shows only URLs that returned 404 in the past month. More in Status codes, soft 404, 410.

Blocked due to access forbidden (403)

The server answered 403. Google points out that “Googlebot never provides credentials, so your server is returning this error incorrectly.” Action: yes, when the page is meant to be public. The usual cause is a firewall, CDN or bot-protection rule that blocks Googlebot. Allow verified Googlebot requests instead of blocking them.

URL blocked due to other 4xx issue

“The server encountered a 4xx error not covered by any other issue type described here.” This bucket collects the remaining client-error codes, such as 400 (bad request) or 405 (method not allowed). Note that 429 (too many requests) is handled differently: Google treats it as a sign of server overload, like a 5xx. Action: it depends on the code. A code you send on purpose for a page that should stay out of search is fine. A 429 on pages you want indexed means your server is rate-limiting Googlebot. Use URL Inspection to see which code the URL returns. More in Status codes, soft 404, 410.

Crawled – currently not indexed

Google fetched the page and decided not to index it, at least for now. “It may or may not be indexed in the future; no need to resubmit this URL for crawling.” Action: only for pages that matter. The cause is usually the page itself: thin content, near-duplicates of indexed pages, little added value. Resubmitting alone does not change that; improving the page and its internal links does. This status cannot be checked in the live test. Full diagnosis in Crawled vs Discovered – currently not indexed.

Discovered – currently not indexed

Google knows the URL but has not crawled it yet, so the last crawl date is empty. Google explains: “Typically, Google wanted to crawl the URL but this was expected to overload the site; therefore Google rescheduled the crawl.” Action: only for important pages, and only if the count keeps growing. Look at server speed, the number of low-value URLs competing for crawling, and how well the pages are linked internally. Full diagnosis in Crawled vs Discovered – currently not indexed.

Alternate page with proper canonical tag

The URL is an alternate of another page, for example a mobile, AMP or desktop version, and it correctly points to its canonical. Google's verdict: “This page correctly points to the canonical page, which is indexed, so there is nothing you need to do.” Action: no. Parameter URLs and tracking variants with a canonical often land here too. One note from Google: “Alternate language pages are not detected by Search Console.” More in Canonical tags.

Duplicate without user-selected canonical

Google sees the URL as a duplicate of another page, the URL declares no canonical, and Google picked the canonical itself. “This is not an error, but is working as intended, because Google does not serve duplicate pages.” Action: check, then decide. Inspect the URL to see which page Google chose. If that choice is right, you can leave it, or add a canonical so the choice is explicit. If the choice is wrong, declare the canonical you want. If the page is not really a duplicate, make its content clearly different. More in Canonical tags.

Duplicate, Google chose different canonical than user

“This page is marked as canonical for a set of pages, but Google thinks another URL makes a better canonical.” In other words, you declared a canonical and Google overruled it. Action: check. In URL Inspection, compare User-declared canonical with Google-selected canonical, then open both pages. Usually other signals disagree with your tag: internal links, redirects or sitemap entries pointing elsewhere. And keep in mind that “A duplicate page must be similar to the canonical.” If your declared canonical is a different page, Google will not use it. More in Canonical tags.

Page with redirect

“This is a non-canonical URL that redirects to another page.” Only the redirect target can be indexed, so after a migration or an HTTP to HTTPS move this list fills up with old addresses. That is expected. Action: no for the redirecting URL itself. Check two things instead: that the targets are indexed, and that your own internal links and sitemap use the final URLs, not the redirecting ones. Google adds that “A canonical URL with a redirect can be indexed.” More in Redirects and site migrations.

You may also meet two older status names in Google's URL Inspection help: Blocked by page removal tool (check the Removals page for it) and Duplicate, submitted URL not selected as canonical. Treat the second one like the duplicate statuses above.

The two warnings

Warnings sit in the Improve page experience table, not in the not-indexed table. Google says these issues “don't prevent a page from being indexed, but they do reduce Google's ability to understand and index your pages.” Both deserve attention.

Which statuses need action

Do not work through the table from top to bottom. Start from your intent for each group of URLs and let the status confirm or contradict it. Google's own priority rule is to fix issues with a Website source that are in validation state “failed” or “not started” first.

One exception to the first branch: Indexed, though blocked by robots.txt is a case where a URL you wanted out of search got in anyway. Swap the block for a noindex.

Two habits make this faster. First, work with the All submitted pages filter, because every not-indexed URL there contradicts your own sitemap. Second, fix templates, not URLs. Statuses arrive in groups. Export the examples, sort them by folder, parameter or page type, and you will usually find one shared cause, such as every /tag/ page, every ?sort= variant or every product without stock.

URL Inspection: indexed version vs live test

URL Inspection is the tool for one URL. Paste a full URL into the search bar at the top of Search Console, or click the inspect icon next to any example URL in the report. The URL must belong to the property you have open.

The indexed version

The first screen shows what Google has stored. “This is not a live test. The results shown are from most recently indexed version of a page, not the live version on the web.” The verdict at the top is URL is on Google, URL is on Google, but has issues, URL is not on Google or, for AMP, URL is an alternate version. Even the best verdict has a limit: “"URL is on Google" doesn't actually guarantee that your page will appear in Search results.”

Expand Page indexing to see the details:

• Discovery: the sitemaps that list the URL and a referring page Google may have used to find it.
• Crawl: last crawl date, crawler type (smartphone or desktop), Crawl allowed? (robots.txt) and Page fetch (did the server deliver the page).
• Indexing allowed?: whether a noindex blocks the page. A trap here: “If your page is blocked by robots.txt (see Crawl allowed?), then Indexing allowed? will always be "Yes" because Google can't see and respect any noindex directives.”
• User-declared canonical and Google-selected canonical: your choice and Google's. The canonical can only be read from the indexed data. The live test, in Google's words, “cannot predict whether or not the tested version will be considered canonical.”

If the URL redirects, the indexed view describes the URL you typed, not the target. Use the Inspect button in the Indexing section to jump to the canonical.

The live test

Test live URL fetches the page now, as Google would. Use it after a fix to check that the fix is visible to Google before you request indexing or validation. It shows Crawl allowed?, Page fetch, Indexing allowed? and the user-declared canonical. View tested page opens the rendered HTML, the HTTP response headers, JavaScript console messages, the loaded resources and a screenshot. “A screenshot is available only in a live test with a successful test result.”

Know what the live test cannot do. “The live URL test only confirms if Google-InspectionTool can access your page for indexing.” It does not check duplicates or canonical selection, sitemaps, quality, manual actions or removals. Statuses such as Crawled or Discovered – currently not indexed, the duplicate and alternate statuses and Page indexed without content cannot be confirmed in a live test. A green live test on a page reported as a duplicate means only that Google can fetch it. The live test also follows redirects silently and tests the final URL without telling you.

Request indexing

On the URL Inspection result, Request indexing puts the URL in Google's crawl queue after a quick check for obvious indexing errors. You cannot request indexing for a URL that the live test considers non-indexable.

• “Indexing typically takes only a day or so, but can take much longer in some cases.”
• “Submitting a request does not guarantee that the page will appear in the Google Index.”
• “There is a daily limit to how many index requests you can submit.”

Use it for a handful of important pages: a new key page, a page where you just removed a noindex, a page with a fixed server error. Requesting the same URL again and again does not speed anything up. For larger batches, Google is clear: “To request indexing of many new or updated pages, your best choice is to submit a sitemap, with the updated pages marked by <lastmod>.”

Validating a fix

Validation tells Google you fixed every instance of one issue and asks it to recheck those URLs. You get an email when it finishes, and a log that shows the status of each URL. You do not have to validate: Google updates the counts whenever it recrawls affected pages anyway. Validation simply makes the recheck targeted and visible.

1. Fix every instance. “If you missed a fix, validation will stop when Google finds a single remaining instance of that issue.” Test a few URLs with the live test first.
2. Open the issue's details page and click Validate fix. Click it once only.
3. Wait. “Validation typically takes up to about two weeks, but in some cases can take much longer, so please be patient.”
4. If it fails, open See details, find the URL that still has the issue, fix it and click Start new validation.

Issue states

URL states inside a validation

Each URL in the validation log has its own state: Pending (queued, the issue existed when last checked), Passed (rechecked and fixed), Failed (rechecked and still there) and Other (Google could not reach the URL, which counts the same as Passed). An issue also counts as fixed for a URL that has become unavailable: removed, marked noindex or behind a login. The same URL can be Passed for one issue and Pending for another.

Rules worth knowing

• Only affected URLs are rechecked. “Only URLs with known instances of this issue are queued for recrawling, not the whole site.”
• Do not restart a running validation. “Wait for a validation cycle to complete before requesting another cycle, even if you have fixed some issues during the current cycle.”
• A restart skips what already passed. “URLs marked Passed or Other are not rechecked.”
• Validate by sitemap to go faster. Filter the report to a sitemap with only your most important URLs before you click Validate fix. A smaller set can finish sooner. The validation then covers only the URLs in that sitemap.
• Issues have a lifetime. An issue disappears from the table 90 days after its last instance was gone. If it comes back within that window, it reopens with the original first-detected date; after that, it is recorded as a new issue.
• Passed does not change the label. A fixed issue keeps its type in the table; only the count drops to 0 and the row moves to the bottom.

A weekly routine

The report changes slowly, so once a week is enough for most sites. Twenty minutes, in this order:

1. Check the chart with the filter set to All submitted pages. Is indexed flat or rising? Any drop that mirrors a rise in not indexed?
2. Scan the sparklines in “Why pages aren't indexed”. Note any reason that is new or growing.
3. Open each changed reason, export the examples and group them by folder, parameter or template.
4. Ask the intent question for each group: should these URLs be in search? If not, make sure they are not in the sitemap or linked prominently, and move on.
5. Inspect two or three examples from each group that should be indexed: crawl date, Crawl allowed?, Indexing allowed?, both canonicals.
6. Fix the cause in the template or configuration, then confirm with a live test.
7. Request indexing for a few key URLs, and click Validate fix for the issue.
8. Check running validations and the two warnings in Improve page experience.
9. Write it down. Keep a change log with the date, the change and the issue. When the chart moves weeks later, you will know why.

After a release, a migration or a CMS update, do steps 1 to 3 within a few days, not at the next weekly check. Template mistakes spread to thousands of URLs at once.

Common mistakes

• ✕Trying to reach zero not-indexed URLsRedirects, duplicates, noindex pages and deleted URLs belong there. Only the canonical versions of important pages need to be indexed.
• ✕Reading the examples as a full listThe table is a sample of up to 1,000 URLs. Use a crawl of your site for the full picture.
• ✕Judging a fix before the recrawlCompare the crawl date with the date of your change before you conclude anything.
• ✕Using robots.txt to remove pagesBlocked URLs can still be indexed from links, and Google never sees their noindex.
• ✕Trusting a green live test on a duplicateThe live test does not check canonical selection, quality or the Crawled and Discovered statuses.
• ✕Clicking Validate fix again and againRestarting does not speed it up. Wait for the cycle to finish.
• ✕Validating before every instance is fixedOne remaining URL is enough to fail the whole validation.
• ✕Mass Request indexingThere is a daily limit, and a request is not a guarantee. Use a sitemap with accurate lastmod for many URLs.
• ✕Keeping non-indexable URLs in the sitemapRedirects, 404s and noindex pages in the sitemap make the submitted view useless.

FAQ

Sources

• Search Console Help — Page indexing report
• Search Console Help — URL Inspection tool

Quotes checked against the official pages on 30 October 2026.