Crawl errors in Google Search Console are easy to ignore until they start eating ranking signals. The Page Indexing report flags hundreds of URLs as “Not indexed” without telling you which ones cost real traffic and which are noise. Across the 60+ sites I’ve recovered from indexing issues since 2023, the same triage pattern works on every one. This guide gives you the triage flow for crawl errors in Google Search Console, the priority ranking I use, and the fixes that resolve 4xx and 5xx errors at scale.
The default mistake teams make is treating every error as urgent. A site with 12,000 indexed pages and 400 “Not Found” errors has a 3.3% error rate, which is normal. A site with 50 indexed pages and 12 errors has a 24% error rate, which is critical. The signal isn’t error count. It’s the ratio against indexed pages and the type of URLs hitting errors.
The Crawl Errors in Google Search Console Categories That Cost Rankings
Google Search Console groups indexing errors into specific reason codes, and they don’t carry equal weight. Here’s the priority order I work in for crawl errors in Google Search Console, ranked by ranking impact.
Server error (5xx) — highest priority. Googlebot sees your server returning 500, 502, or 503 codes. This drops crawl budget allocation and can de-index pages within 7 days if it persists. If you see 5xx errors in volume, fix infrastructure first. Don’t touch any other category until 5xx clears.
Soft 404 — high priority. The page returns 200 OK but Google detects empty content, near-empty content, or a “page not found” message. Soft 404s often hit thin product variant pages, expired event pages, or category pages that lost their listings. They count as low-quality signals against the entire site.
Crawled – currently not indexed — medium priority. Google saw the page, decided not to index it. This is usually a quality signal, not a technical one. Either the content is too thin, too duplicate, or too low-value to merit a slot. Fixing this means content work, not technical work.
Discovered – currently not indexed — medium priority. Google found the URL but hasn’t crawled it yet. Common on large sites where crawl budget hasn’t reached the new content. Internal linking and sitemap signals fix this.
Not Found (404) — low priority for most sites. The page returned a 404 code. Google handles 404s gracefully if they’re correct. The error matters only when valid URLs return 404 by mistake.
How to Triage 5xx Errors Before Anything Else
Server errors cascade. A 5xx on one URL signals infrastructure stress that affects every URL Google tries to crawl. The fix sequence I run on every recovery audit:
- Pull the last 30 days of 5xx URLs from GSC. Sort by date to spot incident clusters.
- Cross-reference with server logs. If logs show timeouts or connection refusals at the same timestamps, you have a capacity issue, not a code issue.
- Check rate limiting. Some hosts throttle Googlebot’s IP ranges by mistake. Verify in Cloudflare, Sucuri, or whoever sits in front of your origin.
- Test crawl budget settings. If you set a custom crawl rate in GSC years ago and forgot, Google may be hitting your server harder than it can handle.
- Run a fetch and render test on the URLs flagged. If they load fine for you but fail in GSC, the issue is geographic or IP-specific.
The fix usually lands in step 3 or step 5 on shared hosting. Dedicated hosting with autoscaling almost never produces 5xx for Googlebot unless there’s a code-level deadlock. If you’re seeing persistent 5xx and you’ve ruled out infrastructure, profile your slowest endpoints and check for database connection pool exhaustion.
Soft 404 Errors and Why They Spread Faster Than You’d Expect
Soft 404s are the most underestimated category of crawl errors in Google Search Console. The page returns 200 OK, so monitoring tools don’t flag it. But Google sees the page is empty and treats it as a 404. Worse, a few hundred soft 404s on the same URL pattern can drag down rankings on the entire pattern.
The common sources I see:
- Product pages for out-of-stock items that show a generic message instead of redirecting
- Category pages with no listings (empty filter combinations on faceted nav)
- Event pages where the event ended but the URL still resolves
- Tag archive pages with one or zero posts
- Search result pages indexed by accident
The fix isn’t always to delete. It’s to return the right status code or add real content. An out-of-stock product page should either redirect to the category, return a 410 if the SKU is permanently gone, or display alternatives plus the SKU’s specs so the page has substance. Empty filter pages should return 404 or noindex. Search result pages should always have a robots meta noindex.
Crawled But Not Indexed: When It’s a Content Problem
If GSC says Google crawled the page but didn’t index it, the algorithm made a quality judgment. Pushing the URL through Inspect and clicking “Request Indexing” doesn’t fix this. The signals didn’t meet Google’s threshold the first time and won’t on resubmission.
The fix is content. Audit the page against three checks: is it duplicate or near-duplicate of another URL on your site, is the content under 300 words of unique value, does it serve a real query in Search Console’s coverage data. If all three answers are bad, the page either needs a rewrite or a noindex/canonical to consolidate its signals into the version Google already indexed.
For e-commerce sites with product variant URLs, this category often hits ?color=red and ?size=large parameter URLs that are near-duplicates of the canonical product page. The fix is canonical tags pointing to the parent product, not new content. If you ignore this and let parameter URLs sit in the report, you’ll see the count climb every month as Google discovers more variants.
The Discovered But Not Crawled Backlog and How to Clear It
“Discovered – currently not indexed” means Google found the URL but didn’t get to it yet. On small sites this resolves itself. On large sites it can sit indefinitely if crawl budget is constrained. The fix sequence:
- Boost internal links to the affected URLs. URLs with 5+ internal links from indexed pages get crawled faster than orphans.
- Add the URLs to your XML sitemap if they aren’t there. Submit the sitemap in GSC.
- Check robots.txt for accidental blocks. A misplaced disallow can prevent crawling without showing as an error.
- Reduce crawl waste. If Googlebot is spending budget on faceted nav, parameter URLs, or staging environments, redirect that budget to high-value pages with proper noindex and disallow rules.
For deeper diagnosis on large sites, log file analysis tells you what Googlebot actually requested versus what GSC shows. Log file analysis separates the URLs Google can’t reach from the ones it’s deliberately deprioritizing. The combination of GSC data plus server logs is what makes large-site triage tractable. For more on related index issues, see our breakdown of soft 404 errors and how they interact with the broader index coverage error reports.
The honest summary on crawl errors in Google Search Console is that 90% of what teams worry about doesn’t matter, and the 10% that does matter usually traces back to 5xx or soft 404 issues. Fix those two categories first, every time, and the rest of the report becomes a manageable backlog rather than a crisis.