Key takeaways

• Google Search Console errors show why Google couldn’t crawl or index a page. Check whether the affected page should appear in search results before deciding what to fix.
• Start with server and redirect errors, accidental noindex tags, and robots.txt blocks on important pages.
• Some “not indexed” statuses are expected, including redirects, alternate pages with a proper canonical tag, and pages you intentionally noindexed.
• Use the Page indexing report to find affected URLs, then inspect individual pages to diagnose the cause.
• After making a fix, test an affected URL and use Validate fix to ask Google to recheck the issue.

Google Search Console errors explain why Google couldn’t crawl or index a page. Some point to problems that keep important pages out of search results, while others are expected, such as redirects or pages marked noindex.

This guide shows you how to find the affected pages, prioritize the issues, and check your fixes.

What are Google Search Console errors?

Google Search Console errors are reports of problems that prevent Google from crawling or indexing a page. The Page indexing report lists affected URLs by reason, including server errors, redirect failures, and pages Google crawled but didn’t index. It also includes expected exclusions, so not every status needs fixing.

Previously called the Coverage report, it’s a useful starting point when important pages aren’t appearing in search. If you’d like help prioritizing issues on your site, start with our free ecommerce SEO audit.

How to find errors in the Page indexing report

Open Google Search Console, select your property, and go to Indexing → Pages. You’ll see a chart of indexed and not indexed pages, followed by a table titled “Why pages aren’t indexed.”

To investigate an issue:

1. Look for sudden increases in not indexed pages.
2. Check the Source column. “Website” points to site settings or responses, while “Google systems” reflects Google’s indexing decisions.
3. Click a reason to see example URLs affected by that status.
4. Enter an affected URL in URL Inspection to review its crawl details, indexing status, and Google-selected canonical.

You can also filter to “All submitted pages” to focus on URLs in your XML sitemap and prioritize pages you want appearing in search.

Here’s a quick reference to common indexing report statuses, their types, and when each needs attention:

Crawling errors: Why Google can't access your pages

Crawling errors occur when Google requests a page but doesn’t receive a usable response. Prioritize these errors on important pages, since Google needs access to their content before it can index them.

Server error (5xx)

A server error means your server couldn’t complete Googlebot’s request. Persistent 5xx errors can prevent indexing and eventually cause previously indexed pages to drop out of search results.

Common codes include:

• 500 for an internal server problem
• 502 for a bad gateway response
• 503 when the server is temporarily unavailable

Check your server logs to see whether the errors began after a site update, an app or plugin installation, or a traffic spike. Your hosting provider can help identify configuration or capacity problems. Once the pages load normally, run a live test in URL Inspection before validating the fix.

Redirect errors

Redirect errors occur when Google follows a redirect but can’t reach a working page. Common causes include invalid destination URLs, long redirect chains, and redirect loops. A loop happens when page A redirects to page B, which redirects back to page A.

To fix these issues, make sure each redirect points directly to the page visitors should reach. For example, if page A redirects to page B and then to page C, change page A’s redirect to point straight to page C.

After a migration, review existing URL redirects for chains or loops, and update internal links to point directly to the destination pages.

Not found (404)

A 404 HTTP status code tells Google that a page couldn’t be found. This is expected for permanently deleted pages, but it needs attention when the page should exist or has a relevant replacement.

For each affected URL:

• Restore the page if it was deleted by mistake, or correct links that point to an invalid URL.
• Use a 301 redirect if the page moved or another page offers a similar product or equivalent information.
• Keep the 404 if the page is permanently gone without a replacement, and remove its URL from internal links and your XML sitemap.

For Shopify stores, review deleted product URLs and use the platform’s URL redirects tool where a suitable replacement exists.

Soft 404

A soft 404 occurs when a page looks like it’s missing or has no useful content, but the server returns a 200 status code, which tells Google the page loaded successfully. For example, a collection page might display “No products found” while still returning a 200 response.

The fix depends on whether the page should remain available:

• If it’s permanently gone, return a 404 status or redirect visitors to a page offering a similar product or equivalent information.
• If it should stay live, fix any loading problems and restore its content.
• If a product is temporarily out of stock, keep its description and images visible and add an availability or restock note.

Blocked due to unauthorized request (401) or access forbidden (403)

Some pages, such as customer accounts and staging sites, require a login or restrict access to authorized users. When Google tries to crawl these pages, the server may return:

• A 401 unauthorized request because Google can’t log in
• A 403 access forbidden response because Google isn’t allowed access

These responses are expected for private pages. If either response appears on a public page, check whether password protection, a security plugin, a firewall, or a CDN rule is blocking Googlebot. Then, run a live test in URL Inspection to confirm Google can reach the page.

Private URLs should not be included in your sitemap, which lists pages you want Google to index.

Blocking errors: When your site restricts Google

Your site can instruct Google not to crawl or index certain pages. These restrictions are useful when deliberate, but accidental blocks can keep important pages out of search results.

URL blocked by robots.txt

Your robots.txt file controls which URLs Google can crawl. If it blocks a page in your XML sitemap, check whether that restriction was intended.

Open yourdomain.com/robots.txt and look for a Disallow rule matching the affected URL. A rule such as Disallow: / can block all crawling for the crawler it applies to.

If the page should be accessible, update the blocking rule through your platform or site configuration. If you want it blocked, remove it from your sitemap. For detailed instructions, see our guide to pages blocked by robots.txt.

Excluded by "noindex" tag

A noindex directive tells Google not to include a page in search results. It can appear in the page’s HTML or in an HTTP response header called X-Robots-Tag.

This may be appropriate for thank-you pages or internal search results. If it affects a page you want indexed, check your platform settings, SEO plugin, theme, or apps to find where the instruction was added.

Remove the accidental directive, confirm the change with a live test in URL Inspection, and request indexing for important pages. If the directive comes from an HTTP header, your developer or hosting provider may need to update the server or CDN settings.

Indexed, though blocked by robots.txt

Robots.txt stops Google from crawling a page, but the URL can still appear in search results. Links from other pages can tell Google the URL exists, even when Google can’t access its content.

To keep the page out of search results, remove the robots.txt block and add a noindex tag. This lets Google crawl the page and read the instruction not to index it.

Blocked by page removal tool

This status means someone submitted a temporary removal request through Search Console’s Removals tool. The request hides the URL from search results for about six months but doesn’t permanently remove it from Google’s index.

If the request was a mistake, cancel it in the Removals tool. To keep the page out of search permanently, add a noindex directive if visitors still need access, or return a 404 or 410 status code if the page has been deleted.

Indexing statuses: When pages aren’t selected for indexing

Some pages haven’t been crawled yet, while others have been crawled but remain outside Google’s index. These statuses don’t always indicate a problem. Focus on pages you want appearing in search results.

Crawled – currently not indexed

This means Google crawled the page but hasn’t indexed it. The status alone doesn’t explain why. Review the page for thin content, repetitive product descriptions, or substantial overlap with other pages.

For pages you want indexed:

• Improve the content so it gives visitors useful, specific information.
• Add internal links from relevant pages to help Google find the page and understand its context.
• Combine overlapping pages when one page would serve visitors better.
• After making changes, request indexing through URL Inspection.

These steps can help but don’t guarantee indexing. See our guide to crawled but currently not indexed for the full process.

Discovered – currently not indexed

This means Google knows the URL exists but hasn’t crawled it yet. The delay may relate to server capacity or how Google prioritizes crawling.

On large ecommerce sites, filters and faceted navigation can generate many URLs with similar content. Review unnecessary URL combinations, check server performance, and link to important pages from your navigation and collections.

Duplicate pages and canonical statuses

A canonical tag identifies your preferred URL when several pages contain the same or very similar content. Google considers that preference but may select a different URL.

The Page indexing report distinguishes three situations:

• Alternate page with proper canonical tag: Google accepts another URL as the canonical. This is expected when you deliberately consolidate duplicate URLs, such as tracking URLs or Shopify product URLs within collection paths.
• Duplicate without user-selected canonical: Google found duplicate content and selected a canonical without your instruction. If you have a preferred version, specify it with canonical tags and use that URL consistently in internal links and your sitemap.
• Duplicate, Google chose different canonical than user: Google selected a different URL from the one you specified. Check both URLs in URL Inspection, then review whether your canonical tags, internal links, sitemap, and redirects consistently support your preferred version.

These statuses need attention when Google selects a URL you don’t want appearing in search.

Page with redirect

This status means the URL redirects to another page, so the original URL isn’t indexed. That’s expected when the redirect is intentional, though the destination must still qualify for indexing.

Investigate if the redirect is unexpected or leads to the wrong page. Remove redirected URLs from your sitemap and list the canonical destination URLs you want indexed.

How to validate a fix in Google Search Console

Google Search Console allows users to validate fixes for indexing errors. Once you've fixed every URL under a status, open that status in the Page indexing report and click Validate fix. Google then starts the validation process and rechecks the affected URLs.

The validation moves through a few stages:

• Started: Google has queued the recheck.
• Looking good: The URLs checked so far no longer show the error.
• Passed: Every affected URL has been rechecked and the issue is gone.
• Failed: At least one URL still shows the error. Fix the remaining URLs and start again.

Google's Page indexing report documentation notes that validation typically takes around two weeks and can take longer. Don't click Validate fix until the fix is live on every URL, or it will fail and you'll have to wait again. For a single important page, the faster route is to open the URL inspection tool, run a live test and click Request indexing.

How to prevent Google Search Console errors

Site launches, redesigns, migrations, and changes to products or plugins can introduce crawling and indexing problems. Regular checks help you catch these issues before they affect important pages.

• Review the Page indexing report regularly: Watch for sudden increases in not indexed pages, especially after site changes.
• Keep your XML sitemap current: Include only canonical pages you want indexed that return a 200 status code.
• Check crawling and indexing settings after major updates: Review robots.txt, noindex directives, and canonical tags after a redesign, migration, or theme change.
• Maintain redirects and internal links: Redirect moved or deleted pages when a relevant replacement exists, and update internal links to point directly to working destination pages.

Which Google Search Console errors are worth fixing?

Focus on errors affecting pages you want in search results. Redirected URLs, alternate pages with proper canonical tags, intentionally noindexed pages, and permanently deleted pages returning 404 usually don’t need fixing.

Start with important product, collection, and service pages, then prioritize:

1. Server and redirect errors that prevent Google from reaching them
2. Accidental noindex directives and robots.txt blocks that restrict access or indexing
3. Duplicate and “currently not indexed” statuses that exclude your preferred pages

After fixing the issues, monitor the Page indexing report for changes and the Performance report for impressions and clicks.

If you’d like help identifying where to start, request our free ecommerce SEO audit. Our SEO services address technical issues and strengthen the content and links that support search visibility.

Google Search Console errors: FAQs

How long does it take Google to fix errors after validation?

Validation typically takes around two weeks, though large sites or slow-to-crawl pages can take longer. For an individual page, use URL Inspection to run a live test, then select Request indexing to ask Google to crawl it again. If validation fails, Google shows which URLs still have the issue so you can fix them and try again.

Do Google Search Console errors hurt my rankings?

The errors themselves aren’t ranking penalties, but crawling or indexing problems can reduce search visibility. An accidental noindex tag can remove an important product page from search. A 404 on a permanently deleted page doesn’t penalize your other pages.

Why does Search Console show errors for pages I've never created?

Google found those URLs somewhere, usually in old links from external websites, auto-generated filter and parameter URLs, or URLs from a previous version of the site. The Referring page field in URL Inspection may help identify the source. If the URL shouldn’t exist and has no relevant replacement, returning a 404 is appropriate.

Should I remove URLs with errors from my sitemap?

Remove URLs that are permanently deleted, redirected, intentionally noindexed, or deliberately blocked from crawling. If a page should be indexed but has a temporary error, fix the problem. Your sitemap should list the canonical URLs you want Google to index.

How is the Page indexing report different from the old Google Search Console Coverage report?

The Page indexing report replaced the Coverage report. Instead of grouping pages as Error, Valid with warnings, Valid, and Excluded, it groups them as indexed or not indexed and lists reasons for pages that aren’t indexed.