Every website is likely to experience downtime at some point. It’s often planned, for routine maintenance or a platform upgrade, but it can also be unplanned, due to things like a server outage or a cyber-attack.

This guide explains how to take your site offline without damaging its organic search performance, and what to check once it’s back online.

Does downtime affect organic search performance?

The effect of downtime on search performance mostly comes down to two things:

  • How long the site is offline
  • How clearly you tell search engines that the outage is temporary.

Google has long said that short outages shouldn’t hurt rankings, as Matt Cutts explained when he led Google’s webspam team. More recently, in a 2024 office hours session, Google confirmed that brief 503 downtime is fine, but serving 503s for an extended period will reduce how often Googlebot crawls your site.

A correct 503 status code tells Google the outage is temporary, so it can keep your URLs in its index rather than treating them as removed. But there are limits. Google’s guidance on pausing a website recommends a 503 for one to two days at most, and while your pages return a 503, Google can’t refresh their titles, descriptions, or structured data.

The best way to protect your rankings is to keep the downtime short and configure it properly, so search engines know your site is only temporarily unavailable.

If you need to close for longer than a couple of days, Google recommends keeping the site online with limited functionality instead. For example, disable the shopping cart and add a banner explaining what’s happening.

How to configure SEO-friendly site downtime

Follow these steps to make your downtime as SEO-friendly as possible.

1. Tell search engines your site is temporarily unavailable

To tell search engines your site is temporarily unavailable, set the HTTP status code to 503 (Service Unavailable). The current HTTP specification, RFC 9110, defines a 503 as the server being temporarily unable to handle requests – for example, because it’s overloaded or down for maintenance – and says the server can use a Retry-After header to indicate how long the delay is likely to be.

Every URL a search engine requests during the downtime should return a 503 status code – except your robots.txt file (see step 4).

Alongside the 503, add a Retry-After response header, which Google recommends setting to a best-effort date or duration.

The value can be either an HTTP date or a number of seconds, like this:

  • Retry-After: Fri, 31 Dec 1999 23:59:59 GMT
  • Retry-After: 120

If you know how long your site will be down, set the Retry-After value to when you expect it to be back online.

If the downtime runs longer than planned, update the value so crawlers don’t come back before you’re ready.

2. Show users a custom maintenance page

Just like a custom 404 page, your 503 page should help users, not just tell them something’s wrong. Explain what’s happening, when you expect to be back, and how to contact you in the meantime.

Keep the page lightweight – Google suggests static HTML with inline CSS – so it doesn’t add load to a server that’s under maintenance.

3. Test your status codes and headers

Google’s old Fetch and Render tool has been retired, so use the live test in Search Console’s URL inspection tool to check that Googlebot receives the 503 status code. Review the returned HTTP response to confirm your Retry-After header is there.

You can also check locally with curl or a similar tool. Running curl -I https://www.example.com/ should return HTTP/1.1 503 Service Unavailable, along with your Retry-After header.

4. Don’t block crawling with your robots.txt file

If your robots.txt file returns a server error such as a 503, Google stops crawling your website altogether. For that reason, it has historically been recommended to serve a 503 on robots.txt during planned maintenance to pause crawling completely.

However, Google’s current advice is not to do this. Its guidance on pausing a website says to keep allowing crawling through robots.txt, because a 503 on that file blocks all crawling. Googlebot then can’t see the 503s on your pages, which are what tell it the downtime is temporary.

Keep your robots.txt file returning a normal 200 status code and let the 503s on your pages do the work.

Don’t block the site with a Disallow rule either. Google warns that a robots.txt file that disallows all crawling may remove your content, and potentially your URLs, from search results. In our experience, it can also slow how quickly your crawl rate recovers once you’re back. The same goes for 403, 404, and 410 status codes or noindex tags, which tell Google pages are gone rather than temporarily unavailable.

5. Check your site is back in business

Once downtime ends and the site is live again, remove the 503 responses and make sure every page returns a normal 200 status code.

Then run a health check with a third-party crawler. Check status codes, indexability, and canonical tags, and look for accidental noindex tags or redirect chains – especially if the maintenance included a platform or template change.

That’s where old code or staging settings most often slip through, and where downtime overlaps with migration work.

6. Monitor errors in Google Search Console

Over the following days, keep an eye on the Page indexing and Crawl stats reports in Google Search Console.

A sustained rise in server (5xx) errors or a spike in 404s suggests that something didn’t come back cleanly. Re-check your redirects, templates, and indexability, not just the maintenance window itself. Our guide to canonical issues in Google Search Console covers the most common follow-up fixes.

Keep it short, and signal it clearly

Planned downtime doesn’t have to cost you rankings. Keep it as short as possible, serve 503s with a Retry-After header, leave your robots.txt file alone, and check everything once you’re back.

If your traffic or indexing does drop afterward, our organic traffic drop audit can help you find out why.