“Server error (5xx)” in Google Search Console

What the status means

When Googlebot requested the page, your server, or something in front of it, answered with a 500-level code. Google ignores any content sent with a 5xx response, so it got nothing it could index.

The status shows what happened on the last crawl, and the error may be gone by now. It's still worth checking, because a server that fails for Googlebot may also be failing for visitors.

What Google does with 5xx errors

Google's documentation describes the following:

• Crawling slows down. 5xx and 429 responses make Google's crawlers temporarily reduce their rate. It goes back up gradually once the server returns 2xx again.
• Indexed pages stay for a while, then drop. Already indexed URLs are preserved at first, but those that keep returning a server error are eventually removed.
• A single error isn't a disaster. The damage comes from persistent errors. Google gives no number of days before a URL is dropped.

A short outage is usually forgiven. A section that fails for weeks is not.

Is it a problem?

How to find the cause

1. Open Indexing → Pages → Server error (5xx). Look at the dates on the chart and at URL patterns. One template failing and the whole site failing are different problems.
2. Open Settings → Crawl stats. The By response breakdown shows server errors over time. Host status shows whether Google had trouble reaching the server at all.
3. Test the URL below and in URL Inspection. The checker shows the response code and the redirect chain. If it comes back 200, try Test live URL in URL Inspection as well, because a firewall may treat Google differently from our checker.
4. Read the server logs for the same time. Filter by Googlebot and status 5. This is where you find the actual cause.

Which code points where

How to fix it

WordPress

• Turn on WP_DEBUG_LOG to see what crashes, and look at the PHP error log. Out-of-memory errors and plugin conflicts are common causes.
• Increase PHP workers or memory if the logs show the limit being reached. Caching full pages takes most of the load off PHP.
• Scan for heavy traffic from bots on xmlrpc.php and wp-login.php.

Shopify, Wix and Squarespace

• The server isn't yours, so you can't fix its errors. Check the platform's status page. If errors persist on specific URLs, contact support with examples. Theme code can still be the cause on Shopify, so test with a default theme.

Next.js and headless sites

• A page rendered on request can throw when the CMS or an API is down, and the visitor and Googlebot get a 500. Add error handling around data fetching, and return a real 404 when the item doesn't exist.
• With incremental static regeneration, Next.js keeps serving the last good page when a revalidation fails, so cached pages protect you during a CMS outage. Pages that were never generated aren't protected.

nginx and rate limits

• limit_req returns 503 by default when a client goes over the limit. If your rate limiting catches Googlebot, you've made your own 5xx errors. Check the limit against the crawl rate in Crawl stats.

Cloudflare

• Fix the origin first. Then check timeouts: Cloudflare's 524 appears when the origin takes too long, which is a slow page, not a Cloudflare fault.

Planned maintenance

Return 503 while the site is down. Don't serve a “we'll be back soon” page with status 200: Google may process that message as the content of your pages. Keep the outage short, because a long run of 5xx responses leads to URLs being dropped.

Also keep robots.txt available. If that file returns 5xx, Google's documentation says it stops crawling the whole site for the first 12 hours. You can test how your file is read with our robots.txt tester.

After fixing

Run Validate fix for the issue. Google says validation typically takes up to about two weeks, and it can take much longer. Crawling recovers gradually, so don't expect the old rate the next day. If Crawl stats look normal and the URLs return 200, the job is done.