HTTP 503 Service Unavailable

A maintenance page served with `200 OK` tells every automated client that the page was served successfully. Caches store it, link checkers report the URL as working, and search engines may index the maintenance notice in place of the real content.

The same page served with `503` tells them the opposite: nothing useful here, come back. Nothing is cached as canonical, nothing is indexed, and the outage leaves no trace once it ends.

Google's documentation is explicit that 503 is the appropriate response for temporary downtime, and that a site returning it for a short period is not penalised.

The page body can be identical either way. Only the status line changes, and it is the status line that every machine reads.

`Retry-After` accepts either a number of seconds or an HTTP date, and tells the client when it is worth trying again.

A crawler that receives it can schedule the retry rather than guess. Without it, a client applies its own backoff, which is usually more conservative than you would like.

For a planned window, a date is clearer than a duration because it does not drift as the outage continues. For overload, a short duration in seconds is more useful.

The header is advisory. A client is free to ignore it, and many do, so it is a hint rather than a contract.

Hours are unremarkable. Google's guidance treats short-term 503s as a normal signal and resumes crawling afterwards.

Days change the picture. A site returning 503 for an extended period is eventually treated as genuinely unavailable, and its pages start being dropped from the index.

So 503 is a way to fail safely for a defined window, not a way to take a site offline indefinitely. A permanent removal is a different decision, expressed with 410 or by unpublishing properly.

If the outage will be long, serving a reduced but real version of the site is almost always better than serving nothing.

`curl -I https://example.com` during the window prints the status. A maintenance page that answers `HTTP/2 200` is the defect, whatever the page says.

Check the `Retry-After` header in the same output; its absence is not an error but it is a missed opportunity.

Verify that the maintenance rule applies to the whole site, not only the home page. A partial rule leaves half the site serving broken application pages under 200.

Confirm that static assets are covered consistently: a maintenance page that loads a stylesheet through an application server that is down looks worse than a plain one.