5XX Error URL in XML Sitemaps: How to Fix It

What a 5XX in a sitemap means

A 5XX status code is a server-side error: the request was valid, but your server could not fulfill it. The most common are 500 (Internal Server Error), 502 (Bad Gateway), 503 (Service Unavailable), and 504 (Gateway Timeout). When that error appears on a URL listed in your XML sitemap, the contradiction is the problem. A sitemap is a curated list of pages you are explicitly asking Google to crawl and index. Returning a server error on one of those URLs tells Google that a page you flagged as important cannot be served.

Google is clear that a sitemap should contain only URLs that respond with a 200 (OK) status code, with no 3xx redirects, 4xx errors, or 5xx server errors. A 5XX entry is therefore a direct conflict between your stated intent and your server's actual behavior.

Why it matters: crawl rate, indexation, and trust

A site that regularly returns 5XX errors signals instability to Google. If Googlebot detects slow responses, timeouts, or intermittent 5XX errors, it will deliberately scale back its crawl rate to avoid overloading your server. That reduced crawl rate slows the discovery and refresh of all your content, not just the failing URLs.

Indexation suffers directly. A page returning a 5XX cannot be indexed, so it will not appear in search results. Worse, failed requests waste crawl budget on dead ends instead of your valuable pages. Trust erodes too: when the URLs in your sitemap, the strongest priority signal you can send, are the ones throwing errors, Google loses confidence in the reliability of your whole site.

Transient vs persistent

Not every 5XX is equal, and the distinction drives your response.

Transient (often 503)

A short outage, a brief deploy window, or a momentary load spike. A 503 Service Unavailable communicates temporary unavailability, and Google will retry later rather than dropping the page. Google treats short outages as safe, especially under an hour.

Persistent (often 500)

A 500 is treated as a technical fault, not intentional downtime. If a URL keeps returning 5XX across multiple crawls, or if you serve 503 for more than a day or two, Google may drop those URLs from the index. Returning 503 or 429 for more than two days is enough to cause de-indexing, so a persistent error is an emergency, not a nuisance.

Common causes

Most sitemap 5XX errors trace back to a handful of root causes:

Overloaded server. Insufficient memory, CPU, or worker processes under crawl or traffic load, often surfacing as 502 or 504 timeouts.

Bad deploys. A broken release, a missing dependency, or a fatal application error throws 500s across affected routes.

Timeouts. Slow database queries or upstream API calls exceed the gateway timeout, producing 504s.

Stale sitemap entries. URLs that were removed or migrated but never pruned from the sitemap, now hitting error handlers.

How to diagnose

Crawl the sitemap directly so you test exactly the URLs you submitted to Google. In Screaming Frog, switch to List mode, point it at your sitemap XML, and filter the Response Codes tab for the Server Error (5xx) bucket. You can also crawl your full site and your sitemap together so the tool compares both and surfaces sitemap-only failures.

Because 5XX responses are frequently temporary, enable retries before drawing conclusions. Raise Configuration > Spider > Advanced > Response Timeout and 5xx Response Retries so a single momentary blip is not mistaken for a persistent fault. Cross-check against the Page Indexing report in Google Search Console, which flags Server error (5xx) URLs, and inspect a sample URL live to confirm the current status.

How to fix

1. Stabilize the server first

Treat persistent 500s as the priority. Read the server and application logs for the failing URLs, identify the exception or timeout, and resolve it: roll back a bad deploy, add resources, optimize the slow query, or fix the application bug. The goal is for every sitemap URL to return 200 OK consistently across repeated requests.

2. Use 503 with Retry-After only when truly temporary

For planned maintenance or a brief outage, return a 503 and include a Retry-After header so Googlebot reschedules instead of logging a hard failure. Never leave it in place for more than a day or two, and never use it to mask a real fault.

HTTP/1.1 503 Service Unavailable
Retry-After: 3600
Content-Type: text/html

<!-- Maintenance in progress, back within the hour -->

Retry-After can take seconds (as above, 3600 = one hour) or an HTTP date. Note that Google does not always honor the exact value and may retry sooner.

3. Clean the sitemap

If a failing URL no longer exists, remove it from the sitemap entirely rather than leaving Google to keep hitting a 500. Regenerate the sitemap so it contains only canonical, indexable, 200-OK pages, then resubmit it in Search Console. A lean sitemap focused on your most important content helps Googlebot spend its crawl budget where it counts.

Best practice

Keep your sitemap as a clean priority signal: only URLs that reliably return 200. Monitor server health and the Search Console indexing report on a schedule so a 5XX is caught in hours, not weeks. Reserve 503 with Retry-After for genuine, short-lived downtime, and resolve any persistent 500 before it costs you indexation.

FAQ