How can you temporarily shut down a site without losing your Google ranking?

Why might a temporary shutdown affect your SEO?

When a site becomes inaccessible, Googlebot interprets this unavailability based on the HTTP signals sent by the server. If the crawler detects repeated 404 or 500 errors, it concludes that the pages no longer exist or that the site is faulty.

This interpretation triggers a process of progressive de-indexing: Google removes URLs from its index after several unsuccessful attempts. The problem mainly arises during unannounced or poorly configured maintenance, where the server responds with an inappropriate error code by default.

What is the recommended mechanism by Google for maintenance?

The official solution relies on the HTTP 503 Service Unavailable code, accompanied by a Retry-After header that indicates the estimated duration of unavailability. This signal explicitly informs Googlebot that the interruption is temporary and planned.

When the crawler receives this 503 code with Retry-After, it puts the URLs on hold without de-indexing them. It will automatically return after the specified delay, thereby preserving the ranking and accumulated authority.

How long of a shutdown does Google tolerate without consequences?

Google does not provide an official threshold in hours or days. The essential point is that the Retry-After header must be consistent with the actual duration of maintenance. A maintenance period announced for 2 hours but extended to 48 hours risks triggering partial re-indexing.

In practice, field observations show that a 24 to 48 hour correctly signaled shutdown generates no measurable impact. Beyond 72 hours, even with a clean 503, some ancillary signals (zero traffic, lack of updates) may influence the crawl budget assigned upon return.

• Code 503 + Retry-After: a clear signal for Googlebot that the shutdown is temporary
• Avoid 404/500: these codes trigger progressive de-indexing
• Consistency between announced/real duration: a significant discrepancy can trigger re-evaluation
• Preserved crawl budget: Google does not penalize properly managed maintenance
• Beyond 72 hours: risk of accumulated negative signals (traffic, freshness, zero engagement)

Is this statement consistent with observed practices on the ground?

Tests conducted on client sites confirm that the 503 with Retry-After effectively protects rankings during short shutdowns (less than 48 hours). Positions stabilize as soon as the site is back online, with no measurable drop in the SERPs. This behavior is reproducible across different types of sites (e-commerce, media, B2B).

However, [To be confirmed] the exact tolerance of Google beyond 72 hours remains unclear. Some sites have maintained their ranking after a week in 503, while others have experienced gradual erosion after 4 days. Undocumented variables (domain authority, usual crawl frequency, reliability history) seem to play a role.

What nuances should be applied to this official recommendation?

Google does not mention unplanned shutdowns (server crashes, DDoS attacks, infrastructure issues). In these cases, it is impossible to properly configure a 503 with Retry-After: the site often returns timeouts or random 500 errors. The SEO impact then depends on the speed of coming back online and the crawling frequency.

Another point not addressed: the management of static files (CSS, JS, images). If the site displays a maintenance page but Googlebot cannot access resources, rendering may fail. Google has previously confirmed that blocked resources harm indexing, even if the HTML page is accessible.

In what cases does this rule not apply?

Sites with a constrained crawl budget (millions of pages, complex architecture, low authority) do not always benefit from the same tolerance. If Googlebot only visits twice a week, a 48-hour shutdown may coincide with a crawl attempt, effectively prolonging the perceived unavailability.

Sites under Google News or Discover face stricter rules. These feeds prioritize freshness and availability: downtime, even signaled with a 503, may lead to temporary exclusion from the carousel. Return to these feeds can sometimes take several days after going back online.

What should you concretely do before a planned maintenance?

Setting up a maintenance page with the 503 code and Retry-After header is the top priority. This header should indicate the delay in seconds (e.g., Retry-After: 3600 for 1 hour) or a specific date in HTTP format (e.g., Retry-After: Wed, 21 Oct 2025 07:28:00 GMT).

Test this configuration before going live in a staging environment. Check with the browser's developer tools, and then with a crawler like Screaming Frog or Sitebulb. Ensure that the CDN or reverse proxy does not rewrite the code to 200 or 302.

What mistakes to avoid during the temporary shutdown?

Never use 302 redirects to a maintenance page hosted on a subdomain or different URL. Google may interpret this signal as a content move, triggering a re-evaluation of the original URLs. The 503 must be sent from the canonical URL itself.

Avoid blocking Googlebot access via robots.txt during maintenance. This practice prevents the crawler from seeing the 503 code, forcing it to return later without information on the duration. The result: wasted crawl budget and uncertainty about the site's real status.

How can you verify that the site is correctly protected after coming back online?

Check the Search Console within 24 to 48 hours following the return. Look for an absence of spikes in 5xx or 4xx errors in the coverage report. If Google has correctly interpreted the 503, there should be no abrupt changes in indexed pages.

Conduct a manual complete crawl with a dedicated tool to identify any orphan pages or blocked resources that appeared during maintenance. Confirm that performance has not degraded (Core Web Vitals, server response time): a slow site upon restart may lose ranking even if the shutdown was handled correctly.

• Set up code 503 + Retry-After header with realistic duration
• Test the HTTP response with curl or crawl tools before maintenance
• Ensure that the CDN/proxy does not mask the 503
• Never redirect to a maintenance page on a different URL
• Allow Googlebot to access the site (no robots.txt blocking)
• Monitor Search Console in the 48 hours post-return
• Crawl the site after getting back to identify anomalies or blocked resources
• Validate stability of Core Web Vitals and server response time