The correct approach is to return an HTTP 503 (Service Unavailable) status code paired with a Retry-After header during the maintenance window, which explicitly tells Googlebot that the unavailability is temporary and gives it a signal about when to attempt the page again, rather than treating the pages as removed. This preserves indexing and ranking status through the maintenance period because Google interprets a 503 as a transient server-side condition, not a signal to remove pages from the index, as long as the condition doesn’t persist well beyond what a genuine maintenance window would reasonably require.
The mechanism: how Google’s retry logic interprets 503 versus alternatives
Google’s crawling and indexing documentation on HTTP and network errors, along with dedicated guidance on site maintenance, is specific about this pattern: a 503 response is the correct signal for temporary unavailability, and including a Retry-After header (specifying either a delay in seconds or a specific date/time) gives Google an explicit hint about when to retry, rather than leaving it to guess and potentially retry on its own default schedule. Google’s crawlers are documented as respecting this signal and treating repeated 503s within a reasonable, bounded maintenance window as exactly what they claim to be, a temporary condition, rather than escalating to treat the URLs as gone.
This matters because the alternatives Google explicitly warns against produce worse outcomes. Serving a 404 or 410 during maintenance signals permanent removal, prompting Google to begin the process of dropping those URLs from the index, which then requires a full recrawl-and-reindex cycle to recover once the site is back up, a meaningfully worse and slower outcome than a properly signaled temporary condition. Serving a 200 status code with a generic “we’ll be back soon” maintenance page is also a documented risk, because Google can interpret that as the actual content now living at that URL, and if that maintenance page looks sufficiently different from or thinner than the original content it can trigger a soft-404 classification, again risking the page being effectively treated as not really there, which produces the same painful recovery problem as an explicit 404 would.
The risk of over-persisting the 503 state
Google’s guidance does draw a boundary here: while a 503 is correctly interpreted as temporary in the near term, if the condition persists for an extended stretch, well beyond what a genuine maintenance window implies, Google’s systems can begin to treat the sustained errors as indicating a more permanent problem, similar in spirit to how persistent 5xx errors more generally can lead to removal from the index over time. Google hasn’t published a specific, precise “safe” hour or day count at which this shifts; treating a specific number here as a hard guarantee would be fabricating a precision Google hasn’t actually documented. The practically safe approach is keeping the maintenance window as short as the actual work requires and not treating the 503 pattern as a mechanism that tolerates indefinite or repeatedly-extended downtime without consequence.
Why this preserves “crawl equity” specifically
The underlying reason this approach protects a site’s standing is that it avoids resetting the accumulated trust and indexing state Google has built up for those URLs through prior crawls. A 404/410 response effectively tells Google to discard what it knows about that URL’s content and status; recovering afterward means rebuilding that from scratch through fresh crawling and reprocessing. A properly signaled 503 with Retry-After keeps Google’s existing understanding of the page intact and simply pauses the interaction, so once the maintenance window ends and normal responses resume, Google can pick back up largely from where it left off rather than needing to rediscover and reevaluate the URLs as if they were new or altered.
Worked comparison across common maintenance-mode implementations
It helps to walk through how different common implementations actually fare against this mechanism. A load balancer configured to return a genuine 503 with Retry-After: 7200 (two hours) during a planned two-hour maintenance window is the textbook correct pattern: Googlebot receives an unambiguous, specific signal, backs off, and returns after the stated interval to find the site restored, with no meaningful disruption to indexing or ranking for the affected URLs. A team that instead routes maintenance-mode traffic through a CDN rule serving a static “under maintenance” HTML page, but does so at a 200 status code because that’s what the CDN’s default page rule produces without explicit override, creates real risk, because Google’s system may begin processing that thin, generic maintenance page as the actual current content of every URL it applies to, and if enough of those pages look sufficiently different from their normal content, a soft-404 classification effectively achieves the same damaging outcome a deliberate 404 would, despite nobody on the team intending to signal removal.
A third, subtler failure case: a team that correctly returns 503s during the maintenance window but then extends the window repeatedly, a two-hour maintenance event that stretches into eighteen hours due to unrelated deployment problems, without ever adjusting the Retry-After header or communicating the extension. Even though every individual response is technically a correctly-formatted 503, the sustained duration without an updated retry signal pushes the situation toward the territory Google’s broader persistent-5xx guidance warns about, where an extended pattern of errors starts to look less like a bounded, temporary condition and more like a site that’s actually failing, risking a slower, less confident recovery once service actually resumes compared to a cleanly bounded, accurately-signaled maintenance window.
Practical implication
Configure the maintenance mode to return a genuine 503 status code (not just a 200-status page with maintenance-themed content) at the server or CDN/load-balancer level, and include a Retry-After header set to a realistic estimate of when the maintenance will conclude, updating it if the window needs to extend rather than leaving Googlebot to guess. Keep the actual maintenance duration as short as operationally possible, since Google’s tolerance for a 503 pattern is for genuinely temporary conditions, not an open-ended workaround for extended downtime. Avoid the two common missteps: don’t serve 404/410 status codes for temporary maintenance (that signals permanent removal and forces a slow reindexing recovery), and don’t serve a 200-status generic maintenance page in place of the real content (that risks a soft-404 misclassification with a similar recovery cost). After maintenance concludes, spot-check a sample of affected URLs via URL Inspection to confirm Google is recrawling them normally and that indexing status hasn’t drifted during the window.
