Website Downtime and SEO: What an Outage Actually Costs

The honest answer to "does downtime hurt SEO" is: it depends entirely on how long the server stays down and what it says while it's down. A five-minute blip during a deploy is invisible to Google. A server that returns errors for three days is a different problem, and a maintenance page that quietly returns a 200 status code is worse than either, because it tells Google the broken page is the real page.

Most of the anxiety around downtime and SEO comes from treating "down" as one event, when Google actually treats it as a pattern it measures over time. Understanding that pattern is what lets you take a site down for maintenance on purpose without paying for it in rankings.

What Googlebot Does the Moment It Hits a 5xx

Googlebot fetches a URL the same way any HTTP client does, and a 5xx response (500 Internal Server Error, 502 Bad Gateway, 503 Service Unavailable, 504 Gateway Timeout) tells it the server, not the page, is the problem. Googlebot's crawling infrastructure is built to expect this: servers restart, deploys happen, traffic spikes overload a database connection pool. A single failed fetch does not get treated as evidence the page is gone.

What it does trigger is a change in crawl behavior, not an indexing decision. Google's crawlers reduce the rate at which they hit a server that is returning errors, specifically to avoid making a struggling server's problem worse. This is the same mechanism that kicks in when a server responds slowly rather than erroring outright: Googlebot treats sluggish responses and error responses as related signals that a host is under strain, and backs off the request rate accordingly. That backoff is itself a minor cost, separate from any indexing effect, because a lower crawl rate means changes to your other pages get discovered more slowly for as long as the throttling lasts.

• 500 / 502 / 504: server-side failure, no information about duration
• 503: explicitly means "temporarily unavailable," and can carry a Retry-After header
• Connection timeout / refused: treated like a 5xx for crawl-rate purposes, but logged differently on your end

The Real Timeline: From "Ignored" to "Dropped From the Index"

There is no single published number of hours or days after which a page gets removed, and any article that gives you one as a hard rule is inventing precision Google has never committed to. What is consistent, across Google's own guidance and how the crawling system is described, is the shape of the curve rather than a fixed point on it.

A short outage, measured in minutes to a few hours, is generally invisible: Googlebot retries later, gets a normal response, and moves on. There is no meaningful gap in the index because Google is still serving the last successfully crawled version of your pages to searchers; a failed crawl attempt does not erase what's already indexed.

An outage that stretches across a full day or more starts to behave differently. Repeated failures on the same URLs get recorded, crawl frequency for the affected host drops further, and if the pattern continues Google's systems start to treat the URL similarly to a page that's returned 404s repeatedly: a candidate for removal, not because someone made that decision, but because the URL has now failed enough consecutive checks that keeping it in the index stops making sense. Once removal happens, getting the URL back is not instant even after the server is fixed: Google has to recrawl it, confirm it's healthy again, and restore it to the index, which happens on Google's own schedule rather than yours.

The practical takeaway is that duration is the variable that matters, not the existence of an error. A host that flaps between healthy and erroring for a week does more damage than one that is cleanly down for six hours and then reliably up.

503, 500, or a "Back Soon" Page Served as 200: Pick the Right One

When you take a site down for planned maintenance, the status code you serve is the actual decision, not an implementation detail. There are three common approaches, and they are not interchangeable.

Serving a proper 503 Service Unavailable is the correct choice for planned maintenance. It tells any crawler, explicitly, that this is temporary: the page isn't gone, isn't broken content, it's just not available right now. Pair it with a Retry-After header set to a realistic number of seconds or a specific time, and Googlebot has a concrete signal for when to come back rather than guessing.

A bare 500 communicates that something failed, but not that it's expected or temporary. It works from a "don't index broken content" standpoint, but it gives Google no information about whether to expect this URL to recover, so it's a weaker signal than a deliberate 503 for a maintenance window you control.

The mistake that actually costs rankings is the third option: a "we'll be back soon" page that returns HTTP 200. This is common because it's the default behavior of a lot of maintenance-mode plugins and reverse-proxy configs that swap the content but forget the status code. A 200 tells Google this is the real, successful response for that URL. If every URL on the site returns the same maintenance message with a 200 status, Google can end up recrawling and reindexing that generic maintenance text as the actual content of many different pages at once, which looks like the site has replaced dozens or hundreds of unique pages with duplicate boilerplate. That is a self-inflicted content problem layered on top of the outage itself, and it persists until those pages get recrawled with real content again.

Setting Up a Maintenance Response That Doesn't Cost You Anything

For a planned maintenance window, the mechanics are straightforward once the status code is right.

Configure the server or load balancer to return 503 for the URLs actually affected, with a Retry-After header carrying your best honest estimate. If the work runs long, update Retry-After rather than leaving a stale value; Googlebot pays attention to it as a hint, not a guarantee, but a wildly wrong one erodes the value of using it at all.

Avoid the tempting shortcut of a site-wide 301 or 302 redirect to a single "under maintenance" URL during the window. Mass-redirecting every URL to one target creates the same everything-is-the-same-page problem as the 200 maintenance page, just via a different mechanism, and redirects are stickier for crawlers to unwind afterward than a temporary status code that resolves itself the moment the real page responds normally again.

If only part of the site is affected, for example checkout and account pages are down while the blog and marketing pages are fine, scope the 503 to those specific paths only. Serving a blanket outage response for the entire site when only a subsystem is broken throttles crawling and risks the maintenance-page problem across pages that never needed to be touched.

• Return 503, not 200, for anything genuinely unavailable
• Set Retry-After to a real estimate and update it if the window extends
• Scope the response to the affected paths, not the whole site, when the outage is partial
• Don't mass-redirect every URL to one maintenance page

Reading the 5xx Bucket in Search Console Correctly

Search Console's Crawl Stats report groups crawl responses into buckets by status: OK, redirect, not found, and server error among others. That server-error bucket lumps every 5xx variant together into one count, and that's the limitation worth knowing before you use it to diagnose anything: a spike in that bucket tells you Google saw more failures, not whether they were timeouts, database errors, an upstream API dependency falling over, or a CDN misconfiguration. Triaging the actual cause means going to your own server and application logs for the same time window, not staring at the Crawl Stats chart for more detail than it contains.

The Page Indexing report is more specific about which URLs are affected: it has a "Server error (5xx)" exclusion reason listing individual URLs Google tried to crawl and couldn't, with a last-crawled date. That's useful for confirming which parts of the site were hit and whether the count of affected URLs is shrinking after a fix, but it's still a sample of Googlebot's own crawl attempts, not a full record of every user-facing error during the incident. An external uptime monitor that hits your site independently of Google will usually give you a tighter picture of exactly when the outage started and ended than either Search Console report will.

After the Fix: What Recovery Actually Looks Like

Fixing the server doesn't instantly undo the crawl-rate reduction or restore any URLs that got dropped; both recover on Google's schedule as it re-establishes that the host is healthy again. There isn't a reliable trick to force this faster at scale. The URL Inspection tool's "Request Indexing" option can nudge a recrawl of a specific high-priority URL, but running it across hundreds of URLs one at a time doesn't meaningfully speed up a site-wide recovery, and Search Console rate-limits how many manual requests it will accept anyway.

What's worth doing instead is watching the Page Indexing report's server-error count over the following days and confirming it's trending down rather than assuming it's fixed the moment the site itself loads normally in a browser. It's also worth treating the incident as diagnostic input rather than a closed ticket the moment the server responds again: was the root cause a deploy that briefly exhausted database connections, a dependency on a third-party API that had its own outage, a spike in bot traffic unrelated to Googlebot, or a certificate that expired and broke TLS handshakes site-wide? Each of those has a different fix, and a site that goes down the same way twice in a month teaches Google's crawl scheduler to be more conservative about it than a site that had one clean incident and recovered.

Flaky Uptime Is Worse Than One Clean Outage

A pattern worth naming separately from a single incident: intermittent failures, where the server is up most of the time but returns a 5xx or times out on some fraction of requests, are harder on crawling than one clean, complete outage. A site that is reliably down communicates a clear, bounded event. A site that fails unpredictably looks, from a crawler's perspective, like it can't be trusted to respond consistently at any given moment, and that uncertainty is exactly the condition that pushes crawl rate down for longer than a single well-defined outage would.

This shows up most often with under-provisioned hosting that only fails under load, origin servers sitting behind a CDN or reverse proxy where the edge is fine but the origin occasionally times out on cache misses, and DNS-level problems where some resolvers get a failure and others don't. In all of these cases the fix isn't a maintenance page at all, since nothing was taken down on purpose; it's addressing the underlying capacity or configuration issue, because from Google's side, five clean minor outages this month read worse than one afternoon offline for a planned deploy.