Short answer: maintenance mode does not have to hurt your SEO, but the HTTP status code of the maintenance page matters a great deal. For a temporary outage, the right tool is a 503 Service Unavailable response on the same URLs, ideally with a Retry-After header. Serving the maintenance page with a 200 tells crawlers that the text on it is the real content; a 404 or a redirect suggests something permanent happened. This guide covers how Google treats 503, how to handle short and long outages, how to test and roll back, and what to verify once the site is back.
The general status code table is not repeated here. For what 200, 301, 302, 404, 410 and 5xx mean for SEO, see the HTTP status codes SEO guide. This article stays on the planned or unplanned downtime scenario. Google's documentation can change, so check the current pages before you apply any detail below.
Why a Maintenance Page Should Not Return 200
Many plugins and hosting panels treat maintenance mode as a nice-looking page. That is fine for people, but if the status code is 200, crawlers see a perfectly normal page.
What a 200 tells Google
Google's documentation on HTTP status codes (Opens in a new tab) says that for 2xx responses the content is passed to the next stage of the indexing pipeline. In other words, your maintenance message is considered as the content of that URL. The same page adds that when a 2xx response carries content that looks like an error, such as an empty page or an error message, Search Console may report a soft 404, and indexing is not guaranteed. So you either get noise in your reports or, for a while, a page whose indexed text is "back soon" rather than your real copy. Neither outcome is what you want.
Why 404, 410 and redirects are also wrong
A 404 or 410 describes a page that does not exist or was removed on purpose. During a short outage it tells crawlers nothing about the pages coming back. Redirecting every URL to one maintenance page creates a different problem: it looks like your address structure changed, and you must remove the redirects afterward. Google's site-move documentation separately warns that sending many old URLs to one unrelated page can be treated as a soft 404. Returning an error code on the original addresses, without redirects, is cleaner.
What 503 communicates
A 503 is a server error that says the server cannot handle the request right now. According to Google, 5xx and 429 errors make its crawlers temporarily slow down. For 500, 502 and 503 specifically, the page says Google lowers the crawl rate in proportion to how many individual URLs return server errors. Once the server returns 2xx again, Google gradually raises the crawl rate, although the page gives no figures for how fast. In practical terms, 503 is the signal built for "come back later".
Side-by-side summary
| What the site returns | What a crawler infers | Main risk |
|---|---|---|
| 200 with maintenance text | Normal content, maybe a soft 404 | Real content confused with the notice, report noise |
| 404 or 410 | Page missing or removed | A wrong signal about permanence |
| 301 or 302 to a maintenance URL | Address moved or temporary target | Redirect clutter, cleanup afterward |
| 503 on the same URL | Temporary server problem, retry later | If it drags on, slower crawling and index loss |
An unplanned crash looks the same
A 503 is also what an overloaded or crashed server may produce on its own. That is why planned maintenance and incident monitoring should share one view: after a window closes, confirm that 503s are really gone, and decide in advance who checks and when.
Implementing 503 with Retry-After
The mechanics are simple: while maintenance is on, every request receives a 503 and a short HTML body. The hard part is doing it consistently across all paths without poisoning caches.
The three parts of the response
The status line is 503 Service Unavailable. The optional Retry-After header suggests when to try again. The body is what people read: a brief explanation, an estimated return time and, if appropriate, a way to reach you. Keep the wording informative and short, so it does not read like page content.
What does Retry-After mean for Google?
Google's HTTP status code document does not mention Retry-After, so there is no official Google statement about how it uses the header. The MDN page on Retry-After (Opens in a new tab) explains that it tells a client how long to wait before the next request. It takes either a non-negative number of seconds or an HTTP date, and with a 503 it indicates how long the service is expected to be unavailable. It is also used with 429 and redirect responses. MDN adds that some crawlers, Googlebot among them, honor the header and recommends sending it with a 503 during scheduled downtime, but also warns that support on clients and servers is inconsistent. The sensible position: include it, but never promise yourself that it controls crawl timing.
Picking a sensible value
Use an estimate you believe. If the work should take an hour, send that as seconds. If the window runs over, update the value. A figure that is far too large effectively asks crawlers to stay away for a long time, which is the wrong message for a short planned window.
Sitewide means sitewide, including robots.txt
If maintenance affects the whole site, every request should get the same 503, robots.txt included. A mixed state, where some paths return 200 and others 503, sends inconsistent signals. Google's robots.txt documentation (Opens in a new tab) describes what happens when a robots.txt file exists but cannot be fetched because of a 5xx: for the first 12 hours Google stops crawling the site but keeps trying to fetch the file; for the next 30 days it uses the last good version; after that, if errors continue and the site is generally available, it behaves as if there were no robots.txt, while if the site has general availability problems it stops crawling and requests the file periodically. This is not a maintenance recipe, but it shows that a 503 on robots.txt is a known case with documented behavior. The documentation does not suggest serving a 200 robots.txt with a blanket "Disallow: /" during maintenance, and we would not do it: it announces a site closed to crawling, and forgetting to revert it afterward causes a lasting crawl problem.
Should the page carry noindex?
Google's robots.txt introduction (Opens in a new tab) says robots.txt is not a mechanism for keeping a page out of Google, that a blocked URL can still be indexed if other sites link to it, and that noindex or password protection are the ways to keep content out of search. For a maintenance notice that already returns 503, an extra noindex is unnecessary and becomes a hazard if it survives the end of the window. Google's documents give no direct guidance on maintenance pages, so the advice that follows is an inference: when the status code does the job, skip noindex.
Caching and CDN hazards
If a CDN or reverse proxy caches the maintenance response, visitors may keep seeing a 503 after you reopen the site. Mark the maintenance response as uncacheable, purge the relevant caches when you finish, and test both the origin and the CDN edge on the way out. The exact headers depend on your stack.
Plugins and panel switches
Many maintenance plugins ship with a friendly page and leave the status code as a separate setting. Some show the maintenance page only to logged-out visitors and the normal site to administrators, so your own test looks fine while crawlers get something else. Always check from a logged-out window and from the command line. The same caution applies to "maintenance" buttons in hosting panels: measure the code, do not assume it.
Implementation checklist
- The maintenance response is a 503 on the original URLs, with no redirect.
- Retry-After carries a realistic estimate.
- All paths and robots.txt behave the same way.
- The body gives a short explanation and an expected return time.
- The response is not cached anywhere.
- Monitoring and health checks will not raise false alarms or hide real ones.
- The steps to turn maintenance off are written down with a named owner.
Writing the notice for people
The status code speaks to crawlers, the text speaks to visitors. A good notice answers what is happening, when it should end and what to do meanwhile. Link to a status channel if you have one and give an urgent contact route. Keep the page light: no extra web fonts, heavy images or third-party scripts that add load to an already strained server. On a bilingual site, show the notice in both languages.
Clients that are not browsers
Maintenance also hits API endpoints and callbacks hosted on the same server. Mobile apps and partner systems may show error screens if they do not expect a 503. Serve API maintenance responses with a machine-readable body and the same 503 code. For payment providers or other systems that call your callback URLs, read the provider's documentation to learn how they retry; behaviors differ and should not be assumed.
Short vs Extended Downtime
The question everybody asks is how long is too long. The honest answer is that Google's documentation does not set a threshold.
Google gives no threshold for how long downtime can last
According to the status code page, server errors slow crawling temporarily, and URLs that persistently return a server error are eventually removed by the indexing pipeline. It gives no number of hours or days. The 12-hour and 30-day values belong to robots.txt fetch errors and must not be read as the point at which pages drop out of the index. Any sentence that says "two days is safe" or "a week is fatal" would go beyond what the documents state.
Three ways to handle different durations
| Situation | Suggested approach | Watch for |
|---|---|---|
| Minutes to a few hours, planned | Sitewide 503 with Retry-After | Pick low-traffic hours and confirm the end |
| Several hours to a few days, planned | Split the work so only affected sections return 503 | Risk grows as the window stretches |
| Long or open-ended | Reduce the scope of downtime, work on a temporary environment first | Do not let 503 become a long-term answer |
| Unplanned crash | Find the cause first; make sure errors surface as 503, not 200 or 404 | Provider fallback pages that return 200 |
Narrowing the scope
If only checkout, a member area or a search module is affected, there is no reason to take the whole site down. Returning 503 only on the affected paths lets the rest keep being crawled and visited. This fits Google's description that the slowdown is proportional to the number of URLs returning errors: fewer failing URLs, smaller impact. With partial maintenance, make sure navigation does not point heavily at pages that are down.
Scheduling around marketing
Choose the lowest-traffic window you can find, using day-and-hour breakdowns from analytics. Avoid the times when campaigns, newsletters or ads start sending visitors, and pause paid campaigns for the window if it overlaps. Paid clicks landing on a 503 waste budget and trust.
Example scenario: a short overnight database update
Example scenario: an online store manager plans a database update for the quietest hour of the night. She schedules a one-hour sitewide window, sets Retry-After to 3600 seconds, confirms that open orders were completed or queued, and turns the 503 off when the update finishes. The next day the logs show Googlebot receiving ordinary 200 responses again. For a short, planned window like this, what Google documents is a temporary slowdown of crawling followed by a gradual recovery; no further outcome is promised.
Decision rule when the window overruns
- Past the estimate? Update Retry-After and tell users an honest new time.
- Is the problem sitewide or only in one area? If you can split it, reopen the healthy part.
- Heading toward days? Increase monitoring of crawl activity and the index right away.
- Can part of the work wait? Restore normal 200 service first and reschedule the rest.
- If the fix is far off, record the risk for each additional day of 503 rather than switching to permanent codes or redirects.
What not to do in an unplanned outage
Some hosts show a fallback page automatically and may return it with 200, which silently publishes a maintenance page with the wrong code. Test what your host's error page returns before an incident. Deleting or blanking robots.txt in the first hours is not a fix either.
Testing and Rollback
A maintenance switch that has never been rehearsed is a source of avoidable errors. Run a full dry run before it matters.
Verifying the response
- Open the browser's developer tools network tab and confirm the homepage and a couple of inner pages return 503.
- Use a command-line client, such as curl with the head-only option, to read the status line and the Retry-After header.
- Check that robots.txt, the sitemap and an image file behave the same way.
- Try as a logged-out visitor, an administrator and an API client; if maintenance excludes some users, make sure crawlers are not among the excluded.
- When maintenance is live, run a live test with the URL Inspection tool in Search Console to see the response Google receives.
HEAD and GET must agree
Some plugins answer GET with 503 and HEAD with 200. Monitoring tools often use HEAD, so they report that maintenance has not started. Test both methods.
Write the exit before you enter
The moment you plan to turn maintenance on, document how to turn it off: which flag changes, which configuration reverts, which caches are purged and who does it. Define two rollback triggers. One is time: if the work overruns the plan by an agreed margin, an owner takes over. The other is outcome: if the main paths do not return 200 after the change, reverting the update beats extending the outage. If the work includes database changes, do not start without a restorable backup.
The first five minutes after reopening
- Homepage, a category and a product or article return 200.
- robots.txt returns 200 with the same content as before.
- The sitemap is reachable.
- No CDN or cache still serves a 503.
- The Retry-After header is gone.
- Health checks and monitoring are back to normal.
- Sign-in, search and checkout work.
Record the rehearsal
Write the status codes, headers and response times you saw during the rehearsal into a short table. During the real window, fill in the same table and compare. An unexpected 200 on a single path will stand out within minutes, and someone outside the maintenance team can read the table and confirm the work.
Where to rehearse
Use an environment with the same cache and CDN configuration as production when possible. A 503 that behaves on a laptop may behave differently behind a CDN. Keeping a test environment out of search results is a separate task and is not covered here.
Post-Maintenance Crawl and Index Checks
When the site is back, the work is not quite over. You still want to see Googlebot return to its normal pattern.
How quickly does crawling recover?
Google says the crawl rate rises gradually once the server returns 2xx, and it gives no timeframe. Recovery speed depends on site size and outage length, so a lower crawl rate in the first days is expected. The concern is a slowdown that persists for days while new content goes undiscovered. For the broader picture of how crawl capacity is spent, read the crawl budget optimization guide.
What to look for in the logs
Confirm that Googlebot requests received 503 during the window and 200 afterward. Unexpected 5xx responses, steady 4xx, and paths that were crawled before and no longer are, deserve attention. A method for reading logs for SEO is described in server log analysis for SEO. In Search Console, check the crawl statistics and indexing reports; if you use the interface in another language, menu labels may differ from those named here.
Soft 404 clean-up
If any URL returned 200 with maintenance text, Search Console may flag soft 404s. These do not always clear on their own. Inspect the affected URLs and validate the fix. To diagnose and resolve them, use soft 404 errors: how to find and fix.
Comparing visibility
Compare Search Console performance and organic sessions before, during and after the window. A short outage naturally produces fewer visits on that day, which should not be mistaken for lasting loss. The expectation is that impressions return toward the earlier level as crawling recovers. If they have not after several weeks, use the indexing report to see which pages dropped.
Keep a maintenance log
For every window, note the start and end time, the Retry-After value, the affected sections, test results and what you monitored over the next three days. If traffic wobbles later, the log lets you rule the maintenance in or out quickly, and it becomes a ready template for the next one.
Post-maintenance decision table
| Observation | Likely cause | Next step |
|---|---|---|
| Maintenance ended but 503 persists | Cache, CDN or plugin remnant | Purge caches, test origin and edge separately |
| robots.txt still unreachable | Maintenance rule covers it, or the file is missing | Republish it with 200 and compare with the previous version |
| Soft 404 count rose | Pages returned 200 during maintenance | Inspect them and start validation |
| Crawling stays low for days | Slow server or partial errors continue | Review logs and response times |
| Specific pages left the index | Long outage or wrong status code | Re-inspect them and request recrawling if needed |
Frequently Asked Questions
Does putting a site into maintenance mode hurt SEO?
Not necessarily. A short, well-configured outage is usually manageable, while a badly configured one can cause trouble. A maintenance page served with 200 tells crawlers it is normal content. A 503 says the server is temporarily unable to respond, and Google slows its crawling. Google's documentation says URLs that persistently return server errors are eventually dropped from the index, but it gives no number of days, so keep downtime as short as possible.
Which status code should a maintenance page return?
For temporary maintenance, 503 Service Unavailable. A 404 or 410 suggests the page is gone for good. A 200 presents your maintenance text as real content and can lead to soft 404 reports in Search Console. Redirecting everything to a maintenance URL behaves like an address change, so returning 503 on the original URLs is cleaner.
Does Google respect the Retry-After header?
Google's HTTP status code documentation does not mention the header. MDN says some crawlers such as Googlebot honor it and recommends sending it with a 503 during scheduled downtime, while also noting that client and server support is inconsistent. Add it as a harmless best practice, but do not treat its effect as guaranteed.
How long can a site stay down before rankings suffer?
Google's documents give no threshold in hours or days for this. The 12-hour and 30-day figures it publishes apply to how robots.txt fetch errors are handled, not to when pages leave the index. Longer outages are riskier in general, so plan the shortest window possible and narrow the scope if the work drags on.
Should I block the maintenance page in robots.txt?
There is no need. Google states that robots.txt is not a mechanism for keeping a page out of Google, and a blocked URL can still be indexed if other sites link to it. A sitewide Disallow left in place after maintenance can cause a serious crawl problem. A 503 does the job and is easy to reverse.
What should I check once maintenance is over?
Confirm key pages return 200, robots.txt is reachable and unchanged, and no CDN or cache is still serving a 503. Then watch crawl stats, the page indexing report and server logs for several days. Google raises its crawl rate gradually after your server returns 2xx again.
What about checkout and payment callbacks during downtime?
From an SEO view, the point is that 503 signals a temporary condition. The business side is separate: finish or safely queue in-flight orders before the window starts, and check your payment provider's documentation to learn whether it retries callbacks that receive a 503.
Related guides: Website Redesign SEO Checklist: Protect Rankings When You Relaunch, Staging Site Indexed by Google: How to Fix and Prevent It, WordPress Tag and Archive Pages: Noindex or Index?.
Conclusion
What makes maintenance safe for SEO is the status code, not the design of the notice. Return 503 on the same URLs, add Retry-After with a realistic estimate without treating it as a documented Google guarantee, test robots.txt and CDN behavior in the same rehearsal, and narrow the scope if the work runs long. Google's documents give no day threshold for downtime, so keep it short and verify the end. Afterward, watch 200 responses, robots.txt, logs and Search Console. No step guarantees a particular ranking outcome; the aim is to keep a temporary technical event from becoming a lasting loss of visibility.
If you want a steady supply of guides and knowledge content to keep your site useful through maintenance and after it, you can explore Akua Adforce's content writing service; scope and terms are described on the product page.
Post a comment
Please log in to leave a comment. Login