Why Google got a server error from your pages, and how to stop it happening again

What the error means

When Google requested the page, the server answered with a 5xx status (500, 502, 503 or 504) or did not answer in time. The page could not be read, so it was not indexed or was dropped.

Why Google rejects it

5xx errors mean the server failed, not the page. They come from overload during crawl bursts, crashing plugins or apps, upstream timeouts behind a CDN, and maintenance windows. Repeated server errors also make Google slow down how often it crawls the whole site.

How to fix it

1. Check whether the error is current: test the URL now from outside your network and with URL Inspection's live test.
2. Open the Crawl stats report in Search Console to see when server errors happened and whether they cluster in time.
3. Match those times against server logs, hosting status and deploys to find the cause.
4. Reduce load: cache pages, remove slow plugins or apps, and make sure the host can handle crawler bursts.
5. For planned maintenance, return 503 with a Retry-After header rather than a 200 maintenance page or a 500.

Common causes

Origin overload or exhausted resources

A host can return 500, 502, 503, or 504 when traffic exceeds available workers, memory, database connections, or upstream capacity. Googlebot may encounter the error during crawl bursts even if the site works later. Check host availability and request logs around the reported time.

Plugin, theme, or application exception

A code path can fail only for one template, product state, or query parameter. The same error may repeat on a narrow group of URLs. Review PHP or application logs and recent plugin/theme changes; do not infer an outage from one successful manual reload.

Proxy or upstream timeout

A CDN, reverse proxy, or load balancer can time out while waiting for the origin and return a 5xx even if the origin eventually completes. Compare edge and origin logs to find where the request failed.

Brief maintenance or deployment window

A backup, update, restart, or migration can temporarily interrupt responses. Google may crawl during that window and report a server error after the site has recovered. Match Search Console crawl dates with deployment and host status history.

Fix it on your platform

On Shopify

1. Check Shopify's status history and the exact crawl time first. Shopify-hosted storefront errors may be platform incidents, while a proxy, app, or custom storefront can be a separate source.
2. If a CDN or custom storefront sits in front, compare edge and origin responses and logs for 502/503/504 errors.
3. Identify whether failures cluster on one app or page template, then disable or repair the responsible integration in a controlled way.
4. Retest the public URL and confirm the product remains published and reachable after a theme or app change.

On WooCommerce

1. Check PHP and web server logs for fatal errors at the crawl timestamps and correlate them with plugin, theme, backup, or deployment changes.
2. Review hosting resource limits, PHP workers, database connections, and slow queries. Enable caching for anonymous catalog pages if dynamic requests overload the origin.
3. Test affected and unaffected templates to isolate whether the failure follows one product type, plugin, or query parameter.
4. Ask the host for edge and origin logs if a proxy returns the error before WordPress receives the request.

On other platforms

1. Check the platform status page and deployment history at the time Google reported the error.
2. For custom hosting, trace the status across CDN, load balancer, web server, application, and database logs.
3. Reduce slow server-side work and cache stable anonymous content where appropriate; do not return a fake 200 for a failed page.
4. During planned maintenance, use an appropriate temporary unavailable response and restore normal service promptly.

How to confirm it is fixed

1. Repeat the exact affected URL from outside the admin session and record status and response time at multiple times if errors are intermittent.
2. Compare Search Console Crawl Stats and URL Inspection with edge/origin logs; a successful live test does not erase an earlier transient failure.
3. Run the bulk status check across affected URLs to identify whether failures follow a template or path pattern.
4. After the site is stable, monitor the Page indexing report for a later successful crawl; do not expect the old report row to change immediately.

A worked example

Hypothetical case: a WooCommerce store receives Server error (5xx) reports for product pages during nightly catalog imports. Manual visits the next morning return 200. The host logs show PHP workers exhausted while the importer updates products and cache rebuilds simultaneously. The owner moves the import to a quieter window, enables anonymous page caching, and asks the host to review worker limits. They compare the next Search Console crawl with server logs and test a sample of product URLs from outside the network. The old report remains until Google crawls again, so the owner tracks new crawl results rather than repeatedly validating the same historical error.

Other errors like this