Website Downtime and SEO: What Outages Do to Rankings

Short answer: a short outage of minutes or a few hours rarely has a lasting effect on rankings, because search engines expect occasional errors and simply try again later. Problems start when a site returns server errors for days, when maintenance pages are served with a 200 or 404 status, or when robots.txt itself becomes unreachable. For planned maintenance, return 503 Service Unavailable with a Retry-After header, keep it short, and monitor so you know about unplanned outages before search engines do.

What search engines see when your site is down

“Down” covers several different situations, and each looks different to a crawler:

• Server errors (5xx): the server is reachable but fails to produce the page, for example a 500 from a broken plugin or a 503 during overload.
• Timeouts and connection failures: the server does not answer at all, or too slowly.
• DNS failures: the domain name does not resolve, often after an expired domain, a misconfigured DNS change or a provider outage.
• Blocked crawlers: the site works for people but a firewall, bot protection or rate limit rejects search engine crawlers.
• Partial outages: the home page works, but a template, a database table or a region fails, so only some pages error.

Search engines treat all of these as signals that the site is temporarily unable to serve content. They slow down crawling to avoid adding load and retry later. The standard meaning of 503 and its companion header is documented on MDN’s 503 reference.

How long is too long?

Search engines do not publish exact thresholds, and behaviour varies by site. From Google’s public guidance and common experience, a reasonable way to think about it is:

Pages that drop out because of prolonged errors usually come back once they work again and are recrawled, but that can take days or weeks, and rankings may take time to settle. Prevention is far cheaper than recovery.

Two other factors change the picture. First, visitors: even if rankings survive a day-long outage, every searcher who clicks during that time sees an error and may not come back, and some will choose a competitor in the same results. Second, frequency: a site that goes down for an hour every few days sends a pattern of unreliability. Search engines may crawl it more cautiously, and new content can take longer to be picked up. Repeated short outages deserve the same attention as a single long one, because the underlying cause, usually hosting capacity or an unstable plugin, tends to get worse rather than better.

The robots.txt trap

One file deserves special attention. Before crawling a site, Google requests robots.txt to learn what it may crawl. If robots.txt returns a server error, Google cannot know which URLs are allowed, so it pauses crawling of the whole site rather than risk crawling blocked pages. A site whose pages work perfectly can therefore stop being crawled because of one failing file.

A missing robots.txt that returns 404 is fine: search engines treat that as permission to crawl everything. The problem is specifically a 5xx or timeout on that URL. Check that robots.txt is served by the same reliable setup as your pages, and that no firewall rule or maintenance mode blocks it. Our guide to robots.txt for SEO covers what the file should contain.

Planned maintenance: the right way to go offline

When you have to take a site offline on purpose, for a migration, database upgrade or major deployment, how you do it matters more than how long:

1. Return 503 for every page, not 200. A maintenance page served with 200 tells search engines that your content has been replaced by “We’ll be back soon”, and that text can end up indexed or trigger soft 404 reports.
2. Add a Retry-After header with the expected duration in seconds or a date, such as Retry-After: 3600. It is a hint, not a command, but it communicates intent clearly. The Retry-After reference shows both formats.
3. Never use 404 or 410 during maintenance. Those say the page is gone, which is the opposite of what you mean.
4. Do not change robots.txt to disallow everything. Blocking crawling does not protect rankings and can cause more confusion when it is left in place by mistake.
5. Keep it short. Schedule maintenance for low-traffic hours in your main markets, and aim for hours, not days.
6. Serve a static copy if you can. For long migrations, a read-only version of the site is better than any error page.

Many maintenance plugins and hosting control panels send 503 correctly, but some send 200. Check with curl -I on a few URLs before relying on one. Our guide to HTTP status codes for SEO explains the difference each code makes.

Partial outages and hidden errors

Full outages are noticed quickly. Partial ones can run for weeks unnoticed because the home page still loads:

• A plugin update breaks one template, so all product pages return 500 while blog posts work.
• A database table grows slow, and category pages time out under crawl load but not for a single visitor.
• A CDN region fails, so visitors and crawlers from some locations get errors.
• Bot protection starts challenging or blocking search engine crawlers after a configuration change.
• Error pages return 200 with an error message, hiding the problem from monitoring and creating soft 404s.

These are exactly the cases where a crawl of the whole site finds what spot checks miss. If blocked bots are a suspicion, our article on checking whether a CDN or firewall blocks crawlers walks through the tests.

Monitoring so you hear about outages first

The worst outages are the ones you learn about from customers or from a traffic drop a week later. A basic monitoring setup is inexpensive:

• Uptime monitoring that requests a few key URLs every minute or few minutes and alerts you by e-mail or message. Include a deep page, not only the home page, and robots.txt.
• Status code checks per template, so a failing product or category template is caught even when the home page works.
• Server error logs with alerts when 5xx responses rise above a normal level.
• Search Console Crawl Stats host status, which shows robots.txt, DNS and connectivity problems Googlebot met. Our walkthrough of the Crawl Stats report explains how to read it.
• Domain and certificate expiry reminders, because expired domains and TLS certificates cause some of the most avoidable outages.

Recovering after an outage

Once the site works again, a short checklist speeds up recovery:

1. Confirm that key pages, robots.txt and XML sitemaps return 200 with the right content.
2. Check Crawl Stats and server logs over the next days to see that crawling returns to its usual level.
3. Use URL Inspection on a few important pages and request indexing if they dropped out.
4. Resubmit sitemaps if the outage was long, so search engines see the full set of URLs again.
5. Compare Search Console performance before and after, allowing a few weeks for rankings to settle.
6. Write down the cause and the fix, and add a monitor for that failure mode.

Avoid rushed changes during recovery, such as redirects or URL changes made to “help”. They add new variables just as search engines are re-evaluating the site.

How an audit helps after changes

Site SEO AI Audit crawls every page like a search engine and reports status codes, server response time on every page, redirect chains and broken links, so a template returning errors or a slow section stands out by its pattern. Pro plans include weekly audits and e-mail alerts, which help catch partial problems between releases. You can also run a free audit after a deployment to confirm nothing broke.

Related reading

• Technical SEO Monitoring: Catch Problems Before Traffic Drops
• Soft 404 Errors: What They Are and How to Fix Them
• Server Response Time and TTFB: How to Speed Up Your Server

The bottom line

Brief outages are normal and forgiven. Long outages, maintenance pages served with the wrong status code and an unreachable robots.txt are what damage search visibility. Use 503 with Retry-After for planned downtime, keep it short, monitor key templates and robots.txt, and follow a calm recovery checklist when something breaks.

FAQ

Will a few hours of downtime hurt my rankings?

Usually not. Search engines expect occasional errors and retry later. Rankings are normally unaffected by short outages, especially when the site returns 503 rather than a broken or empty page.

What status code should a maintenance page use?

Use 503 Service Unavailable, ideally with a Retry-After header. Avoid 200, which can get the maintenance text indexed, and avoid 404 or 410, which say the pages are gone.

How long can a site be down before pages drop from Google?

There is no fixed number. Pages that keep returning errors for several days can start to drop out, while a few hours usually has no effect. The longer the outage, the longer recovery takes.

Why did Google stop crawling when only robots.txt was failing?

If robots.txt returns a server error, Google cannot tell which URLs are allowed, so it pauses crawling instead of risking blocked pages. A missing robots.txt returning 404 does not cause this.

How can I get pages back into the index after an outage?

Make sure pages return 200 again, resubmit sitemaps if the outage was long, and request indexing for key URLs in Search Console. Most pages return as they are recrawled.