Fix 5xx server errors in Google Search Console

Server error (5xx) means Google received a server-side failure when it requested a URL. Start by finding the exact status code, affected address and failure time. Then compare the public response with your server or hosting logs before changing settings.

A page opening normally in your browser does not settle the diagnosis. Google may have encountered an earlier outage, an intermittent failure, a different cache response or an application error hidden by what the browser later displays.

What Server error (5xx) means for Google indexing

The “Server error (5xx)” reason groups failed server responses in Search Console. It identifies a failed fetch, not the application bug or infrastructure condition responsible for it.

Google’s HTTP status-code guidance^[1]Source 1HTTP status-code guidanceView source ↗ says server errors cause its crawlers to slow down temporarily. Existing indexed URLs can remain initially, but persistent failures can eventually cause them to be dropped. Content returned with a 5xx response is ignored.

That makes two distinctions useful. A short incident is different from a recurring failure. A new page that Google cannot fetch is different from an established page that failed once after previously being indexed.

Treat the report as evidence about particular requests. It does not prove that every page is currently unavailable or that every traffic change was caused by this issue.

Identify the exact HTTP status code

Find the code in the current response, access logs or provider diagnostics. Search Console’s grouped label alone is insufficient.

Code	Meaning	Useful investigation
500 Internal Server Error	An unexpected server condition prevented completion	Application exception, route configuration or recent deployment
502 Bad Gateway	A gateway received an invalid upstream response	Proxy-to-origin connection and upstream health
503 Service Unavailable	The service cannot currently handle the request	Maintenance, resource pressure or a failed dependency
504 Gateway Timeout	A gateway did not receive an upstream response in time	Upstream latency, application work and timeout configuration

These meanings come from HTTP Semantics, RFC 9110^[2]Source 2HTTP Semantics, RFC 9110View source ↗. They are clues, not one-to-one diagnoses. A 503 does not automatically mean you need a larger hosting plan, and a 500 does not automatically identify a WordPress plugin.

A content delivery network or hosting platform may also use provider-specific codes. Record the complete response and request identifier so the relevant provider can interpret it.

Check the request that Google could not fetch

Open the issue in the Page indexing report and inspect representative URLs. Group them by hostname, route, template and resource type. A failed product page, image-generation endpoint and internal PHP file may require different decisions.

Check the exact public address with a GET request. For example:

curl.exe -sS -D headers.txt -o page.html "https://example.com/path/"

Read the status in headers.txt and the content saved in page.html. If the response redirects, record the destination and inspect it separately. This keeps the original request distinct from the page you eventually see.

In Chrome, you can also open Developer Tools, select Network, reload the URL and inspect the main document request. Look at its response status rather than judging success from the visible layout alone.

When the page works in your browser

Compare the report’s recorded crawl with your check time. If Google’s failed request predates a deployment or outage recovery, the old status may simply await a new observation.

If the dates overlap, test other explanations. A browser may have a cached response, an authenticated session or cookies that change the route. Different edge locations or backend instances may serve different results. Failures may occur only when a dependency is slow.

A page can even display usable content while its initial HTML response has status 500. Client-side code may fill the screen after the server-rendering stage failed. Compare the response status and received HTML with the rendered page using the Googlebot-view inspection workflow.

One successful request establishes what happened to that request. Repeat the checks at a reasonable rate across the conditions and routes involved in the incident.

Initial diagnosis workflow

1. Select an important affected URL and record Google’s observation time.
2. Capture its current GET status, headers and response body.
3. Check a sibling URL using the same route or template.
4. Compare the failure window with deployments, outages and logs.
5. Assign the next investigation to the layer with supporting evidence.

Trace the failure through server logs

Use the same URL and time window throughout the investigation. Normalize timezones before comparing records. A log entry from the wrong request can send you toward an unrelated warning.

Evidence	What to record	What it helps distinguish
Edge or CDN request	Time, request ID, status and upstream timing	Edge-generated response versus origin failure
Origin access log	Host, path, method, status and duration	Which requests actually reached the server
Application error log	Exception, route and stack trace	The code or dependency that failed
Capacity metrics	Memory, CPU, workers and connection pressure	Resource exhaustion versus a deterministic bug
Deployment record	Version, time and changed component	A possible regression to investigate

Prioritize by reader impact and failure pattern. A sitewide outage needs faster attention than an isolated obsolete route, but neither should be diagnosed solely from a large report count.

Check CDN and origin responses

A proxy can return a 502 or 504 because the origin is unhealthy or slow. It can also generate a failure before the application sees the request. Compare edge and origin records using the request identifier and timestamp.

If the origin has no matching request, investigate the preceding connection or routing layer. If it logged a completed 500, continue into the application evidence. If the application is slow, determine what it was waiting for before simply increasing a timeout.

Keep any direct-origin testing within your hosting setup’s supported method. You do not need to remove protection from the entire site to establish which layer failed.

Check WordPress or server-rendered application errors

For WordPress, correlate the failed request with PHP and server error logs. A recent plugin, theme or configuration change is a candidate, not proof. Reproduce the issue in a suitable test environment and change one suspected component at a time.

WordPress documents debugging and logging controls^[3]Source 3Debugging and logging controlsView source ↗. Keep diagnostic output in the appropriate log rather than displaying sensitive application details on public pages.

For a server-rendered application, inspect production exceptions and imports that assume a browser environment. Browser-only functionality can fail during server execution. Locate the offending component or dependency instead of disabling rendering across the site as a blanket repair.

For suspected crawler-specific failures, inspect the actual request records. Google documents verifying its crawler and fetcher requests^[4]Source 4Verifying its crawler and fetcher requestsView source ↗. Changing a local request’s user-agent string is a comparison test; it does not establish that the request came from Google.

Handle maintenance and permanently removed pages correctly

For short maintenance, return an appropriate temporary-unavailability response rather than serving a maintenance message with status 200. A response can include a Retry-After header:

HTTP/1.1 503 Service Unavailable
Retry-After: 120
Content-Type: text/html; charset=utf-8

Here, the delay is expressed in seconds. It communicates an expected retry interval to clients; it is not a promise that Google will revisit at that exact time.

Restore the normal response when maintenance ends. Google’s temporary site-pausing guidance^[5]Source 5Temporary site-pausing guidanceView source ↗ warns that leaving a whole site unavailable for an extended period can affect search visibility. Avoid treating 503 as a long-term publishing state.

A permanently retired URL needs a different response. Return 404 or 410 when the content is gone without a suitable replacement. Use a relevant redirect when the content genuinely moved. The page-with-redirect guide explains the distinction between an old address and its replacement.

Do not redirect every obsolete address to a generic error message that returns 200. That can introduce a soft 404 rather than solving the underlying status problem. Adding noindex or blocking crawling also does not repair a failing server response.

Verify recovery before validating the fix

Repeat the original request after the correction. Confirm both the status and the useful content. Then check affected sibling routes and the conditions under which failures occurred, including uncached or anonymous requests where relevant.

Review the failure pattern over a suitable observation window. A recurring 500 every few requests is still an incident even when the latest reload succeeds. There is no universal error percentage that makes every site safe; use impact, duration and the affected functionality to judge priority.

Recovery workflow

1. Repeat the public GET check and compare its status and body with the intended outcome.
2. Verify that matching application or infrastructure errors have stopped.
3. Recheck representative sibling URLs and the previously failing request conditions.
4. Run Search Console’s live URL test.
5. Validate the issue when the relevant fixes are deployed, then monitor later crawl evidence.

Google’s URL Inspection documentation^[6]Source 6URL Inspection documentationView source ↗ explains the difference between a live test and information about the indexed version. The live test helps establish current fetch behavior. The recorded crawl may still describe the earlier failure.

Use the Page indexing report^[7]Source 7Page indexing reportView source ↗ to follow validation and the affected examples. Validation does not change your application or erase the need for a working response. A successful fetch also does not guarantee that Google will index a page with other unresolved issues.

Fix server error (5xx) with a repeatable evidence trail

Choose one important failing URL and capture its status, response body, request time and relevant request identifier. Match that request to the responsible log entry, correct the cause and repeat the same check.

If you need help from hosting or development, send those observations with the affected route pattern and recent deployment details. A precise request trail gives the next person something to investigate and gives you a clear way to confirm the repair.

Sources

1. Google Search Central. HTTP status-code guidance.

2. IETF. HTTP Semantics, RFC 9110.

3. developer.wordpress.org. Debugging and logging controls.

4. Google Search Central. Verifying its crawler and fetcher requests.

5. Google Search Central. Temporary site-pausing guidance.

6. Google Search Console Help. URL Inspection documentation.

7. Google Search Console Help. Page indexing report.