How Downtime Affects SEO: What Googlebot Actually Does

Every site goes down sometimes, and most owners worry about the same thing: will Google drop my pages? The short answer is that a brief outage is not an SEO disaster, but a long or repeated one can be, and some kinds of "downtime" (a broken robots.txt, a maintenance page served with 200 OK) do more damage than a clean error. This article explains what Googlebot does when it meets errors, based on Google's own public documentation, and how to run maintenance and monitoring so search visibility survives.

What Googlebot sees when your site is down

From a crawler's point of view, "down" is not one thing. Googlebot may get any of these:

• A 5xx status code (500, 502, 503, 504) — the server answered but said it cannot handle the request.
• A 429 Too Many Requests — the server is asking clients to slow down.
• A timeout or connection failure — nothing answered at all.
• A DNS failure — the hostname did not resolve, so Googlebot never reached your server.
• A 200 OK with the wrong content — a maintenance page, an error message rendered by the app, or an empty template.

The first four are honest signals that something is temporarily wrong. The last one is the dangerous case, because to a crawler it looks like your page's content has genuinely changed. If you want a refresher on what each code means, see our guide to understanding HTTP status codes.

Short outages: Google slows down, it does not delete

Google's documentation on how HTTP status codes affect Search states that 5xx and 429 responses cause its crawlers to temporarily slow down crawling of the site. Content that is already indexed is kept for the time being. Google's guide on reducing Googlebot's crawl rate goes further: it describes returning 500, 503 or 429 as an emergency way to make Googlebot back off, and explicitly warns against doing this for more than a day or two.

So for a typical incident of a few minutes to a few hours, the realistic effects are:

• Googlebot crawls fewer URLs for a while, so new or updated pages may be picked up later than usual.
• Pages already in the index stay there.
• Crawling returns to normal once the server responds successfully again. Google does not publish a fixed timeline for that recovery.

Network-level failures (timeouts, refused connections, DNS errors) are reported separately in Search Console, but the practical behavior Google describes is similar: fewer crawl attempts while the host looks unhealthy.

Prolonged outages: when pages start to drop

The same Google documentation is clear about the other side: if the server keeps returning errors, URLs that persistently fail are eventually removed from the index. Google does not publish an exact threshold in hours, and you should be skeptical of anyone who claims one. The guidance that does exist points in one direction — errors lasting more than a couple of days put indexed pages at real risk, and the longer the problem persists, the more pages are affected.

Repeated short outages are a quieter version of the same problem. Each one makes Googlebot back off again, so a site that flaps several times a day can spend much of its time being crawled cautiously. If your site has this pattern, read about detecting flapping websites; fixing the root cause matters more than any single long outage.

The robots.txt trap

Your robots.txt file deserves special attention. According to Google's robots.txt specification:

• If robots.txt returns a 4xx (except 429), Google treats it as if no robots.txt exists — everything may be crawled.
• If robots.txt returns a 5xx or 429, Google temporarily treats the whole site as disallowed and stops crawling it until it gets a non-error response.
• If robots.txt stays unreachable for a long period (Google's documentation says more than 30 days), Google falls back to the last cached copy, or assumes no restrictions if it has none.
• Google generally caches robots.txt for up to 24 hours, so a short blip may not be noticed at all.

The practical lesson: a misconfigured server that returns 500 for /robots.txt while the rest of the site works fine can halt crawling of the entire domain. This happens after framework upgrades, CDN rule changes or permission mistakes, and nobody notices because the homepage looks normal. Monitor /robots.txt as its own URL.

The worst case: a maintenance page that returns 200

A "We'll be right back" page served with status 200 OK tells Google that the content of your URL is now "We'll be right back". If Googlebot recrawls important pages during that window, it can index that text, or classify the pages as soft 404s. That is a content problem, not an availability problem, and it recovers only after the pages are recrawled with real content.

Two common culprits: CMS maintenance plugins that render a styled page with 200, and single-page apps that show an error component while the HTML shell still returns 200. Check what your maintenance mode actually returns before you need it:

curl -sI https://example.com/some-page | head -n 5

You want to see HTTP/1.1 503 Service Unavailable (or HTTP/2 503) and ideally a Retry-After header.

How to run planned maintenance SEO-safely

Google's long-standing advice for planned downtime is to return 503 Service Unavailable rather than 200 or 404. The HTTP standard also defines a Retry-After header that tells clients when to try again. Google's older guidance on planned downtime recommended sending it; treat it as a hint that crawlers may use, not a guarantee of when Googlebot will return.

nginx: a switchable 503 maintenance mode

server {
    # ... your existing listen/server_name/ssl lines ...

    error_page 503 @maintenance;

    location @maintenance {
        root /var/www/maintenance;
        rewrite ^ /maintenance.html break;
        add_header Retry-After 3600 always;
    }

    location = /robots.txt {
        # keep robots.txt answering 200 during maintenance
        try_files $uri =404;
    }

    location / {
        if (-f /var/www/maintenance/ON) {
            return 503;
        }
        # ... your normal try_files / proxy_pass ...
    }
}

Enable maintenance with touch /var/www/maintenance/ON and disable it with rm /var/www/maintenance/ON — no reload needed. Keeping robots.txt reachable is a judgment call: a 503 on robots.txt pauses crawling entirely, which is harmless for a short window, but you do not want it to persist if maintenance runs long.

Framework and CMS shortcuts

• Laravel: php artisan down --retry=3600 returns 503 with a Retry-After header; php artisan up ends it.
• WordPress: the built-in maintenance mode used during core and plugin updates returns 503. Third-party "coming soon" plugins vary — test them with curl.
• Load balancers and CDNs: if you serve a maintenance page from the edge, make sure the status code is 503, not 200.

Timing rules of thumb

• Schedule maintenance for your lowest-traffic hours; Search Console's Crawl Stats report shows when Googlebot is busiest on your site.
• Keep 503 windows as short as possible — hours, not days. Google's warning about 1–2 days applies here too.
• For a multi-day migration, keep a read-only version of the site up instead of a long 503.

How to tell if an outage affected crawling

After an incident, check these in Google Search Console:

1. Settings → Crawl stats. Look at total crawl requests around the incident and the breakdown by response. The Host status section flags problems with robots.txt fetching, DNS resolution and server connectivity.
2. Pages (indexing) report. Watch for a rise in "Server error (5xx)" or "Soft 404" in the days after.
3. URL Inspection. Inspect a key URL and request indexing once it serves correctly again; this does not guarantee anything, but it helps Google notice that the page is back.

If crawl requests dipped and then recovered within a few days, no action is needed.

Monitoring that protects your rankings

You cannot fix an outage you do not know about, and Google may be the first visitor to notice one at 3 a.m. Good monitoring for SEO purposes covers more than "is the homepage up":

The keyword check is what catches the "200 with the wrong content" case: if a text that should always be on the page (a product name, a footer string) disappears, you get an alert even though the status code looks healthy. Our article on keyword monitoring for pages that return 200 OK covers how to pick a good keyword. And when you schedule maintenance, use maintenance windows so planned 503s do not page your team.

FAQ

Will one hour of downtime hurt my rankings?

Based on Google's documentation, a one-hour outage should cause at most a temporary slowdown in crawling; indexed pages are kept. Rankings are not something Google documents as reacting to a single short outage.

Should I return 503 or 500 during an outage?

For planned maintenance, return 503, ideally with Retry-After. For unplanned failures, whatever your server returns is what Google sees; both are treated as server errors, so focus on restoring service fast.

Is uptime a Google ranking factor?

Google has not said that uptime percentage is a ranking factor. What it does document is the mechanism: errors reduce crawling, and persistent errors lead to URLs being dropped from the index.

Key takeaways

• Short 5xx outages make Googlebot crawl less for a while; indexed pages are kept.
• Errors lasting more than a day or two put indexed URLs at risk of removal.
• A 5xx on robots.txt stops crawling of the whole site — monitor it separately.
• Maintenance pages must return 503, not 200; add Retry-After and keep the window short.
• Use keyword checks to catch error pages that return 200.
• After an incident, review Crawl stats and the indexing report in Search Console.

Uptime Monitor checks your pages as often as every minute, alerts you by email, Telegram, Slack, Discord or webhook, and records a cause code for each failure (server_5xx, timeout, dns_error, keyword_missing and more), so you know within minutes whether Googlebot is hitting errors too. The free Starter plan covers one site with checks every five minutes — enough to watch your homepage or robots.txt. Create a free account to start.