Skip to content
Adrythm

Your website

Should we take our website down while we are closed?

The short answer

Almost never. Google recommends keeping the site online with limited functionality, because closing a site even for a few weeks can harm indexing and carries no fixed recovery time. So the instinct to take our website down while we are closed is the one option that says something permanent about something temporary.

Keep the site up. That is the recommendation, and it comes from the company whose index you are worried about.

Google is direct about it: "we recommend that you keep your site online and limit the functionality."

The instinct runs the other way. If you cannot sell, take it down. But a closed shop with the lights on is still findable, and a closed shop with the lights off is a different thing entirely.

Switching off is treated as a bigger event than closing

The distinction that matters is not open against closed. It is reachable against gone.

Google states the consequence of the second: "Completely closing a site even for just a few weeks can have negative consequences on Google's indexing of your site."

It goes further on how long the way back takes: "There's no fixed time for a recovery from a complete removal, and there's no mechanism to speed that up."

Read those two together and the asymmetry is the whole decision. The closure has a date on it. The recovery does not.

Google reserves the full switch-off for a window most owners would find surprisingly short: "This is an extreme measure that should only be taken for a very short period of time (a few days at most), as it will otherwise have significant effects on the website in Search, even when implemented properly."

Note the last clause. Even done correctly, it still costs you. That is unusual language in platform guidance, and it is worth taking at face value.

The web has three different words for not here right now

This is where an owner decision quietly becomes a technical one, and the standard is more precise than any summary of it.

When a browser or a crawler asks your server for a page, the server answers with a status code. RFC 9110, the current standard for how HTTP works, defines three that all sound alike in English and mean very different things.

The temporary one: "The 503 (Service Unavailable) status code indicates that the server is currently unable to handle the request due to a temporary overload or scheduled maintenance, which will likely be alleviated after some delay."

The permanent one: "The 410 (Gone) status code indicates that access to the target resource is no longer available at the origin server and that this condition is likely to be permanent."

And the one that refuses to say: "A 404 status code does not indicate whether this lack of representation is temporary or permanent".

So the vocabulary already exists for exactly the situation you are in. A seasonal closure is scheduled maintenance in everything but name. Turning the site off, or letting pages fall to a generic missing-page response, picks a word that either claims permanence or says nothing at all about when you will be back.

MDN adds the part that makes a 503 useful rather than just correct. It "should be used for temporary conditions and the Retry-After HTTP header should contain the estimated time for the recovery of the service, if possible." And it asks for something a visitor benefits from: "A user-friendly page explaining the problem should be sent along with this response."

That is the difference between a server saying nothing and a server saying back on the fourteenth.

The details that catch people out

Three specific traps, each of which looks sensible until you read the guidance.

A 503 is not free even when used correctly. Google warns that "it's not possible for Google's systems to refresh titles, descriptions, metadata, or structured data included on a website if a page returns a 503 HTTP response status code." So the information shown about you freezes at whatever it said the day you switched over.

Blocking crawler access at the file level is worse, not safer. Google states it plainly: "Don't block your robots.txt file with a 503 HTTP response status code."

And geography is the one almost nobody anticipates. Owners of local businesses sometimes block traffic from outside their area while closed. Google's note: "Google generally crawls from the US. If you block the US, Google Search won't be able to access your site at all." A shop in one country can make itself invisible by blocking another.

On removing products that are out of stock, the answer is no, and the reasoning is about the customer rather than the ranking. Google says it is better to leave the page available and mark the item out of stock, because a removed page tells a shopper nothing about why it is gone.

Slowing the crawler down is a separate lever, with a catch

There is a middle option people reach for, and it is worth knowing what it costs.

You can ask Google to visit less often while you are shut. Google allows it but adds a caution: "though it's not recommended for most cases."

The cost is freshness. In Google's words, "This may have some impact on the freshness of your results in Search." So the change you make on reopening day takes longer to show up, which is precisely the day you want it to be fast.

There is one situation where it is the right call. If crawler traffic is genuinely straining a server you have scaled down for the quiet period, reducing the rate protects the site.

Then comes the part that gets forgotten, and Google says it out loud: "We recommend setting a reminder for yourself to reset the crawl rate once you're ready to go back in business."

Read that as a warning about human nature rather than about software. The setting has no expiry date. Nothing turns it back on for you. A business can reopen fully and quietly stay slow in search for months because one toggle was never reversed.

What to check, in order

Five checks, and the first four are free.

  • Write down the reopening date before choosing a method. The right approach for four days is not the right approach for four months.
  • Disable the cart or the booking form rather than the site. That is the recommended route, and it keeps every page findable.
  • Put the closure in words on the site, with the date you reopen. A visitor who reads it does not need to guess, and neither does anybody quoting you later.
  • Check what your server actually returns for a closed page, rather than what you intended. A page can look closed to a person and look missing to a crawler.
  • Only if the outage must be total and brief, use the temporary status code with a real explanation page.

The arithmetic settles most arguments about this, because the two numbers are not on the same scale. Google's ceiling for a full switch-off is a few days at most. Call it 3 days. Suppose a seasonal business closes for 10 weeks, which is 70 days.

That closure is more than 20 times longer than the maximum window the method is meant for, since 70 divided by 3 is about 23. The figures are an illustration, but the shape is not: for any closure measured in weeks, the full switch-off is being used far outside the range its own guidance describes, and the way back has no published duration.

Working out which of these applies to a specific closure, and checking what the server really returns before anybody trusts it, is part of what we do on websites.

Terms used on this page

Sources

Last reviewed 2026-09-12.

Still have a question this page did not answer?

Ask it on a call. Twenty minutes, a straight answer, and no follow-up sequence if you decide not to work with us.