Does Website Downtime Hurt Google Rankings?

Outages are one of the most common causes of drops that get blamed on algorithm updates. The site went down, traffic fell a few days later, and nobody connected the two.

The rules are simple once you know them. Most of the damage comes from returning the wrong kind of error, not from the downtime itself.

How long is too long

Downtime	What usually happens
A few hours	Nothing lasting. Google retries and carries on
One to two days	Usually fine with a 503 status. Crawling slows, pages stay indexed
Several days	Pages can start dropping out of the index
Weeks	Large parts of the site may be removed and need recrawling to return

Google’s own guidance puts the comfortable limit at about two days. It recommends a 503 for urgent closures of one to two days and warns against serving 503 for much longer than that.

What Google does with server errors

• It slows crawling across the whole site, to avoid making a struggling server worse.
• It ignores the content of any page returned with a server error.
• It keeps indexed pages at first, then drops them if the errors persist.
• It treats a lasting 503 as a sign that the server may be gone for good.

The robots.txt trap

This is the one that catches experienced teams. Under Google’s robots.txt rules, a server error on that single file is treated as if the whole site were blocked.

1. For up to twelve hours, Google stops crawling the entire site while it retries.
2. After that, for up to thirty days, it uses the last copy of robots.txt it saved.
3. If errors continue for a long period, Google’s Gary Illyes has warned the site can drop out of results, even when every other page works.

Many maintenance mode plugins return 503 for every URL, robots.txt included. Check yours before you need it. The fix is to exclude robots.txt so it always returns 200 with its normal rules.

How to take a site offline properly

1. Return 503 Service Unavailable for pages, with a Retry-After header giving a realistic estimate.
2. Keep robots.txt returning 200 with its normal rules.
3. Show visitors a short notice saying when you expect to be back.
4. Keep it as short as you can, and well under two days.

What not to do

• Do not return 404 or 410. Those say the pages are gone, and Google removes them.
• Do not return a normal page that says the site is down. Google may index the notice in place of your content.
• Do not disallow everything in robots.txt as a way of pausing crawling.
• Do not switch on a CDN challenge page that Googlebot cannot pass, even briefly.

Test it before you need it

Most maintenance mistakes are only discovered during the maintenance. Five minutes of testing on a quiet day avoids that.

1. Switch maintenance mode on on a staging copy, or briefly at a quiet hour.
2. Check the status code of a normal page with any header checker. It should say 503, not 200.
3. Check robots.txt separately. It should return 200 with your usual rules.
4. Switch it off and confirm both return to normal.

Moving to a new host

Hosting moves cause more quiet downtime than any outage. Address changes spread gradually, so for a while some visitors and some crawlers still reach the old server.

• Keep the old server running with the full site until traffic to it stops.
• Lower the DNS time to live a day or two before the move, so the change spreads faster.
• Watch Crawl Stats for a week afterwards for errors or a fall in crawling.

Cancelling the old hosting on moving day is the classic mistake. Give it at least a few days of overlap.

Outages you might not know about

Not every outage is visible to you. Your site can work perfectly in a browser while Googlebot is refused.

• Firewall and bot protection rules that treat Googlebot as an attacker.
• Rate limiting that answers heavy crawling with 429 errors.
• Hosting limits that fail under load at the times Google crawls most.

The host status section of Crawl Stats in Search Console shows these when your own checks do not. Drops with no matching update are covered in rankings dropped with no Google update.

After an outage: did it hurt you?

1. Compare the dates. A drop that starts during or just after the outage points here.
2. Check the Pages report for a rise in server errors or pages no longer indexed.
3. Check Crawl Stats for the dip in crawling and its recovery.

The good news is that this kind of loss usually reverses on its own once the site is stable and Google crawls it again. Nothing was judged, so nothing needs to be reassessed. Speeding up the recrawl is covered in how to get Google to recrawl your fixed pages.