Server Error (5xx) in Search Console: Causes and Fixes (2026)

"Server error (5xx)" in Search Console means your server answered Googlebot with a 500-level status instead of your page. Google's definition is one sentence: "Your server returned a 500-level error when the page was requested." What that sentence leaves out is the part that decides how urgent this is. Google does not treat a 5xx as a missing page. It treats it as a signal that your site is unwell, and it responds by crawling you less.

That is the difference between this status and every other one in the Page indexing report. A 404 or a noindex affects the URL it appears on. A run of 5xx responses affects how much of your entire site Google is willing to fetch, and the effect outlasts the outage. This article covers what Google documents about 5xx handling, how long indexed pages survive one, the six causes that produce it, and how to tell a real emergency from a report entry you can ignore.

What does "Server error (5xx)" mean in Google Search Console?

It means Googlebot requested a URL on your site and got back a status code in the 500 range instead of a page. The common ones are 500 for an unhandled application error, 502 for a bad gateway between your web server and the application behind it, 503 for a service that is unavailable or overloaded, and 504 for a gateway timeout. Search Console groups all of them under one status because Google's handling is the same for all of them.

Google's documentation on HTTP status codes is unusually specific about that handling. It states that "5xx and 429 server errors prompt Google's crawlers to temporarily slow down with crawling" and that "any content Google receives from URLs that return a 5xx status code is ignored." Both halves matter. The content is discarded, so a page that errors is not partially indexed or indexed from cache. And the crawl rate drops, which is the part that reaches pages that were never erroring at all.

The row people get wrong is 503. It is the only 5xx that is sometimes correct on purpose. If you are taking the site down for twenty minutes of planned work, a 503 is exactly what you should serve, because it tells crawlers the condition is temporary. Serving a 200 with a "back soon" page instead is the mistake, because Google will happily index that.

Will a 5xx error remove my pages from Google?

Not immediately, but yes if it persists. Google's documented behavior is that "already indexed URLs are preserved in the index, but eventually dropped." There is no published number attached to "eventually", and treating that ambiguity as safety is how sites lose rankings over a weekend outage nobody escalated.

The practical reading is that a short outage costs you very little. Google has seen your pages before, it keeps them, and when your server recovers it comes back. A multi-day outage is a different situation, because at some point Google stops preserving URLs it cannot re-fetch and they start dropping out. Recovery from that is not instant either, since the pages have to be recrawled and reindexed after the server is healthy again.

There is a second cost that is easier to miss. Google states that "Google decreases the crawl rate for the site" and that "the decrease in crawl rate is proportionate to the number of individual URLs that are returning a server error." So one broken URL out of fifty thousand barely registers. A deploy that returns 500 across every page tells Google the whole site is failing, and the crawl rate drops accordingly. New pages published during and after that window get discovered slowly, which is why traffic sometimes stays flat for weeks after an outage that was fixed in an hour.

How long does it take Google to recover after fixing a 5xx error?

Google's own answer is directional rather than numeric: "once the server starts responding with a 2xx status code, Google gradually increases the crawl rate for the site." Gradually is the operative word. The slowdown is applied quickly when errors appear and unwound slowly when they stop, which is the sensible design for a crawler that does not want to be the thing that knocks your server over a second time.

In practice, a site that was erroring for a few hours is usually back to normal crawl volume within days. A site that spent a week returning 500s can take considerably longer, and the recovery is not something you can accelerate by requesting indexing on individual URLs. The Crawl stats report under Settings in Search Console is where you watch this happen, because it shows total crawl requests and the response code breakdown over time.

What causes "Server error (5xx)" in Search Console?

Six causes account for nearly all of it. The order below is roughly how often each one turns out to be the answer.

• A bad deploy. Code shipped with a missing dependency, a bad migration, or a configuration value that exists locally and not in production. This produces the site-wide version, which is the damaging one, and it is usually noticed by a human within minutes. The exception is a deploy late on a Friday.
• Resource exhaustion under crawl load. The site works fine for humans and falls over when Googlebot requests forty pages a minute. Shared hosting and undersized PHP worker pools produce this constantly. It looks intermittent in the report because it is: the errors appear only during crawl bursts.
• A slow database query behind a timeout. One uncached query on one template pushes past the gateway timeout and returns 504 for that URL pattern only. This is the classic case where the Page indexing report lists a few hundred URLs that all share a path segment.
• Aggressive bot protection or rate limiting. A WAF rule or a rate limiter that treats Googlebot as an attacker and returns 429 or 503. Verify by checking whether the requests came from genuine Googlebot IP ranges before you unblock anything.
• Memory limits on specific pages. A page that loads an unbounded result set works with 50 rows and returns 500 with 50,000. Category and archive pages on old sites are the usual suspects.
• Expired or misconfigured infrastructure. A certificate, a DNS change, an origin server removed from a load balancer. These produce total outages that are obvious once you look and invisible until you do.

How do I fix a 5xx server error?

Start by reproducing it, because the report tells you what happened and not why. Take a URL from the affected list and request it yourself with curl so you see the raw status code rather than a browser's rendering of an error page. Then run the same URL through the URL Inspection tool and use Test Live URL, which fetches as Googlebot right now and tells you whether the problem is still present.

If the live test comes back clean, the error was transient and the report is describing history. Search Console data lags by a few days, so a status you fixed on Monday is still listed on Wednesday. Use the Validate Fix button, which asks Google to recheck, and remember Google's own rule for validation: if it finds a single remaining instance, the validation stops and fails. Fix the whole class before you start it.

If the live test errors too, the cause is in your server logs and nowhere else. Look at the application error log for the timestamp of the failed request, not the access log, since the access log will only confirm the status you already know. Match the URLs in the report against a pattern: a single path segment in common points at one broken template or query, while errors spread evenly across the whole site point at capacity or the deploy.

For the capacity version specifically, the fix is not an SEO fix. It is more workers, more memory, caching in front of the slow path, or a smaller blast radius on releases. It is also worth watching the origin from outside your own network, because the failure mode that catches teams out is a server that answers fine from the office and errors from other regions, which is precisely how Googlebot experiences it. A monitor that checks the site from several locations every minute turns that into an alert instead of a discovery you make in Search Console a week later.

Should I use 503 during maintenance?

Yes, and it is the one time a 5xx is the right answer. A 503 tells crawlers the unavailability is temporary and expected, so they should come back rather than draw conclusions. Adding a Retry-After header with a realistic duration makes the intent explicit. For planned work measured in minutes or hours, this is strictly better than any alternative.

What to avoid is the version that looks friendlier. A maintenance page that returns HTTP 200 is a page Google can index, and sites have ended up with "We'll be right back" indexed as the content of their homepage because of exactly this. If the site is down, say so with the status code. Also avoid leaving a 503 in place for days, because at that point it stops reading as maintenance and starts reading as a site that does not work.

When is a 5xx in the report safe to ignore?

When it is small, historical, and not reproducible. A handful of URLs erroring once during a traffic spike three weeks ago, on a site that now tests clean, is noise. Chasing it produces no benefit, and the report will clear itself as Google recrawls.

The signals that make it worth dropping other work: the count is growing between report refreshes, the affected URLs include pages that earn traffic, the errors reproduce on a live test, or the Crawl stats report shows total crawl requests falling. That last one is the most important and the least watched, because it is the measurable version of the crawl rate reduction Google describes, and it is the mechanism by which a server problem becomes a traffic problem.

One thing worth doing regardless of urgency is confirming that the pages which were erroring are still in Google's index rather than assuming they survived. Google drops URLs it cannot fetch without telling anyone, and the gap between a page falling out and someone noticing is usually measured in months. Checking the affected URL list against actual index status closes that gap in a few minutes, and our guide to checking whether URLs are indexed at scale covers the methods. If the check turns up pages that dropped, they need resubmitting rather than just fixing, and the bulk URL indexer handles that through the official channels.

Server error (5xx) in one paragraph

Google defines it as "your server returned a 500-level error when the page was requested", discards the content of any URL that returns one, and reduces your crawl rate in proportion to how many URLs are affected. Indexed pages survive a short outage and are "eventually dropped" if it continues. Fix the server rather than the report, validate only once the whole class is resolved, use 503 with Retry-After for planned maintenance, and check afterwards that nothing quietly fell out of the index while the site was down.