What Is a 503 Error (Service Unavailable)?

503 belongs to the 5xx class of HTTP status codes, the server errors. It is defined today in RFC 9110, "HTTP Semantics", published in June 2022, section 15.6.4. The same document describes the Retry-After header in section 10.2.3: sent with a 503, it says how long the service is expected to be unavailable, either as an HTTP date or as a number of seconds.

The official name is "Service Unavailable". Each server shows the error with its own wording, such as "503 Service Temporarily Unavailable" or "No server is available to handle this request". It is the same response: what counts is the numeric code.

A 503 appears when the server is running but can't respond. The RFC and MDN describe two causes: the server is down for maintenance or it is overloaded. In practice that covers:

• Maintenance or a software update: the CMS or the server returns 503 to every request while it lasts.
• Overload: according to MDN, some applications reject requests with a 503 once they hit their memory, CPU or connection limits, so the server doesn't fail completely.

The RFC adds a note: the existence of 503 doesn't mean an overloaded server has to use it, and some simply refuse the connection.

For Google, a 503 has three documented effects:

• It slows crawling. Google's status code documentation says 5xx errors and 429 make its crawlers temporarily slow down. The guide to reducing crawl rate adds that the drop applies to the whole hostname, including URLs that still return content, and that the rate goes back up on its own once the errors decrease.
• It keeps indexed URLs for a while, but not forever. Google writes that already indexed URLs are preserved in the index, "but eventually dropped". Google gives no fixed deadline.
• It ignores the content of the response. While the 503 lasts, Google can't refresh the page's titles, descriptions, metadata or structured data.

Two cases need to be kept apart, because Google treats them differently.

A 503 on a normal page follows the rules above: slower crawling for the whole host and, if it goes on, lost URLs with no published deadline.

A 503 on the robots.txt file has its own rules. According to Google's robots.txt documentation, if the file exists but can't be fetched, Google stops crawling the site for the first 12 hours and keeps trying to fetch it. For the following 30 days it uses the last good version. For a 503, Google describes "fairly frequent" retrying. These 12-hour and 30-day periods apply only to robots.txt, not to other pages.

A shop updates its CMS for two hours. Meanwhile, every page returns an information page with these headers:

HTTP/1.1 503 Service Unavailable Retry-After: 7200

The value 7200 is in seconds, so two hours. The robots.txt keeps answering with 200. Once the update is done, the pages return 200 again and Google raises its crawl rate again.

Another case: a campaign drives a traffic spike, the server hits its connection limit and for a few minutes answers part of the requests with 503. Google slows crawling of that host until the server responds again.

To check the code of a URL, a request from the terminal is enough, as Google's own guide shows: curl -I -X GET "https://www.example.com/". The first line of the response shows the code and, if present, the Retry-After header.

In Google Search Console, the Page indexing report groups these URLs under "Server error (5xx)". Google warns that they can be transient: a live test in URL Inspection may succeed even though Google's crawl failed earlier.

For a planned outage, 503 is the code the standard provides: it says the problem is temporary and lets you say when to come back. It is better than a notice page with 200, which a crawler sees as a normal page with that text, and better than a 404, which says the page doesn't exist. With Retry-After the server also gives a concrete estimate.

The drawbacks are those of any 5xx: crawling slows for the whole host, Google doesn't refresh titles or structured data and, if the error goes on, URLs can drop out of the index. A 503 is meant for hours or a day or two, not as a permanent state.

Source: RFC 9110 (June 2022), sections 15.6.1, 15.6.3 and 15.6.4; MDN, "503 Service Unavailable" (429); Google's status code documentation (accessed 11.11.2026).

When crawling, Google treats 500, 502 and 503 the same way, and it counts 429 as a server error too. The difference between them lies in the standard and in what the reader of the response understands, not in different treatment in the index.

Deadlines circulate for 503 that Google's sources don't back up. Google doesn't publish how many days it tolerates a 503 before removing a URL. What it does write are two different things. One is a recommended duration: to slow crawling on purpose, return 5xx or 429 for "a couple of hours, or 1-2 days", and disable a whole site only for "a few days at most". The other is a risk with no date attached: indexed URLs are preserved, "but eventually dropped", and if Googlebot sees these codes on the same URL for multiple days, the URL may be dropped from the index. The one or two days are therefore not a removal deadline. Figures like "one week" or "two weeks" don't appear in its documentation either.

In Google's 2011 blog post on planned downtime, Google recommended 503 over 404 or 200 because it signals that the outage is temporary; the current status code documentation, on the other hand, describes 500, 502 and 503 with the same effect on crawling and indexing. So 503 is the right code for maintenance according to the standard, but it doesn't protect the index any better than a 500.

The same goes for Retry-After. Google has named the header in its guide on reducing crawl rate since 6 October 2026, noting that support wasn't new. No source says whether its crawlers evaluate it or wait for the time given.

• Decide whether the outage fits into hours or a day or two. If it will take longer, use an indexable home page with 200 instead of a 503.
• Set up the server or the maintenance mode so that pages return 503, not 200 or 404.
• Add Retry-After with a date or the estimated number of seconds.
• Keep robots.txt out of the 503: it should keep answering with 200.
• Serve a static, lightweight notice page.
• Check with curl that the response is 503 and carries the header.
• When you're done, switch back to 200 and check the Page indexing report and crawl stats in Search Console.

• Use 503 or 429 to slow Googlebot down for a short time; Google advises against 403 and 404 for this.
• Keep the notice short and static, so it doesn't add load to a struggling server.

• Returning 503 for robots.txt: Google stops crawling the whole site.
• Leaving maintenance mode switched on for days or weeks.
• Showing the maintenance notice with a 200 code: to Google it is a normal page with that text.
• Assuming a 503 keeps URLs in the index with no time limit.

This entry was written in November 2026 with AI assistance. The facts come from RFC 9110, Google's documentation on status codes, crawl rate, robots.txt and disabling a site, Google's 2011 blog post, and MDN. It was reviewed before publication and contains no client data.