How to Fix Page Indexing Errors in Google Search Console: Every Status Explained

What the Page indexing report is really telling you

The Page indexing report counts which of your pages Google has indexed and lists the reasons the others were left out ^[1]. It covers the whole property, not one page, and each reason opens a list of example URLs. To find it, open Search Console, choose the property, then Indexing, then Pages. The chart shows indexed and not-indexed counts over time, and the table below it lists the reasons. There is no search or filter by URL, so for a single page you use URL Inspection instead. Google says that if your site has fewer than 500 pages, you probably do not need the report at all.

Not indexed is not automatically bad. Google says it will almost certainly not index every page, and what matters is that the canonical, non-duplicate versions of your important pages are in. Duplicates, redirects and noindex pages belong in the not-indexed bucket. Larger sites and stores should check the report monthly. Before you read a single reason, look at the chart. Google wants a gradually increasing count of indexed pages as the site grows, and a sudden drop or spike tells you more than any row. Each bar shows the total as of that date, not the pages indexed that day.

The Source column decides what you can fix

Every reason carries a source, Website or Google, and in general you can fix only the issues with the Website source. Source Google means Google probably decided against indexing for a reason of its own. Website rows are things like 404s, redirects and noindex pages. Google rows, such as crawled or discovered but not indexed, reflect Google's choices, which you influence only indirectly through quality, links and server speed. Start with the Website rows, and among them with the ones that touch your most important pages.

One loop fixes almost every status

The pattern is the same for every reason. Open it, read the examples, inspect two or three URLs, find the shared cause, fix it in the template or on the server, then click Validate fix. Most indexing problems come from templates, so one fix usually clears hundreds of URLs. That is why sampling three examples beats reading a list of a thousand.

What happens after you click Validate fix

Search Console immediately checks a few pages. If the issue is still there, validation ends at once. Otherwise only the URLs with known instances of the issue are queued for recrawling, not the whole site, and a single remaining instance stops the process. Google emails you when it confirms the fix on all URLs or finds instances left. An issue moves through Not started, Started, Looking good, Passed, N/A or Failed. N/A is good news. It means Google found the issue fixed without a request.

Be patient with the clock

In Google's words, "Validation typically takes up to about two weeks, but in some cases can take much longer" ^[1]. Do not click Validate fix again until the run has succeeded or failed. A second click only restarts the wait. Google's own shortcut is to submit a sitemap with only your most important pages and filter the report by it before validating, so the request completes faster.

Server-side errors: 5xx, redirects and DNS

Server error (5xx)

A server error means Googlebot could not access the URL, the request timed out, or the site was busy. Check host status in Crawl Stats and your server logs for the dates shown. Googlebot retries later. One bad night rarely matters. A pattern across several weeks does, because Google crawls less and failing pages can drop out of the index. Firewalls and DoS protection often block Googlebot, which makes more requests than a human user, and slow dynamic pages time out. Allowlist verified Googlebot traffic and speed up heavy templates before validating.

Redirect and DNS errors

Redirect errors cover chains that are too long, loops, URLs longer than the limit and empty URLs in a chain. They usually come from stacked migration rules. Point every old URL straight to its final destination in one hop, update internal links and sitemaps, and remove rules that loop back. Each extra hop is also a separate crawl request ^[2]. A DNS error means Googlebot could not reach your DNS server at all; for recurring ones, talk to your DNS provider. In Crawl Stats, DNS failures on more than 5% of requests in a day count as an issue. Reliable DNS is cheap insurance.

Access and status codes: 401, 403, 404 and soft 404

Login walls and forbidden pages

A 401 means Googlebot hit a login or authorization request, which you can confirm by opening the page in incognito mode. Remove the authorization from public pages, or keep private pages out of sitemaps and links. Never let Googlebot in by user agent alone. User agents can be spoofed. A 403 is stranger, because Googlebot never provides credentials, so the server is returning it incorrectly. Security plugins, country blocks and bot filters are the usual causes; allow verified Googlebot requests and retest live. A 429 usually means rate limiting, often on a CDN, and Google warns not to return 503 or 429 for more than two or three days.

Not found (404), and when to leave it

A 404 is not necessarily a problem when a page has been removed without a replacement. The report shows only URLs with 404s from the past month, and Google treats 410 the same as 404. For an online store this bucket fills naturally as products are discontinued. Several hundred 404s on a catalog of thousands is normal, while a sudden jump of thousands after a release usually means a broken template or a changed URL pattern. Google itself says most 404 errors are not worth fixing, because they do not harm indexing or ranking. You cannot tell Googlebot to forget a URL forever, but it crawls it less often over time.

The ones worth your time are narrow. Google recommends "fixing only 404 errors that you link to yourself or list in a sitemap" ^[3]. If the page moved, use a 301 redirect. Do not redirect every 404 to the home page, which Google explicitly advises against, and do not expect a URL removal request to clear a 404 from the report. It will not.

Soft 404

A soft 404 is a page that returns a success code but looks like an error or an empty page. Thin category pages with no products often land here. Run a live inspection and click View tested page to see a screenshot of how Google renders it. If the page is truly empty, return 404 or 410, as Google recommends for pages that do not exist. If it has content Google missed, fix the rendering. Empty search and filter pages should not be indexable at all.

Pages you blocked on purpose, or by accident

Blocked by robots.txt

Here Google could not crawl the URL because robots.txt forbids it. That does not reliably keep it out of Google, since there is a very small chance the page is indexed anyway. If the page should rank, remove the rule; a robots.txt validator shows which one blocks it. If the page should stay hidden, robots.txt is the wrong tool. The related status, Indexed though blocked by robots.txt, shows why: Google indexed the page from links without crawling it, so its result carries no useful description.

Excluded by noindex tag

Google found a noindex directive and respected it. That is correct for thank-you pages, internal search results and admin screens, and a problem when a template adds noindex to products or posts by mistake. A useful check is to filter this reason by your main sitemap. Any URL that appears both in the sitemap and under noindex is sending Google two opposite instructions, and one of them is almost certainly a mistake. Remove the noindex tag or X-Robots-Tag header from the template, then request indexing. Check plugins and staging settings as well. A staging switch left on in production is the classic cause.

Keeping a page out the right way

To hide a page, use noindex or require a login. A robots.txt rule is not recommended for this, because it actually prevents Google from seeing the noindex at all. Blocking and noindex together never works. Pick one signal, not two. For urgent cases, the Removals tool hides a URL for about six months, which buys time to make the fix permanent.

Google's own choices: crawled or discovered, not indexed

Crawled, currently not indexed

Google crawled the page and chose not to index it. It may or may not be indexed later. This is a quality and value decision, not a technical error, so resubmitting changes nothing. Thin, repetitive and duplicate pages often end up here. A site that adds hundreds of near-identical location or tag pages will see this bucket grow faster than its indexed count.

The fix is to improve or merge. Add original content to pages that deserve to rank, merge near-duplicates, noindex pages that exist only for navigation, and strengthen internal links to the pages you care about. Pruning or consolidating often helps more than writing new pages when the indexed count stalls. Then wait for the next crawl. Validation is rarely useful here.

Discovered, currently not indexed

Here Google knows the URL but has not crawled it, typically because the crawl was expected to overload the site and was rescheduled. The last crawl date is empty, and large counts point to server limits or weak signals. Speed up the server so Google can crawl more, remove low-value URLs from sitemaps so crawl effort goes to important pages, and link important pages from strong ones. Sites that use URL parameters rather than URL paths are harder to crawl. Clean URLs help.

Duplicates, canonicals and redirects

Several statuses are housekeeping rather than trouble. Alternate page with proper canonical tag means the page correctly points to an indexed canonical, so there is nothing to do; these are usually mobile, AMP or parameter versions, and a large count is normal. Page with redirect is expected after migrations and http to https moves, because only the redirect target is indexed. Remove redirecting URLs from sitemaps and internal links. After a migration this bucket can hold thousands of URLs for months, but if the targets themselves are missing from the indexed list, inspect each one, because the migration lost signals somewhere.

Duplicate without user-selected canonical

Google found duplicates, none declares a canonical, and Google picked one. If it picked the right one, do nothing; check its choice in URL Inspection. Parameter URLs from filters and tracking are the usual cause. Stores suffer most here, because a category with 10 colors, 8 sizes and 4 sort orders can generate 320 URLs for one listing. The fix is a rel=canonical tag on every variant pointing to the preferred URL, clean URLs in internal links and sitemaps, and noindex on filter combinations. If two pages truly differ, make sure the content differs substantially.

Duplicate, Google chose a different canonical

You declared a canonical, but Google thinks another URL is better. Compare the two in URL Inspection. Usually your choice is weaker in links, redirects somewhere, or is not similar enough to the page, and Google will never choose a canonical that is not similar to the current page. A frequent cause is a canonical pointing to the http version while the site runs on https, or to a URL that redirects. Make sure the target returns 200, is indexable, sits in the sitemap and receives internal links, and remove conflicting hreflang or redirect signals.

Reading the report like a specialist

The dropdown above the chart filters by All known pages, All submitted pages, Unsubmitted pages only, or one sitemap. Filtering by your main sitemap gives a far better health number than the site-wide total. If your sitemap lists 2,000 product pages and the filtered report shows 1,700 indexed, then 85% of the pages you care about are in Google. Example lists stop at 1,000 URLs, though the totals are complete. Need more? Split sitemaps by section. To brief a developer, the Share button sends a revocable link to the issue and its validation history.

For one URL, use URL Inspection, covered in our URL Inspection guide. It shows the indexed version, the Google-selected canonical and the last crawl ^[4]. The live test has limits, though. It does not test duplicate or canonical conditions, it cannot test the crawled or discovered statuses, and a green result does not promise indexing. If the report lacks a URL that inspection calls indexed, the page was probably indexed recently.

When the indexed count drops without new errors, pages may now be blocked by robots.txt, noindex or a login. Compare the drop date with your deploy log before blaming Google, because a template change can remove whole sections overnight. Error spikes have the same usual cause, or a sitemap listing blocked URLs. Google should email you when one occurs. Read that email the same day.

A monthly routine, and the mistakes to avoid

Google suggests checking monthly, or whenever you make large changes. Open the chart and note the indexed total, read the top Website-source reasons, inspect two examples of each, check validations in progress, and compare the sitemap-filtered count with last month. Fifteen minutes is enough for most sites. A store that publishes products daily is better served by a weekly look at the indexed count and the top three reasons. Logged monthly, those numbers become a trend line.

New sites need patience. It can take a week or so for Google to start crawling a new page or site, and a page must be linked from a known page or listed in a sitemap. Request indexing for the home page first, then let Google follow links. Keep requests for a few important new or changed pages, because there is a daily quota, and submit a sitemap when there are many. Our setup guide covers that groundwork. Finally, avoid the common mistakes. Each sends Google a mixed signal:

• Blocking a page in robots.txt and adding noindex at the same time.
• Redirecting every 404 to the home page.
• Requesting indexing for hundreds of thin pages.
• Clicking Validate fix again before the last run finished.
• Listing redirects and noindex pages in the sitemap.

The bottom line

Page indexing errors are mostly template problems, with a few of Google's quality decisions mixed in. Fix Website-source errors on your important pages first, validate once and wait, and leave Google's choices on duplicates and harmless 404s alone. The goal is not zero not-indexed pages. It is every important page indexed, and the sitemap filter is the number that tells you whether you are there.