Maintenance page returning 200

Search engines index the maintenance notice as the page's content, which is what puts a maintenance message into search results for a brand query.

If the window is long enough for many pages to be re-crawled, a large share of the site can be replaced in the index by the same notice.

Duplicate-content handling then groups those pages together, because they are genuinely identical.

Caches store the notice with whatever lifetime the response declares, so visitors keep seeing it after the site returns.

Uptime monitoring configured on status alone reports everything as fine, which is the opposite of useful during an incident.

The status says the service is temporarily unavailable, which crawlers are documented to handle by coming back rather than by re-indexing.

Retry-After tells them roughly when, which turns a guess into a schedule.

Caches do not store a 503 by default, so the notice does not outlive the window.

Monitoring sees a failure, which is what you want during planned work as much as during an incident.

The page itself is unchanged: visitors see the same notice, because the status is for machines and the body is for people.

A crawler's timing is not yours. A ten-minute window that coincides with a crawl of your most important page is enough.

Recovery is not immediate either: a page dropped or replaced in an index takes days to return after the site does.

The cost of doing it correctly is a status code, which is usually one line in whichever layer serves the maintenance page.

Which makes the trade lopsided enough that there is no window short enough to justify the wrong status.

At the edge or the load balancer, so the maintenance page is served even when the application is entirely down.

A maintenance page served by the application only works while the application works, which is not the case you are planning for.

Allow-list your own addresses so the team can reach the real site while visitors see the notice.

Keep the page static and self-contained, without references to assets that may themselves be unavailable.

Include a genuine estimate and a place to check for updates, which is what a status page exists for.

Redirecting every page to a maintenance URL, which tells crawlers the content moved there permanently or temporarily depending on the code used.

Serving a 500 instead, which says the server failed rather than that it is deliberately unavailable.

Serving a 503 with no Retry-After, which is valid and leaves every client guessing.

Returning 200 for missing pages generally, which is the same category of mistake outside a maintenance window.

In each case the body is right and the status is a statement to machines that contradicts it.

`curl -I https://example.com` during the window and read the status line — it should say 503.

Confirm a Retry-After header is present, in seconds or as an HTTP date.

Check a deep page as well as the home page, since a rule applied only at the root is common.

Confirm the response is not cacheable, so the notice does not outlive the window.

Test the configuration before you need it, which for a planned window means rehearsing rather than improvising.

`availability.maintenance_page` detects a maintenance page and reports the status it was served with.

`availability.status_classification` groups the status codes encountered, which is what surfaces a 200 where a failure status belongs.

`availability.error_pages` covers the neighbouring case of an error page served with a success status outside a maintenance window.

`seo.noindex` and `seo.canonical` are read alongside, since a maintenance page that is indexable is what makes the status consequential.

`performance.cache_control` reports the caching directives, which decide whether the notice outlives the window.