Troubleshooting

How To Identify Google Search Console Errors and Determine If There’s a Problem

Finding the issues & resolving them is as easy as:

Receive an error email alert from GSC & click it OR visit GSC directly and navigate to the Coverage report.

Review your Coverage Error reports directly in GSC, which specify what the issue is and what URL(s) that issue applies to.

QA the issue on the URLs in question (e.g. validate that the issue is still occurring)

Determine the priority of the fix, based on the combination of these two factors:

1. The URL it’s occurring on (does it matter to your business? How much?)
2. The urgency/scale of the issue itself (outlined by major Issue type, below.)

If you detect a real issue, then determine the correct action to revolve it (generally outlined the correct actions below.) If you couldn’t solve it by yourself or don’t know what to do even after you read the guidelines, you can reach out to The Webmasters Help Community or an SEO agency (like ourselves) for help. 

After taking the correct action, you should carry out the validation process in most cases. NOTES: 

• GSC is, ultimately, software. Sometimes software breaks! So sometimes, the issue is on Google’s end – and you should wait it out.
• False positives can and do happen. Ensure you can replicate the issue that GSC is pointing out to you before you “fix” an issue that’s not really broken.
• False positives are most common on the Mobile Usability report (e.g. issues specific to smartphones). If this happens frequently, you may be seeing signs of Google struggling to render your website (or not finding a particular page to be worth the work of rendering it.) 

Issues in Google Search Console Index Coverage Report

Once you click on Coverage, you will see:

• Error,
• Valid with warning,
• Valid, and
• Excluded tabs at the top of the page.

The summary page shows the results for all URLs in your property grouped by status, and the specific reason for that status (such as server errors). By clicking a table row on the summary page, you can view the list of URLs with the same status/reason and more details about the issue. Don’t forget to scroll below the graph to see that data set (depending on your screen size, that gets buried easily!)

GSC’s Coverage Error Summary Report

Let’s go over all the statuses, the reason for that status, and how to fix these URL issues under Index Coverage Report.

GSC Index Coverage Most Common “Errors” List

Errors mean that these specific pages cannot be indexed, therefore won’t be visible on Google search results page (SERP). Meaning no one can access your website via organic search. Below are the reasons that your submitted URL may have a crawl issue, and what those errors actually mean.

Submitted URL marked ‘noindex’

A page that you have previously submitted, or are currently submitting to Google (likely via the sitemap XML file) has a ‘noindex’ directive either in a meta tag or HTTP header. 

So the real question you need to answer is: should the page(s) be indexed or not? 

If the page(s) should be indexed, the meta tag or HTTP header noindex directive should be removed. You may want to use the URL Inspection tool to investigate and re-submit the article for indexation once the issue is resolved. You can also start the Validation process in GSC to clear out the errors – this way if/when new errors arise, they are easier to spot (and not easily buried under old and inaccurate issues!

Look for the “Validate Fix” button within the error you are reviewing.

If the page(s) are correctly noindexed, just make sure the URL in question is not listed on a current XML file. 

Note: when you validate this error, it’s checking to see if the page stopped being noindexed. It will validate correctly in that case. But if the correct solution is to remove the page from the sitemap file, then validation won’t work. In this edge case, you should just ignore the error. It’ll clear itself out eventually. 

Server error (5xx)

Your server returned a 500-level error when the page was requested. Investigate and contact your server provider if there is a problem since the capabilities of your server indirectly affects the indexation process as well.

You may see URLs that are working on this list; they get added to this report if/when there is a server blip and your site goes down. Simply start the validation process to clear these out (but if this happens frequently, you should resolve that issue with your host directly!)

Redirect error

Google experienced a redirect error, either a redirect chain or a redirect loop. By using a web debugging tool, such a Screaming Frog or Httpstatus.io, to learn what causes this redirect error.

Redirect loops are redirects that cause errors because they (eventually) point to themselves, e.g. Page A -> Page B -> Page A. Resolve these by deciding what the correct page is (or should be), and ensure that the final page of the redirect correctly loads. 

Redirect hops are multi-step redirects, e.g. Page A -> Page B -> Page C – and sometimes deeper. (NOTE that Google will only follow 8 redirect chain steps before giving up. Each additional “hop” results in lost SEO equity.) Fix this by changing the redirect from Page A to point directly to Page C, or whatever the final, 200 page should be. This is rather an issue we see after website migrations, so make sure that you plan your migration well.

Submitted URL blocked by robots.txt

It’s not uncommon to accidentally send conflicting messages to search engines. In this case, you are submitting a URL to Google (likely via your sitemap XML file) as a page to crawl & index, while simultaneously blocking that URL in your robots.txt file. 

So again, the real question comes down to: should the page be indexed? 

If it should be indexed, you are blocking it in your robots.txt file. If you aren’t sure what line of the fix is causing the conflict: 

• Click any page in the Examples and you’ll see a panel on the right-hand side.
• Click ‘test robots.txt blocking’ to run the robots.txt tester for that URL, and the rule that is blocking that URL will be highlighted.
• Update your robots.txt file to remove or alter the rule, as appropriate.
• The Robots.txt tool will be your best bud on this one.

If the URL should not be indexed, remove it from your sitemap XML file. 

Submitted URL seems to be a Soft 404

A “soft 404” is a page that appears to be blank (so far as Google can tell), and therefore may be a 404 error that’s not correctly sending a 404 response code (this is a common 404 mistake to avoid!)

If the page is, in fact, an error page, work with your web developer to send an actual 404 http header response. If your website is an SPA (single page application), sending a 404 not “out of the box” functionality, so here’s how have your SPA correctly send a 404 error. Further, consider redirecting the page and/or issuing a 410 (Gone) status (find more about why we recommend this on our 404 FAQ page.)

If the page is not an error page, it’s either a) a temporary bug (try the validation process and see if it will clear itself out, OR b) an issue. If Google can’t access and/or render the contents of your page, they won’t “see” the page to know it’s good and valid. 

Why wouldn’t they be able to render it? Generally due to: 

• JS, cookie, or CSS errors
• Blocked JS/CSS (e.g. blocked resources) 
• General timeout errors / Google just choking on your JavaScript. Google can struggle with perfectly “valid” JS, but it’ll require a “fix” regardless – if ranking that page is important to your business. Work with your development team to resolve these issues (and reach out if you need help doing so!)

Submitted URL not found (404)

Similar to above, if you are submitting a URL (via your sitemap XML file) and it issues a 404 error, you need to resolve it. Generally speaking, you’ll either fix the page (if the 404 is in error, and the content should be there), or you should 301 redirect the URL to the closest functional page on your site. Don’t forget to fix any broken links on your website!

Submitted URL has crawl issue

Sometimes, Google notified you about crawl errors that don’t fall into any of the other buckets. These can be bugs on Google’s end (they will clear themselves out eventually), or there’s some other error. In this scenario, you should debug your page using the URL Inspection Tool. 

Example of “Submitted URL has crawl issue error” in GSC

If you still see issues, you can refer to our guide to indexing and crawling for a thorough explanation.

GSC Index Coverage Most Common Issues from the “Excluded” List

Excluded URLs represent the ones that Google believes are intentionally left out from indexation. However, that’s not always the case! That’s why it’s important to review periodically for issues.  

From Google:

“These pages are typically not indexed, and we think that is appropriate. These pages are either duplicates of indexed pages, or blocked from indexing by some mechanism on your site, or otherwise not indexed for a reason that we think is not an error.”    

Excluded by ‘noindex’ tag and blocked by robots.txt

The Googlebot encountered a ‘noindex’ directive, or a disallow in the robots.txt file and didn’t index the page. If this is intentional, perfect. If not, remove the noindex tag (or resolve the robots.txt issue) and simply add the URL to your sitemap.

Blocked by page removal tool

This states that the URL is currently blocked by a URL removal request. The URL removal tool only helps you to suspend the indexation of a page for a period of 90 days. After that, Google may index the page again so if you need a permanent option, just block, noindex or remove the page.

Crawl anomaly

Google encountered a bug. That may have been a temporary bug on your side, OR on Google’s side, but the result is that the page content couldn’t be retrieved by Google. 

Assuming these are valid pages and you want them indexed, crawl errors of such can be identified by using the URL Inspection Tool. If none come up, resubmit the URL for Google’s consideration – and monitor to see if it works. If errors do come up, work to resolve them. 

If they are not real or valid pages, you can ignore them (or redirect them, if appropriate.)

Not found 404

Much like the Submitted URL not found (404) above, this is a list of 404s on your site. In this case, you’ve not submitted them to Google, but nevertheless, Google is aware of them. You should take steps to correct these (generally via 301 redirects, but issuing a 410 instead is also a valid step.)

Discovered – not currently indexed

Review this list of URLs to ensure no important pages are listed (work to improve & index them if they are valid.) If many pages are listed, it could be a sign of quality issues on your site as a whole.

Canonical related exclusions

There are several cases where Google doesn’t index the specific URL due to canonicals.

• Alternate page with proper canonical tag: The page in question canonicalizes another valid page, and Google has accepted your recommendation. If this is correct, no action is needed. If the canonical is incorrect, you’ll need to fix where it’s pointed at.
• Duplicate without user-selected canonical: The URL has duplicates, and none of the URLs is marked as canonical. Review the duplicates and decide on a canonical, then mark each page accordingly (alternatively, you can remove or redirect the unnecessary duplicates.) You can see the Google-selected canonical URL by inspecting this URL.
• These are common for URL variations with and without URL parameters. Where possible, explicitly state the correct canonical to reduce Google’s work in having to “assume” what’s correct and keep your URL structure as basic as possible.
• Duplicate, Google chose different canonical than user: Even though you marked a specific URL as the canonical for the given page, Google found another URL that it believes is a better candidate for canonical.
• Examine these in detail. In general, Google overriding your instructions is a sign of an issue. And if they don’t trust your recommendations here, they may not trust them elsewhere – so it’s important to get these aligned.
• If you believe Google’s selections are correct, you should update your canonical tags to reflect the “reality” of the situations.
• If you believe they are not correct, then you’ll have to do some fairly in-depth work to understand why & resolve those issues. That’s a problem for another article!

The complete list of the reasons that create the excluded list of URLs can be found here.

Excluded error types in GSC

GSC Index Coverage Most Common “Valid with Warnings” List

Valid with warnings are the URLs that have some issues that aren’t preventing indexation. However, these “warnings” can limit ranking potential, and are therefore worthy of review. 

Indexed, though blocked by robots.txt

A similar issue to the index coverage issue resulting from robots.txt directive, however, these pages are indexed. If the page should not be indexed, and is intentionally blocked, use the “Remove URL” tool in GSC to get it done quickly. If you’ve made a mistake, and the page should be indexed, then refer to the robots.txt tool once again.

Indexed, though blocked by robots.txt error in GSC

GSC Index Coverage Valid List

Valid URLs are generally okay – but you may want to check and ensure the URLs under this group are good & valid URLs. 

Submitted and indexed

The list of URLs where theoretically, everything went according to plan. You wanted the page indexed, so you submitted it, and it worked. 

Indexed but not submitted in sitemap URLs

In this case, the URL was discovered elsewhere by Google and indexed. If any important pages are on this list, consider doing the work to include them on the XML sitemap file instead. If URLs you don’t like are on this list, you should work to deindex them. 

Indexed pages: Submitted and indexed, and Indexed, not submitted in sitemap error in GSC

What Other GSC Errors Might I Find

You’ll get automatic emails notifying you about issues in 3 other primary cases:

1. Issues with Mobile Usability
2. Issues unreadable structured data
3. Issues with your AMP setup

In each case, the process is the same: verify if the issue is real. If it is, work with your engineering team to fix it (for these issues, it’s almost always your design your development team that has to help), and start the Validation process to clear them out once you confirm the fix (good SEO QA processes can help here!)