503 Service Unavailable Maintenance Mode: Set It Up Safely for SEO

Sooner or later most sites need a short break: a database migration, a platform upgrade, a payment-provider switch. The easy way out is a "We'll be back soon" page, and the easy way to publish it is to swap in a static file. If that file is served with a normal 200 status, or if every URL is redirected to it, search engines and monitoring tools are told that the site now consists of one healthy page. The right tool is a 503 service unavailable response, which says the site is temporarily not ready, so the content you have should be kept.

This guide shows how to run 503 service unavailable maintenance mode properly: when it is the right choice, how long it can last, what the page and headers should contain, configuration for nginx, Apache and ASP.NET Core, and how to switch it off cleanly. It is for owners and developers planning downtime. You finish with a rehearsed switch-on, a verified switch-off and a plan for overruns.

Short answer: For short planned downtime, answer every page with HTTP 503, a Retry-After header and a light static page, and keep /robots.txt available. Google advises 503 only for urgent, short outages of about one to two days at most. For longer closures, keep the site online with limited functionality instead.

Before you begin

You need access to the web server or hosting configuration, the CDN settings if you use one, your monitoring tool, and a way to run curl from outside your network. Pick a quiet time, tell customers and support staff, and write down the planned start, the expected end and who can cancel the window.

Back up the configuration you will change and rehearse on staging. The main risk is a rule that stays active after the work is done, so prepare the switch-off before the switch-on. If URLs or domains are changing too, read Website Migration SEO Checklist, because maintenance mode covers downtime, not redirects.

Why does 503 work and 200, 404 or a redirect do not?

Google's documentation on HTTP status codes puts 503 in the same group as 500 and 502: crawlers slow down, content from those responses is ignored, and URLs that are already indexed are kept at first. If the errors persist, URLs are eventually dropped, and Google gives no fixed number of hours for that. That is acceptable for a short, announced window and unacceptable for weeks.

The alternatives behave differently:

What you serve during downtime	What crawlers learn	Result
503 with `Retry-After`	The site is temporarily unavailable.	Content kept at first; crawling slows.
200 "back soon" page on every URL	Each URL now holds that text.	Error-like content under a 200 is reported as a soft 404 in Search Console.
404, 410 or 403	The content is gone or forbidden.	Google's pause-your-site guidance warns these remove URLs from Search.
`noindex` tag or header	Do not show this page.	Same warning: it removes URLs.
Redirect everything to a maintenance URL	Every old URL moved there.	Describes a move, not downtime.

How long can a site stay in 503 maintenance mode?

Google's guidance on pausing an online business and its guidance on reducing crawl rate give the limits:

Planned duration	What to do
Minutes to a few hours	503 with `Retry-After` and a static page.
Up to one or two days	503 is still the recommended error response, but do not plan to stay longer.
Several days	Treat a full shutdown as a last resort that lasts "a few days at most".
Longer than that	Do not return 503. Keep the site online with limited functionality (disable the cart, add a banner), or keep an indexable home page returning 200 as a placeholder.

Google also says that the same URL returning these codes for multiple days may be dropped from the index, that long error periods reduce discovery of new pages and refresh of existing ones, and that Google Ads campaigns may be paused. While a URL returns 503, Google cannot refresh its title, description or structured data. None of this is a ranking claim.

Step-by-step instructions

Step 1: Decide whether you need a full outage

Ask whether only one part of the site has to stop. If only checkout or the account area is affected, put a notice there and keep content pages online with a normal 200. Google reduces crawl rate across the hostname in proportion to the number of URLs returning server errors, so a smaller scope helps. A rolling deployment or read-only mode may remove the need for downtime entirely.

What success looks like: You have written down the exact URLs or areas that will return 503, and why the rest cannot stay up.

Step 2: Set the window and the Retry-After value

Estimate the end time and add a margin. Retry-After takes either a number of seconds or an HTTP date, such as Retry-After: 3600 or Retry-After: Wed, 21 Oct 2026 07:28:00 GMT. Google says to send it as a best-effort date or duration. MDN notes that client support is inconsistent, though some crawlers such as Googlebot honor it. Treat it as a hint, not a schedule.

What success looks like: You have a planned end time and a Retry-After value you can defend.

Step 3: Build a light static maintenance page

Make one self-contained HTML file: inline CSS, no database calls, no external scripts, and only small images (Google suggests keeping it lightweight, with inline CSS and base64-encoded images). Say what is happening, when you expect to be back, and how to contact you or where to see status. Do not add a noindex tag (see What Does Noindex Do? for why it is the wrong tool here).

What success looks like: The file loads in a fraction of a second with the application stopped.

Step 4: Serve the page with a 503 status and the right headers

Pick the snippet for your stack. Whatever you use, the page must be served at the URL requested, with the status 503, and not behind a redirect.

nginx (the always parameter matters: without it, add_header skips error codes such as 503):

server {
    root /var/www/example;
    error_page 503 @maintenance;

    location = /robots.txt { }   # keep serving the real file

    location / {
        return 503;
    }

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

Apache 2.4 (Header always is needed because the default condition only covers 2xx responses):

ErrorDocument 503 /maintenance.html
Header always set Retry-After "3600" "expr=%{REQUEST_STATUS} == 503"
Header always set Cache-Control "no-store" "expr=%{REQUEST_STATUS} == 503"

RewriteEngine On
RewriteCond %{REQUEST_URI} !^/(maintenance\.html|robots\.txt)$
RewriteRule ^ - [R=503,L]

For a R= code outside 300 to 399, Apache drops the substitution and answers with that status through its normal error path, so the ErrorDocument is used.

ASP.NET Core (a middleware placed first in the pipeline, switched by configuration):

app.Use(async (context, next) =>
{
    var on = app.Configuration.GetValue<bool>("Maintenance:Enabled");
    if (on && !context.Request.Path.StartsWithSegments("/robots.txt"))
    {
        context.Response.StatusCode = StatusCodes.Status503ServiceUnavailable;
        context.Response.Headers["Retry-After"] = "3600";
        context.Response.Headers["Cache-Control"] = "no-store";
        context.Response.ContentType = "text/html; charset=utf-8";
        await context.Response.SendFileAsync(
            Path.Combine(app.Environment.WebRootPath, "maintenance.html"));
        return;
    }
    await next();
});

If you run ASP.NET Core on IIS, Microsoft's documentation says a file named app_offline.htm in the app root makes the ASP.NET Core Module stop the app and send back that file's contents while it exists. The page does not state the status code, so check with curl what your host returns before relying on it for SEO, and do not assume it is 503.

Managed platforms often have a built-in maintenance mode. What matters is the status code the test in Step 6 shows, not the setting's name.

What success looks like: curl -I on any page shows 503, Retry-After and the no-store directive, while /robots.txt shows 200.

Step 5: Keep robots.txt, your monitor and your team working

Google's guidance is explicit: do not return 503 for robots.txt, because that blocks all crawling. Its robots.txt documentation explains why: if the file cannot be fetched because of a 5xx error, Google stops crawling the site for the first 12 hours, keeps retrying, and then uses the last good copy it has for up to 30 days. Also do not disallow everything in robots.txt as a shortcut; Google warns that this can remove your content from Search. Exempt /robots.txt in the rule, as the snippets do. If you are unsure what the file does, read What Is Robots.txt?.

Tell your uptime monitor about the window, as described in Website Uptime Monitoring, so the 503 does not page anyone.

What success looks like: Robots.txt returns 200 during the window, and your monitor shows the window as planned downtime.

Step 6: Test before and during the window

On staging, then immediately after switching on production, run:

curl -sI https://example.com/ | grep -iE '^(HTTP|retry-after|cache-control)'
curl -sI https://example.com/any-inner-page | grep -iE '^HTTP'
curl -sI https://example.com/robots.txt | grep -iE '^HTTP'

Expect 503 on pages, 200 on robots.txt, and check from a second network. If you use a CDN, request the same page twice to confirm the 503 is not being cached; a cached 503 can stay visible after the origin recovers. Google's pause guidance also recommends confirming the 503 locally with a tool like curl.

What success looks like: Three commands, three expected answers, from two networks.

Step 7: Switch off and prove the site is back

Remove the rule, then check the home page, an inner page, a page you rarely open, the sitemap and robots.txt for 200 with the real content. Purge the CDN. Read the first page to confirm it is not the maintenance page served under a 200. Keep monitoring closely, follow the checks in After Website Launch SEO for anything unusual, and look at Search Console's Crawl Stats Host status for server connectivity problems, as covered in Website Uptime Monitoring. Google increases crawl rate gradually once it sees successful responses again, and states no timescale.

What success looks like: All key URLs return 200 with real content, and no 503 responses appear in the access log after the end time.

Step 8: Have a plan for overrun

Decide before you start what happens at the edge of your window. If the work is not done well before the one-to-two-day limit, restore a limited version of the site rather than extending the 503. If you cannot restore, use Google's placeholder approach for longer closures: an indexable home page with a 200 status that explains the situation. Do not use the Search Console temporary removal tool for this; Google says it makes it hard for people to find out your status.

What success looks like: The overrun rule is written, and the person who may invoke it is named.

Final verification checklist

Every maintenance URL returns 503 with a Retry-After header and a static page.
/robots.txt returns 200 throughout, and the sitemap stays reachable.
Nothing in the setup uses 200, 403, 404, 410, noindex or a redirect to hide the outage.
The CDN does not cache the 503, and the cache was purged at the end.
The monitoring window opened and closed on schedule.
After switch-off, key pages return 200 with their real content.
The total downtime stayed within the one-to-two-day guidance, or the site stayed online in a limited form.

Common mistakes to avoid

Returning 200 with a "back soon" message. Use 503.
Redirecting all URLs to /maintenance. Serve the 503 in place at each URL.
Blocking robots.txt with the same rule. Exempt it so crawlers can keep reading it.
Forgetting always in nginx or Apache. Without it, headers are skipped on error responses.
Letting the CDN cache the 503. Use no-store and test twice.
Using noindex or Disallow as a maintenance tool. Both risk removing URLs.
Planning an open-ended outage. Past a day or two, keep the site online with limited functionality.
Leaving the switch on. Put the switch-off in your runbook.

Frequently asked questions

Does a 503 hurt SEO?

A short, planned 503 is the response Google's documentation expects for a temporary condition, and it keeps indexed URLs at first. Persistent errors can lead to URLs being dropped, so duration matters. Google makes no promise about how a page will perform after an outage.

Will Google obey Retry-After?

Google accepts it and says to send it as a best-effort date or duration, and MDN says some crawlers honor it. Support across clients is inconsistent, so use it as a hint.

How long is too long?

Google's guidance puts a full shutdown at a few days at most as a last resort, and says to use 503 for 1 to 2 days. For anything longer, keep the site online in a reduced form.

Should the maintenance page have noindex?

No. Google lists a noindex tag or header among the things that remove URLs from Search during a closure.

Can I use 503 for a brief restart?

Yes, with a short Retry-After, though zero-downtime deployment is better. For diagnosing real faults instead, see HTTP 500 and 503 Errors.

Official references

Next step: Try the free website sample to see how your own site does on a few of these checks. This guide provides technical information, not a guarantee of rankings, traffic or index inclusion.