A 503 means "the server is up but isn't handling requests right now — try again later." It is the correct status code for planned maintenance and overload. Always pair it with a Retry-After header so Googlebot and other clients know when to retry. Returning…
HTTP 503 Service Unavailable is the "we're temporarily down, please try again later" status code. Unlike 500 (something crashed) or 502 (the upstream is unreachable), 503 is deliberately a soft signal: the server is up, but it has chosen not to serve this request right now. The expected use cases are planned maintenance, overload protection, rate limiting, and circuit breakers. Critically, a well-behaved 503 includes a Retry-After header telling clients (and search engine crawlers) when to come back — and Google specifically respects this for maintenance windows.
When done correctly, almost no SEO impact. Google explicitly honours 503 + Retry-After for maintenance up to a few hours — pages stay indexed, crawl rate is preserved. When done wrong, severe: 503s without Retry-After are treated like generic server errors; 503s lasting more than a day or two cause deindexing; serving a maintenance page with 200 OK can pollute your index with duplicate "we'll be right back" pages. The correct pattern is always 503 + Retry-After + a useful HTML body.
LemWatch can be told about your maintenance windows so we don't fire false-positive alerts for an expected 503. We also detect when a Retry-After is missing — a frequent oversight that costs you Google's "this is just maintenance" goodwill.
HTTP 503 was defined in HTTP/1.0 (RFC 1945, 1996) and reinforced in HTTP/1.1 with explicit guidance to include a Retry-After header. Google publicly documented in 2011 that Googlebot honours 503 + Retry-After for maintenance: as long as the 503 lasts less than a few hours and the Retry-After is reasonable, the affected pages stay indexed and the crawl rate isn't penalised.
HTTP 503 Service Unavailable means the server is temporarily unable to handle the request. It implies the situation is short-term and recoverable — maintenance, overload, or rate limiting — as opposed to 500 (something crashed) or 404 (the resource doesn't exist).
It depends on the cause. For maintenance: wait for the window to end. For overload: scale the bottleneck (more workers, bigger DB pool, caching). For rate limiting: slow down the client, respect the Retry-After header, request a quota increase. Check the server's logs and load metrics to identify which case you're in.
Done right, no. Google honours 503 with a Retry-After header for maintenance — pages stay indexed and crawl rate is preserved. Done wrong (no Retry-After, or 503s lasting days), yes — affected pages get deindexed and crawl rate drops sitewide.
A response header that tells the client how long to wait before retrying the request. It can be a number of seconds (Retry-After: 3600 = 1 hour) or an HTTP date (Retry-After: Wed, 21 Oct 2024 07:28:00 GMT). Google, Bing, and well-written API clients all respect it.
500 Internal Server Error means "we crashed, we don't know why." 503 Service Unavailable means "we're intentionally not serving right now, come back later." 503 is a controlled response; 500 is an uncontrolled failure.
Yes — always. Returning 200 with a "we'll be right back" page is one of the most common SEO mistakes: Google may index that page as your homepage, and you lose visibility on the real page until the next crawl. 503 + Retry-After is the correct pattern.
Google publicly says up to about a day or two with a reasonable Retry-After is fine. Beyond that, affected pages start getting deindexed and crawl rate drops. For longer planned outages, communicate publicly and consider a holding page on a separate URL.
Almost always overload: too many requests competing for too few worker processes, database connections, or memory. Check your server's load metrics during the 503 spikes — they'll usually correlate with traffic peaks, slow database queries, or insufficient autoscaling.