Server Error (5xx): What It Means + How to Fix It

This status means Googlebot showed up, sent the request, and your server answered with a 500-class error instead of a page. Nothing about your content was ever evaluated — the failure happened before Google got that far. It's the crawl equivalent of knocking on a door and the house falling down before anyone answers.

That reframes the fix. There's no content, canonical, or indexing decision to make here. Something on your server broke, timed out, or actively refused the request, and the job is to find out which.

First, confirm it's still happening

GSC's report can lag your actual server state — you may have already fixed this, or it may be intermittent enough that it doesn't reproduce on demand.

Open Pages → Why pages aren't indexed, click into "Server error (5xx)," and pull an affected URL. Run it through URL Inspection and use Test live URL — this sends a fresh request right now, rather than showing you Google's last cached crawl result. Check the HTTP status Google actually received.

Find your cause

Work down this list — the tell for each is specific enough that you'll usually land on the right one fast.

1. The server is overloaded

Too many concurrent requests, a spike in traffic, or a database that can't keep up, and the server starts returning 502 Bad Gateway or 503 Service Unavailable under load — including to Googlebot.

Tell: the 5xx errors cluster around specific times (a traffic spike, a marketing push, a cron job), and your hosting dashboard or logs show CPU, memory, or database connections maxing out during those windows.

2. A specific page or route is crashing

The server itself is healthy, but one template, plugin, or code path throws an unhandled error — a bad database query, a null reference, a broken third-party API call the page depends on synchronously.

Tell: it's the same handful of URLs failing consistently, not a broad site-wide pattern, and your application error logs show a stack trace pointing at the exact route.

3. Googlebot's requests are timing out

The server eventually responds, but too slowly — Google gives up waiting and logs a timeout, which shows up here as a server error even though your server didn't technically "error."

Tell: in Settings → Crawl stats, average response time is high or spiking, and you see timeout entries in the host-status breakdown rather than clean error codes.

4. Bot protection or rate limiting is throttling Googlebot

A WAF, CDN, or hosting-level rate limiter is treating Googlebot's crawl pattern (many requests in a short window) as suspicious and serving it a 5xx instead of the page — sometimes without you configuring this on purpose.

Tell: the page loads instantly and normally in your own browser, but Test live URL in GSC gets a 5xx. Check your CDN/WAF dashboard for blocked requests from Google's crawl IP ranges.

5. A deploy or config change broke it

A recent release introduced the failure — a bad environment variable, a missing dependency in production, a misconfigured reverse proxy.

Tell: the errors started at a specific point in time that lines up with a deploy.

The fix

Match the fix to the cause you found.

1. Fix overload at the source

   For server overload (cause 1): add caching in front of expensive routes (page cache, CDN, or a reverse-proxy cache), scale your hosting tier or database connections, and defer heavy background work (image processing, report generation) off the request path. The goal is a server that stays responsive under Googlebot's crawl load, not just your normal traffic.

2. Fix the crashing route

   For a specific broken page or template (cause 2): pull the stack trace from your application logs for the exact failing URL and fix the underlying code — a missing null check, a failed dependency call that should degrade gracefully instead of throwing. Add error handling so one broken data source doesn't 500 the whole page.

3. Speed up slow responses

   For timeouts (cause 3): profile the slow route and cut its response time — database indexes, reducing synchronous third-party calls, server-side caching. Get it comfortably under a second; anything over a couple of seconds risks Google logging it as a failure even on a technically-successful response.

4. Allowlist Googlebot in your firewall or CDN

   For bot protection throttling Googlebot (cause 4): check your WAF/CDN (Cloudflare, Sucuri, a hosting-level firewall) for rules blocking traffic from Google's published crawler IP ranges. Allowlist verified Googlebot traffic — verify by reverse-DNS lookup on the requesting IP, since the user-agent string alone is easy to spoof.

5. Roll back or fix the breaking deploy

   For a deploy-caused break (cause 5): check recent releases against when the errors started. If it's a fast-moving incident, roll back first and diagnose after; otherwise fix forward — a missing production environment variable and a misconfigured reverse proxy are the two most common culprits.

Platform notes

• WordPress — often a plugin conflict or exhausted PHP memory limit. Check wp-content/debug.log, disable recently added plugins one at a time, and raise WP_MEMORY_LIMIT in wp-config.php. Shared hosting is also a common source of throttling under crawl load.
• Shopify — rare on Shopify's own infrastructure, but a heavy app or a custom Liquid section with an expensive loop can time out on large catalogs. Check the app's status page, then audit recently installed apps.
• Next.js (React) — check your hosting platform's function logs (Vercel, or your Node server), not just the browser network tab. A common cause: a server component or route handler blocking on a slow upstream API with no timeout — add one.
• Webflow — 5xx here is almost always a platform incident; check Webflow's status page. On a custom backend behind Webflow, the same overload and timeout causes above apply to that backend.

How to verify it's fixed

Re-crawling takes time, and Google's own guidance is not to expect it instantly. Check in this order:

1. URL Inspection → Test live URL — this is your fastest, most reliable signal. You want a clean 200 on demand, repeatedly, not just once.
2. Crawl stats → Host status — confirm the error rate has actually dropped over several days, not just for one manual test. A single successful test doesn't prove the overload or throttling issue is gone under real crawl load.
3. Pages report — request indexing once the live test is clean, then watch for the URL to drop out of "Server error (5xx)." This can take days to a couple of weeks; Google re-crawls on its own schedule and doesn't guarantee a timeline.

If the status persists after a couple of weeks despite a clean live test, the failure is likely intermittent — happening only under real crawl load — so correlate your server logs against Googlebot's actual request timestamps rather than trusting a single manual check.

When to ignore it

A handful of isolated 5xx errors during a known deploy window or a brief traffic spike, on a site that's otherwise healthy, isn't worth chasing — Google retries and moves on. The status is worth real attention when it's persistent, affects many URLs, or is climbing in Crawl stats over time; that's when it starts throttling how much of your site Google is willing to crawl at all.