Search Console’s crawl error data is some of the most actionable information Google gives you directly. Unlike ranking data, which is noisy, delayed, and influenced by dozens of variables, crawl errors are precise: Google attempted to access a specific URL, encountered a specific problem, and logged it. Here is how to work through the reports systematically and turn the data into fixes that actually improve your site’s crawl health.

Where to Find Crawl Errors in Search Console

Crawl error data lives in two places in the current Search Console interface:

  • Pages report (Indexing → Pages): This is the primary view. It categorizes all URLs Google has encountered by whether they were indexed and why or why not. Error types here include server errors (5xx), redirect errors, not-found responses (404), and soft 404 classifications.
  • Crawl Stats (Settings → Crawl Stats): This view shows crawl volume over time with response code breakdowns by day. Use it to spot trends and anomalies — a sudden spike in 4xx or 5xx responses in the Crawl Stats chart often precedes ranking impacts by weeks, giving you a window to fix problems before they compound.

Server Errors (5xx)

Server errors mean Googlebot successfully reached your server but the server failed to return a valid response. Common causes include overloaded hosting infrastructure, application-level errors in your CMS or framework, timeout configurations that cut off slow requests, and firewall or bot management rules that accidentally block or rate-limit Googlebot specifically.

When you see 5xx errors in Crawl Stats, cross-reference the timestamps with your hosting control panel’s error log and your application error log. The cause is usually identifiable — a deploy that introduced a PHP error, a database connection pool that maxed out during a traffic spike, or a caching layer that failed. Chronic 5xx errors (not spikes, but a persistent baseline) cause Google to reduce its crawl rate for your site automatically. Reduced crawl rate means slower indexation of new and updated content.

Redirect Errors

Redirect errors appear when a redirect chain is too long, a redirect loop exists (URL A redirects to URL B redirects back to URL A), or a redirect chain resolves to a non-2xx final destination. Google stops following redirect chains after approximately five hops. Chains longer than that result in a redirect error classification for the original URL.

The most practical tool for diagnosing redirect issues is Screaming Frog run in List mode against your known redirect URLs. It will follow and report the full chain for each URL. Any chain longer than two hops (origin → 301 → final 200) should be collapsed to a direct redirect. Also check for redirect loops, which often appear after CMS migrations where the old URL patterns were not fully removed before the new redirects were added.

Not Found Errors (404)

404 errors are the most common crawl error on mature sites and the most likely to be noise. Not every 404 needs to be fixed — URLs that appear in old external links or historical sitemap submissions and were never part of your current site are expected noise. Your energy should go toward 404s that were recently live pages, 404s that appear in your current sitemap, and 404s that have active inbound backlinks pointing to them.

The Pages report in Search Console shows when Google first detected each error. Use that date to identify recently broken URLs versus long-standing dead URLs. For URLs with inbound links, check Ahrefs or a similar link data tool to quantify the link equity being lost before prioritizing redirect implementation.

Soft 404s

Soft 404s deserve their own dedicated treatment — I have a full post on soft 404 errors that covers causes and fixes in detail. In the crawl error context, they appear in the Pages report under ‘Not indexed’ and require different remediation than hard 404s. The response code is 200, so robots.txt and redirects are not the solution. The fix is usually noindex, canonical, or adding real content to the page.

Prioritization Framework

With potentially hundreds or thousands of crawl errors on a mature site, triage is essential. Here is the framework I use on audit engagements:

  • Critical: Any page in your sitemap that is returning an error. These are pages you explicitly told Google to index that it cannot access.
  • Critical: Pages with significant inbound backlink equity returning 404 or 5xx. Every crawl is equity wasted.
  • High: Redirect errors on URLs referenced in your primary navigation or used in active internal linking.
  • Medium: Recently-broken pages (last 30-60 days) that had organic traffic before breaking.
  • Low: Old URLs from legacy site versions with no inbound links, no sitemap inclusion, and no recent organic traffic.

How to Verify Fixes in Search Console

After fixing a crawl error, use the URL Inspection tool to test the live URL. It performs a real-time fetch of the page and returns the HTTP status code Google sees, the rendered HTML, and any crawl or indexation issues. This is your fastest verification method for individual URLs.

For bulk fixes affecting many URLs — a category of redirect errors you resolved, or a set of 404s you redirected — resubmit your sitemap after the fix and monitor the Pages report over the following two to four weeks. The error count in the relevant category should decline as Google recrawls the affected URLs. The ‘Validate Fix’ button in Search Console triggers a recrawl cycle for a specific error group, which can accelerate this process for large batches.

Crawl Errors as a Crawl Budget Signal

High crawl error rates are a crawl efficiency problem as much as an indexation problem. When Googlebot spends its crawl allowance hitting dead pages, it has less capacity left for your live content. Resolving crawl errors — especially at scale on large sites — often produces measurable improvements in how quickly new content gets discovered and indexed. The relationship between error volume and crawl efficiency is explored in my post on crawl budget optimization.

Crawl errors are one of the first datasets I pull in a technical website audit. They are frequently the fastest wins available — many can be resolved in a single afternoon with immediate impact on crawl health. If your site has accumulated errors over years of content changes and migrations, a structured audit gives you a prioritized list with context, not just a raw URL export to sort through manually.