Guide · E-commerce

Does Website Downtime Hurt SEO? What Google Says About 503 and Outages

How outages affect Google crawling and rankings, why a 503 with Retry-After is the right response, how short and long outages differ, and how to recover.

By SiteDownCheck Editorial · Updated October 5, 2026 · 8 min read

Every site owner eventually asks the same question after an outage: "Did that cost me my rankings?" The honest answer is that brief outages usually do not, long ones can, and how your server responds while it is down matters more than most people expect. This guide summarizes what Google has published about crawling and server errors, explains what happens during a short versus a long outage, and gives you a response plan that protects your search visibility.

What Googlebot does when your site fails

Google's crawler requests your pages and robots.txt file and reacts to the response codes it gets. According to Google Search Central's documentation on HTTP status codes and network errors:

  • 5xx server errors and 429 (too many requests) cause Google's crawlers to temporarily slow down their crawling. If the errors go away, the crawl rate gradually recovers.
  • If the errors persist, Google may eventually drop URLs that keep returning server errors from its index. Google does not publish an exact threshold in these pages that you can plan around, so treat "a few hours" as low risk and "days" as risky.
  • Network errors and DNS errors (timeouts, connection resets, failures to resolve the domain) are treated similarly to server errors: a temporary reason to slow down, a persistent reason to drop pages.
  • A robots.txt file that cannot be fetched is treated with particular caution. If the robots.txt URL returns a server error, Google may stop crawling the whole site for a period, because it cannot confirm what is allowed. Google's documentation describes how long it uses a cached copy and what happens afterward; read it if your robots.txt is served by something that can fail independently of the site. Check yours with the Robots.txt Checker.

In short: Google treats errors as temporary at first and as a signal of a dead page if they keep happening.

Why 503 is the right status for planned or temporary downtime

When your site is unavailable on purpose (maintenance, a migration step) or you know it will return soon, the correct HTTP response is 503 Service Unavailable. Google has recommended this for years, including in a Webmaster blog post on handling planned downtime and in its guidance on temporarily pausing an online business. A 503 says: the failure is temporary, come back later.

Compare with the common wrong answers:

What the server returnsWhat it tells GoogleRisk
503Temporary; try again laterLow, the intended signal
200 with a "we'll be back soon" pageThis is real contentGoogle may index the maintenance message as your page content, or treat it as a soft error
404 / 410The page is gonePages can be dropped from the index
301/302 to a maintenance pageThe URL movedConfuses indexing; may replace your real pages
Timeout / no answerNetwork errorTreated as an error; no explanation given

Serving a 503 is part of doing website maintenance mode right, and the Maintenance Detector can tell you what your site returns while in maintenance mode. Learn the status code in fix 503 Service Unavailable.

The Retry-After header

You can add a Retry-After header to a 503, giving either a number of seconds or an HTTP date:

HTTP/1.1 503 Service Unavailable
Retry-After: 3600
Content-Type: text/html

The header is defined in the HTTP standard as a hint for when the client should retry. Google's documentation has mentioned it in the context of downtime, but crawlers are not obliged to follow your exact value, and Google does not promise to wait precisely that long. Think of it as a polite hint: include it, keep it realistic, and do not rely on it to hold the crawler off. A very large value does not make a long outage harmless.

Check what your server really sends with the HTTP Header Checker or:

curl -sI https://example.com/ | grep -iE "^(HTTP|retry-after)"

Do not leave a 503 in place for a long time

A 503 is a promise that the outage is brief. If it lasts days, Google may stop treating it as temporary and begin to drop pages. If a site is going to be offline for an extended period, think about what is best for your situation: bring up a stripped-down version of the site, restore from backup on another host, or follow Google's guidance on pausing a business site. Do not leave a bare 503 up for weeks.

Short outages versus long outages

Minutes to a few hours

For most sites, a short outage has little lasting SEO effect. Googlebot may hit errors, slow its crawling, and then resume. Rankings normally do not change in response to a single brief incident. The bigger damage is to visitors and revenue, covered in ecommerce downtime cost.

Frequent short outages are a different story. If your site fails repeatedly, crawlers back off repeatedly, new and updated pages are picked up more slowly, and users who click a result and find an error may return to the search results. Google has said page experience and reliability are important to users, and a flaky site is a poor experience, even if there is no single "uptime ranking factor" you can point to.

A day or two

Expect crawling to slow and recover over the following days. Pages that were being crawled most often recover first. Watch Google Search Console: the Crawl Stats report shows requests, response codes and average response time, and the Page indexing report shows pages that were not indexed due to server errors.

Several days or more

This is where real risk begins. Persistent server errors can lead to URLs being removed from the index, and recovery may take time after the site returns, since Google must recrawl and reprocess them. If you must be down this long, put in place the best version of a stand-in site you can, and read Google's guidance on pausing online businesses.

Slowness counts too

An outage does not have to be total. A site that responds in 20 seconds technically works, but crawlers may reduce their rate when responses are slow, and users leave. Track response time as well as availability. See website slow diagnosis and reduce time to first byte.

Other ways downtime damages SEO

A response plan

During the outage

  1. Confirm what the world sees with the HTTP Status Checker, not just what your own browser shows.
  2. If the downtime is deliberate or will last more than a few minutes, make the server return 503 with a Retry-After, plus a human-readable page.
  3. Keep robots.txt available with a 200 response, and do not block crawling in it just because the site is down.
  4. Post updates on a status page so customers know what is happening.

After the outage

  1. Verify that normal pages return 200, that robots.txt works, and that no maintenance-mode leftovers remain.
  2. Check the Search Console Crawl Stats and Page indexing reports over the next days.
  3. Resubmit the sitemap if many pages were affected. You do not need to request indexing for each URL.
  4. Write a short postmortem and fix the cause.

Before the next one

Next steps

FAQ

Will a few minutes of downtime hurt my Google rankings?

Generally no. Google's crawlers slow down when they see errors and resume afterward. A single short incident rarely produces a lasting ranking change, though repeated failures can slow crawling and hurt users.

Should I return 503 or 404 during maintenance?

  1. It tells search engines the problem is temporary. A 404 or 410 says the page is gone and can lead to pages being dropped from the index.

Does Google respect the Retry-After header?

Treat it as a hint. It is part of the HTTP standard and worth including on a 503, but you should not assume a crawler waits exactly that long.

How long can I leave a 503 up?

Only briefly. A 503 signals a temporary condition, and if it persists for days Google may begin removing pages. For long outages, restore a working version of the site elsewhere if possible.

What if robots.txt returns an error during the outage?

Google is cautious with robots.txt errors and may pause crawling of the whole site. Make sure robots.txt is served reliably, ideally from a layer that stays up even if the application is down.

Get notified when this guide updates

Plus occasional practical tips on uptime and monitoring, nothing else. Unsubscribe anytime.

This page is general information written by our editorial team and updated when documentation changes. Servers and providers differ, so test changes safely first. See our editorial policy and disclaimer.