Quick answer
5xx responses mean that a server or upstream service failed while handling a request. 500, 502, 503, and 504 describe different failure points, but all can prevent a crawler from retrieving important content when they persist. Diagnose the underlying service and return a status that matches the outage rather than replacing an error with a misleading 200.
What the issue means
- 500 Internal Server Error: the application encountered an unexpected condition.
- 502 Bad Gateway: a gateway or proxy received an invalid response from an upstream service.
- 503 Service Unavailable: the service is temporarily unable to handle the request, often during maintenance or overload.
- 504 Gateway Timeout: a gateway or proxy did not receive a timely upstream response.
The exact wording and infrastructure vary, so confirm the source in application, server, proxy, and CDN logs.
Why it matters for SEO
A crawler cannot evaluate a page it cannot retrieve. Intermittent 5xx responses can also make coverage appear unstable and leave users with failed journeys. A brief, genuine 503 during maintenance is different from a recurring 500 on a product or editorial template.
A 5xx finding does not identify a ranking penalty. It identifies a retrieval failure that may block indexing or degrade the experience while it lasts.
How NOTABIS detects it
NOTABIS records the final response status for each crawled URL and reports an http-error finding when it observes a 5xx. If the request itself fails after retries, it may instead produce fetch-failed; an edge challenge can be classified as edge-blocked. The report shows the measured response and confidence for that crawl.
How to check it yourself
- Reproduce the request with the same URL and inspect timing and headers.
- Check application and web-server logs at the response timestamp.
- Trace reverse-proxy, CDN, DNS, database, queue, and upstream API dependencies.
- Compare a failing URL with a healthy URL from the same template.
- Test without and with redirects, authentication, and the relevant user agent.
- Confirm recovery with repeated requests before closing the incident.
How to fix it
Repair the application exception or dependency, correct proxy routing and timeouts, restore capacity, or complete the maintenance work. Use 503 while a temporary outage is real and remove it when service is healthy. Keep error responses from being cached as successful pages, and update monitoring for the route or template that failed.
After recovery, request representative URLs, inspect the final status, repair any internal links revealed by the incident, and re-run the audit.
When this is intentional or does not need fixing
A short, planned maintenance window can correctly return 503. A protected upstream may intentionally fail for an unauthorized context, but check that public users and crawlers receive the intended response. Persistent or repeated 5xx responses on public pages need investigation even when the audit captured only a small sample.
Related issues
Read HTTP error responses, HTTP status codes explained, fetch failures, and edge and bot blocking. Google’s HTTP status-code guidance explains why persistent server errors can prevent retrieval. Crawl coverage and audit limitations explains how failures affect confidence.
Run a NOTABIS audit
Run a NOTABIS SEO audit after the incident is resolved to confirm that important routes return the intended response consistently.