Website Under Maintenance: Usea 503 Without Losing SEO

Put your website into maintenance mode in three steps

A website under maintenance is temporarily made unavailable behind a holding page. Three actions are enough: enable maintenance mode in the CMS, return an HTTP 503 response with a Retry-After header, and publish a clear holding page with an expected return time.

It is mechanical, not magical. Almost every SEO problem seen during this kind of intervention comes down to one technical detail: a 200 response returned instead of a 503, a blank page instead of a useful message, downtime that drags on for three weeks because no one planned the return, or a forgotten CDN cache that continues to serve the maintenance page after the website has gone live again.

Let us look at exactly what you need to do. This article covers maintenance mode, a temporary state that can be switched on and off, rather than a website's routine maintenance programme. The two are often confused, so we will clarify the difference next. By the end, you will know how to take a website offline, carry out the work and bring it back while limiting the risk to your Google visibility and your visitors.

Maintenance mode versus routine maintenance: the crucial difference

Maintenance mode is temporary: your website displays a holding page during an intervention such as a major update, migration, partial redesign or critical debugging. It typically lasts from a few minutes to a few hours. Think of it as an on/off switch.

Routine maintenance is an ongoing programme: security updates, backups, monitoring, performance optimisation and broken-link checks. The website remains online while this work takes place. It is a continuing service, not a one-off event.

Confusing the two leads to costly mistakes. Taking a website offline for a straightforward WordPress plugin update is unnecessary and can harm SEO. Conversely, carrying out a major migration without maintenance mode risks corrupting data if a visitor performs an action while the database is being copied.

As a practical rule, enable maintenance mode if the intervention changes the database, production code or critical files. Leave the website online if the work only affects the back office or passive optimisations. Routine maintenance falls into four categories, explained below and in our complete guide to website maintenance.

The different types of website maintenance

Website maintenance falls into four categories: preventive, corrective, perfective and security maintenance. Each can take place without taking the website offline. Maintenance mode is only necessary when an operation presents a risk to visitors, orders or data.

Preventive maintenance

This reduces the likelihood of a failure. It includes tested backups, monitoring, certificate checks, scheduled-task reviews and the removal of unused dependencies. Its purpose is to identify a problem before it becomes an incident.

Corrective maintenance

This fixes an identified fault: a form that will not submit, a payment error, an unavailable page or a display problem. Priority depends on impact. A minor bug can wait for a normal maintenance window, while a checkout error requires immediate attention.

Perfective and security maintenance

Perfective maintenance adds or adapts functionality. It may change a user journey, connector or template. Security maintenance fixes a vulnerability, updates a dependency or restricts access. They remain distinct categories, even when the same release includes both kinds of change.

How long your website can remain under maintenance

Aim for downtime of less than 24 hours. A 503 response with Retry-After indicates that the outage is temporary, but Google does not guarantee that it will have no effect. Its current documentation advises against returning server errors for more than one or two days. After several days, crawling slows down and some URLs may drop out of the index. From 48 hours onwards, treat the maintenance period as an SEO incident and accelerate the return to service.

Less than 24 hours: limited risk, not zero risk

An intervention lasting from a few minutes to one day usually gives search engines few opportunities to encounter the outage. Check every response nonetheless: all unavailable URLs should return a 503, Retry-After should match the advertised return time, and the essential assets used by the holding page must remain accessible. Monitor sales, forms and inbound calls too, because the commercial risk begins before the SEO risk.

Two to seven days: growing risk and closer monitoring

This exceeds Google's recommended window. Monitor server errors and crawl statistics in Search Console, then review the logs to see which URLs Googlebot is actually requesting. Give customers a realistic return time and restore essential pages first if the entire website cannot be brought back at once. Retry-After does not make an extended outage consequence-free.

More than seven days: high risk

After several days, Google may temporarily remove URLs from its index. Returning visitors also face a prolonged service interruption. Keep production available while the team works in a private staging environment protected from indexing and users. The public outage should cover only the final data synchronisation, checks and cutover.

For a redesign or complete transfer, our website migration guide explains how to prepare URLs, redirects and a rollback plan. Before the intervention, record your crawl data, highest-converting pages and main contact channels. You will then have a reliable baseline for comparison after the website returns.

Why websites are put into maintenance mode

A website migration may require a short freeze while the final data is copied. A partial redesign may alter templates or the database schema. A major update may make the theme or some modules incompatible.

Fixing a vulnerability sometimes requires logins to be blocked while a component is replaced and logs are reviewed. Changing hosting providers can also require a brief cutover, particularly if the data continues to change during the transfer.

In every case, prepare the work in a staging environment. Maintenance mode should protect a short, controlled phase. It should not become a public development environment for days on end.

HTTP 503: the correct signal for temporary unavailability

For temporary unavailability, Google recommends returning a 503 Service Unavailable response. The Retry-After header can indicate when the service is expected to become available again. This helps crawlers distinguish maintenance from permanent removal, although it does not guarantee rankings or indexation.

Why does this precision matter? A 200 OK says that the response is normal, so a search engine may treat the holding page as the content of the URL. A 404 or 410 says that the resource is missing. A 500 indicates an unplanned internal error. None of these statuses accurately describes a temporary, controlled interruption.

A 503 means that the server is temporarily unable to handle the request because of overload or maintenance. Googlebot may slow its crawling and return later. The Retry-After value remains advisory: a client or crawler is not required to return at that exact time.

RFC 9110 defines two formats for Retry-After: a complete HTTP date, such as Retry-After: Wed, 12 Aug 2026 06:00:00 GMT, or an integer delay in seconds, such as Retry-After: 7200 for two hours. A delay works well for a short intervention, while an explicit date makes a planned maintenance window easier to understand.

One important limitation: Google advises against returning server errors for more than one or two days. After several days, affected URLs may drop out of the index. For a longer project, build and test in a private staging environment, keep production online, and reserve the 503 response for the final cutover.

While the website is offline: essential actions

The website is offline. You have a few hours, perhaps a few days. Use that window intelligently instead of simply 'running the update' and hoping for the best.

Back up everything first: database and files

Before changing anything, export the database and copy the entire wp-content directory, or its equivalent in your CMS. Store these files locally AND in cloud storage such as Drive, Dropbox or S3. A backup on the same server is useless if that server fails.

Carry out the work on the staging copy

Ideally, work in staging rather than directly in production. Reproduce the environment, make the update and test it. This is the only reliable way to avoid panic when a plugin breaks 30 minutes after the website goes offline.

Run a technical audit while traffic is out of the way

This is a rare window when no one is using the website. Make the most of it: audit performance, remove unused plugins and inactive themes, optimise images in bulk and review file permissions. Resource-intensive tasks that slow down a production website are easier to complete during maintenance.

Prepare the return announcement

During the outage, draft the blog article or LinkedIn post that will announce, 'We are back with these new features.' Turning maintenance into a communication event helps recover some of the visibility lost through downtime.

Get support for a long cutover

A lengthy intervention requires more than a holding page: a staging environment, a restorable backup, a rollback procedure, HTTP response checks, a communication plan and monitoring after the website returns. Our website maintenance service can manage this technical framework when your team lacks the time or access required.

If the website depends heavily on Google, begin by measuring the URLs, queries and conversion pages that must not disappear. Our SEO studies establish that baseline and help assess the impact after the cutover. The objective is not to promise zero risk, but to detect deviations quickly and retain the ability to roll back.