503 status code (Service Unavailable)

How it looks

A 503 response has a status line, optionally a Retry-After header and a short HTML body that tells visitors what is going on.

HTTP/1.1 503 Service Unavailable

Retry-After: 3600

Retry-After: Wed, 21 Oct 2026 07:28:00 GMT

Content-Type: text/html; charset=utf-8

In nginx a maintenance switch is return 503; with error_page 503 /maintenance.html;; in Apache a RewriteRule with the [R=503,L] flag does the same job.

How Google handles it

Google's documentation on HTTP status codes puts 503 in the 5xx group: server errors prompt Google's crawlers to slow down temporarily, already indexed URLs are preserved in the index but eventually dropped, and any content sent with a 5xx response is ignored. Once the server responds with 2xx again, Google gradually increases the crawl rate.

The same document notes that the crawl rate decrease is proportionate to the number of URLs returning errors, and that URLs which persistently return a server error are removed from the index. A few hours of 503 is noise; a week is a removal.

The reduce crawl rate page explains the mechanism. When Google's crawling infrastructure sees a significant number of 500, 503 or 429 responses, it reduces the crawl rate for the whole hostname, including URLs that still return content, and raises it again automatically once the errors go away. Google recommends this only for a short period, meaning 1-2 days, and warns that if Googlebot sees these codes on the same URL for multiple days, the URL may be dropped from the index.

That page also documents Retry-After: with a 503 or 429 you can send a delay in seconds or an absolute UTC date and time as a hint for when to retry.

Google's guide on temporarily pausing a website adds practical rules. If you need to disable a site urgently for 1-2 days, return an informational error page with a 503 code. For a longer closure, serve an indexable home page with a 200 code instead. And while a page returns 503, Google cannot refresh its title, description, metadata or structured data.

The robots.txt rule

The one 503 that must never happen is on /robots.txt. According to the pause a website guide, a 503 on robots.txt blocks all crawling. The robots.txt specification spells out what follows: for the first 12 hours Google stops crawling the site while retrying the file, then for up to 30 days it uses the last cached version, and a 503 on the file results in fairly frequent retrying.

So a maintenance rule has to exclude the file. In nginx: location = /robots.txt { try_files $uri =404; } placed before the catch-all 503 block. In Apache, add a RewriteCond %{REQUEST_URI} !^/robots\.txt$ line above the 503 rule. More on the file itself in the entry on robots.txt.

When to use it

• Planned maintenance of a few hours: database migration, server move, deploy with downtime.
• Emergency overload: Google's reduce crawl rate page lists 503 as the way to lower crawler traffic urgently.
• A backend down while the CDN still works: let the edge return 503, not a cached 200 error page.

Do not use 503 as a long-term state. For a shop closed for a season or a site rebuilt over weeks, keep pages on 200 with a notice; Google's pause a website guide recommends limiting functionality rather than taking the site down. Do not use 404, 410 or noindex for a pause either; the same guide says those remove URLs from Search.

Common mistakes

The last one is common with plugins that redirect to /maintenance/; see the entry on HTTP status codes for how 302 is read.

How to check it

With curl, as Google itself recommends in the pause guide, confirm the code locally:

curl -I -X GET "https://www.example.com/"

The first line should read HTTP/1.1 503 Service Unavailable and the headers should include Retry-After. Then test the file that must not be affected:

curl -I https://www.example.com/robots.txt

Expect 200 OK. In browser devtools, the Network tab shows the status of each request; filter by the document type to see the 503 on the page and 200 on robots.txt.

In Search Console, server errors appear in the Pages report as Server error (5xx) and in the Crawl Stats report under crawl responses and host status. Google's Crawl Stats documentation lists 5xx as a "bad response" that causes availability warnings. A spike without a planned window is an outage you did not know about.

The redirect checker shows the status code, headers and response time of up to 10 URLs, so you can verify a 503 with its Retry-After header and the 200 on robots.txt in one run.

How IndexRise monitors it

IndexRise requests every monitored URL once a night and compares the status with the baseline. A series of server errors (5xx) is reported immediately as a critical "4xx or 5xx error" event, without waiting for a second check, because a run of 5xx usually means the whole host is down. Robots.txt gets its own check: if the file returns 5xx or does not respond, the project receives a "robots.txt unavailable" alert, since Google pauses crawling in that case. When the site responds like the baseline again, the event closes itself.