Server Error (5xx) in Google Search Console: How to Fix It

Short answer: when Googlebot asked for the page, your server answered with a 500-level error (500, 502, 503, 504 and so on) instead of the page. Google slows down crawling when this happens. If the URL keeps failing, Google drops it from the index. Find out whether the error is still happening, fix the cause (code, server load, or a firewall blocking Googlebot), then validate the fix in Search Console.

What the status means

It appears in the Page indexing report (Indexing → Pages) as a reason a page is not indexed. Google’s help keeps it short: “Your server returned a 500-level error when the page was requested.”

Google’s HTTP status code docs explain what follows:

• Google ignores any content it gets from a URL that returns 5xx.
• 5xx and 429 errors make Google’s crawlers slow down for a while. The more URLs that fail, the bigger the slowdown.
• URLs that are already indexed stay for a while, but are “eventually dropped” if the errors continue.
• When the server returns 2xx again, Google slowly raises the crawl rate back up.

So a short outage is usually fine. A server that keeps failing for Google is not.

Step 1: check if the error is still happening

Search Console shows what happened during Google’s last crawl, which may be days old. Start with the present:

• URL Inspection → Test live URL on an affected page. If the live test passes, the error was likely short-lived.
• Settings → Crawl stats. Look at the responses breakdown for 5xx spikes, and at Host status. Google’s help for this status points here first.
• Request the URL yourself a few times. Some errors only show up under load or now and then.

# Status code of one URL, 5 times in a row
for i in 1 2 3 4 5; do
  curl -s -o /dev/null -w "%{http_code} %{time_total}s\n" https://example.com/page
done

The free sitemap finder does this for 30 URLs from your sitemap at once and lists any that answer with an error or take longer than 3 seconds.

Step 2: find the cause

The application crashes (500)

A bug, a failed database query or a bad deploy throws an error. Your error logs or error tracker show the exact message and the URL. Look for patterns: one template, one plugin, or URLs with odd parameters.

The server is overloaded (502, 503, 504)

Too few workers, slow database queries or a busy shared host make the server time out. A CDN in front of a slow origin turns this into 502 or 504. Google’s help suggests reducing load from dynamic pages and making sure the server is not down or overloaded.

A firewall treats Googlebot as a bot to block

Bot protection, rate limits or WAF rules can answer Googlebot with an error page while normal visitors see the site fine. Google’s help lists this check too: make sure firewalls and protection systems are not blocking Googlebot. Search your server or CDN logs for Googlebot requests to the failing URLs and see what they got back.

Planned maintenance that ran long

For a short break, a 503 is the right answer. Google’s guide on pausing a site says to return an informational error page with 503 if you must disable the site for one or two days, and calls a full shutdown an extreme step for a few days at most.

Step 3: fix it

1. Fix the error in code or roll back the deploy that caused it.
2. Add capacity or caching if the errors match traffic peaks or crawl spikes.
3. Let verified Googlebot through your firewall. Verify it by reverse DNS (host name ends in googlebot.com, google.com or googleusercontent.com, and a forward lookup returns the same IP) or by Google’s published common-crawlers.json IP list. Don’t trust the user agent alone.
4. Keep robots.txt healthy. Google’s pause guide warns never to return 503 for robots.txt, because that blocks all crawling.
5. Don’t fake a 200. A “something went wrong” page with status 200 can be read as a soft 404. Return a real 5xx while the page is broken.

Step 4: confirm and validate

Run a live test in URL Inspection on a few affected URLs. If they pass, click Request indexing for the most important ones, then Validate fix in the report. Google says validation usually takes up to about two weeks and sometimes much longer. Don’t restart it until it has passed or failed.

Then keep watching. A server error that comes back is a sign the first fix only hid the cause. Uptime monitoring that alerts you on 5xx catches it before Google’s next crawl does.

Frequently asked questions

Related guides

• Blocked Due to Access Forbidden (403) or Unauthorized (401)
• Not Found (404)
• Soft 404 Errors
• Crawl Budget Explained
• All Search Console indexing statuses