The server error 5xx Google Search Console status appears under Not indexed in the Page indexing report. Many of its neighbours, such as page with redirect or excluded by noindex tag, describe choices you made. This one describes a failure. It is also the status most often dismissed with “it was a blip”, and sometimes that is true. The way to know is to check whether the errors cluster in time, in a section of the site, or both.
What the server error 5xx Google Search Console status means
Google’s definition is one sentence: “Your server returned a 500-level error when the page was requested.” The 500 range covers every response where the server, not the request, is at fault. A generic 500 usually means the application crashed; a 502 or 504 usually means something between the visitor and the application, such as a proxy or load balancer, did not get an answer in time; a 503 means the server is deliberately refusing work.
What happens next matters more than the code. Google’s documentation on HTTP status codes says “5xx and 429 server errors prompt Google’s crawlers to temporarily slow down with crawling”, and that “already indexed URLs are preserved in the index, but eventually dropped.” So a short outage costs little, while errors that persist start removing pages you already rank with.
That challenges two opposite pieces of received wisdom. One says a 5xx de-indexes a page immediately, so any error is an emergency. The other says Google simply retries, so errors never matter. Neither matches what Google describes: crawling slows first, indexed URLs survive for a while, and only sustained failure drops them.
Finding the cause
The report gives you URLs and dates. Everything else comes from the server. Work through these in order.
- Reproduce it. Run URL Inspection’s live test on a few affected URLs. If they now return 200, the error was intermittent and you are looking for a pattern, not a broken page.
- Check the error log for the dates in the report. Application errors, database connection failures and memory limits all leave entries. A fatal error on one template explains a whole section failing at once.
- Check resource usage. Errors that cluster at busy times point to a server running out of CPU, memory or worker processes. A heavy crawl and a traffic peak arriving together can tip an undersized plan over.
- Check the access logs for Googlebot. Filter requests by user agent and status code to see exactly which URLs failed for Google and when. Our guide to log file analysis for SEO covers how.
- Check recent changes. A plugin update, a new theme, a server configuration edit or a firewall rule deployed just before the errors began is the most likely suspect.
Slow pages are a common hidden cause. A page that takes too long to build can hit a timeout at the proxy and be served as a 504 even though the application would eventually have finished. Work on server response time, covered in our post on page speed and SEO, often removes these errors without any change to the error itself.
Maintenance: use 503, not 200 or 404
Planned downtime is the one situation where you should return a 5xx on purpose. MDN’s reference for 503 Service Unavailable says the code “indicates that the server is not ready to handle the request”, with common causes being that “a server is down for maintenance or overloaded.” It adds that the response “should be used for temporary conditions and the Retry-After HTTP header should contain the estimated time for the recovery of the service, if possible.”
The mistakes come from the alternatives. The table sets out what each response tells a crawler during maintenance.
| Response during maintenance | What it tells the crawler | Verdict |
|---|---|---|
| 503 with Retry-After | The condition is temporary and when to try again | Correct |
| 200 with a maintenance message | This message is the page’s real content | Avoid |
| 404 | The page does not exist | Avoid |
| Cached 503 | MDN notes 503 responses “shouldn’t usually be cached”; a cache can keep serving the error after you are back | Avoid |
A maintenance page served with a 200 is the worst of these, because it is not an error at all as far as a crawler is concerned. Every URL on the site briefly claims to contain the same few lines of text. A 404 is wrong for a different reason: it says the page has gone, which our post on 404 errors and SEO covers. Make sure any CDN or caching layer does not hold on to the 503 once the work is done.
After the fix
Once the cause is fixed and URL Inspection’s live test returns 200, use Validate fix in the Page indexing report so Google rechecks the group. Then watch the Crawl Stats report in Search Console settings: host status and the share of responses that are server errors tell you whether the problem has truly gone or simply moved to other URLs.
Expect crawling to recover gradually rather than at once. Google slowed down because the server struggled, and it speeds up again as responses stay healthy. On large sites this interacts with how much Google is willing to crawl at all, which our guide to crawl budget explains.
What the report cannot tell you
The limitation is that Search Console sees only Google’s requests. It records that a page failed for Googlebot at a given moment, not why, and not whether visitors saw the same thing. An error that hit Googlebot alone, perhaps because a firewall treated it as a bot to throttle, looks identical to a full outage. Only your server logs separate the two, which is why logs, not the report, are where diagnosis happens.
Independent uptime monitoring fills part of the gap, because it tells you about failures before Google does. It cannot replace logs either: a monitor checking the homepage every few minutes will miss a template that fails only on product pages. If errors clear but the pages then sit under crawled, currently not indexed, the server problem is solved and Google is now judging the content. Redirect failures are a separate status again, covered in redirect error.
Frequently asked questions
Will a 5xx error remove my page from Google?
Not straight away. Google says indexed URLs are preserved in the index during server errors but eventually dropped if the errors continue. Crawling slows down first.
What status code should I use for planned maintenance?
A 503, ideally with a Retry-After header estimating when the service will be back. Avoid serving a maintenance message with a 200 or returning 404s.
Why does URL Inspection show the page working when the report shows a 5xx?
The error was probably intermittent: a timeout, a resource limit at a busy moment or a temporary firewall block. Check the server logs for the dates the report lists.
Is a 5xx the same as a 404?
No. A 404 says the page does not exist. A 5xx says the server failed while trying to respond, so the page may well exist but could not be served.
The takeaway Treat this status as a real fault. Find the pattern in your logs, fix the cause, return 503 with Retry-After for planned downtime, and validate once the live test returns 200.
