Server error (5xx) blocking indexing (Google Search Console)

What’s actually happening

Googlebot requested the page and the server returned a 500, 502, or 503 instead of the content. The URL won't index, and if a lot of URLs 5xx over a stretch of days, Google backs off and crawls the whole site less. The tricky part: these are often intermittent. The page works when you check it, but it failed when Googlebot hit it — usually during a traffic or crawl spike. Your server logs are the source of truth here, not a single browser load.

Common causes

• The origin overloads under crawl/traffic load — PHP-FPM workers or DB connections exhausted, returning 500/503.
• A faulty plugin, theme, or app deploy throwing fatal errors on specific routes (PHP fatals, unhandled exceptions).
• Script or upstream timeouts: the app takes too long and the proxy returns 502/504 (nginx upstream timed out).
• Misconfigured hosting or a reverse proxy — bad upstream definition, failed restart, or a 503 from maintenance mode left on.
• Aggressive rate-limiting or a CDN returning 5xx to Googlebot when request volume crosses a threshold.

How to fix it

1. Find the failures in your logsGrep the access log for Googlebot 5xx: grep Googlebot /var/log/nginx/access.log | grep ' 50[0-9] '. Cross-reference timestamps with the error log (tail of /var/log/nginx/error.log or PHP-FPM log). You're looking for which URLs failed and what the server was doing at that second.
2. Reproduce and read the actual errorHit a flagged URL repeatedly: for i in $(seq 1 20); do curl -s -o /dev/null -w "%{http_code}\n" https://example.com/page; done. If it flaps between 200 and 502/500, it's load or a timeout, not a static bug. Check the error log line for the exact fatal or upstream message.
3. Fix the root causeFor PHP fatals from a plugin/deploy, roll back or patch the offending code. For exhaustion, raise PHP-FPM pm.max_children and DB max_connections to fit your RAM, or add caching (page cache, object cache) so Googlebot isn't hitting PHP on every request. For timeouts, raise proxy_read_timeout / fastcgi_read_timeout or speed up the slow query.
4. Use 503 correctly for real maintenance onlyDuring planned downtime, return 503 with a Retry-After header so Google knows to come back — and make sure maintenance mode (e.g. WordPress .maintenance file) is actually removed afterward. A stuck 503 will deindex pages.
5. Validate fix and watch Crawl StatsClick Validate Fix on the issue. Then open Settings > Crawl stats and confirm the 5xx count drops and average response time recovers. Crawl rate climbs back on its own once errors stay low.