Website Maintenance Mode: Keep Your SEO Safe

Website maintenance mode is a temporary state where your site shows a notice instead of its normal pages, and the safest version for SEO answers every page request with an HTTP 503 status and a Retry-After header, for one to two days at most. That is what Google documents for short outages. The wrong setup, such as a 200 “back soon” page, a 404 or a robots.txt that blocks everything, can cost you visibility that takes weeks to win back.

This is part 5 of The Web After PHP2Shell, and it exists because of a real decision many site owners faced this week. After the October 2026 PHP flaws, agencies in several countries advised taking systems offline if a fix could not be installed quickly. Part 1 explains the flaws and Part 4, static vs dynamic website, explains how to reduce the chance of needing this. Here is how to go offline without wrecking your search presence.

On this page

• Should you take your site offline to patch?
• What status code should maintenance mode return?
• How long can a site stay offline?
• How do you set up maintenance mode correctly?
• What about AI crawlers during downtime?
• What should you check when you come back?

Should you take your site offline to patch?

Only if you cannot patch or contain the risk quickly, and Google’s own advice is that staying online in reduced form is better than going dark. In its guidance on pausing an online business, Google recommends keeping the site up with limited functionality, for example disabling a cart and showing a banner, because that “doesn’t change anything” for visibility in Search. Full disablement is described as a last resort.

For PHP2Shell the security advice was split in a way that matters. NBC News reported that US, European and British authorities recommended websites go offline temporarily until fixed, while CISA recommended patching. The UK’s National Cyber Security Centre said to consider taking systems offline if immediate remediation is not possible, and Cybersecurity Dive lists the Finnish government and the Dutch House of Representatives among those that disconnected sites.

A sensible order of operations for a small site:

1. Ask your host first. If the fixed PHP build is installed and workers were restarted, you do not need downtime.
2. Apply the partial mitigations from the PHP announcement if you cannot update yet, and add a firewall rule. They reduce exposure but are not a complete fix.
3. Turn off the risky features, such as uploads, while keeping the rest of the site up.
4. Go offline for a short, defined window only if the above is not possible, and plan the exit before you start.

What status code should maintenance mode return?

Return 503 Service Unavailable. It tells crawlers the outage is temporary, which is the one message you want to send. Every other common choice sends a worse one.

The table follows Google’s guidance on pausing a business. Two details are easy to miss. A 503 prevents Google from refreshing titles, descriptions, metadata and structured data, so do not stage SEO changes during an outage. And the Retry-After header should carry a best-effort duration or date, because a vague answer helps no one.

How long can a site stay offline?

Google gives no safe number, so plan in hours and a day or two, not weeks. Its guidance puts a 503 outage at one to two days, says full disablement should last “a few days at most”, and warns that closing a site completely, even for a few weeks, can have negative consequences. For server errors in general, its HTTP status code documentation says 5xx and 429 responses make Googlebot slow down, and that URLs which keep returning server errors are eventually dropped, with no timeframe given.

The robots.txt file has the most specific documented timings. Google’s robots.txt specification describes what happens when a robots.txt file exists but cannot be fetched: for the first 12 hours Google stops crawling the site but keeps retrying, for the next 30 days it uses the last good copy, and after 30 days of continuing errors it either treats the site as having no robots.txt or, if the site is generally unavailable, stops crawling while still asking for the file periodically.

How do you set up maintenance mode correctly?

Return the 503 from the web server, not from inside the application, so it works even when the application is the thing being patched. A minimal nginx pattern, to adapt and test, looks like this:

location = /robots.txt { try_files $uri =404; }
location / { return 503; }
error_page 503 @maintenance;
location @maintenance {
    root /var/www/maintenance;
    rewrite ^ /index.html break;
    add_header Retry-After 3600 always;
}

The first line keeps robots.txt answering normally. The second sends everything else to a 503. The named location serves a static notice page and adds the Retry-After header, here one hour, which you should change to your real estimate. Do not trust the label on a maintenance plugin or hosting toggle. Check the actual response from a terminal:

curl -I https://example.com/
curl -I https://example.com/robots.txt

The first should show 503 and a Retry-After header, and the second 200. Also load the notice page in a browser on a phone, and make it say what is happening, when you expect to be back and how to reach you. A page that returns 503 but tells a customer nothing still costs trust.

If your site is on a managed platform, ask the host how it implements maintenance mode and whether it returns 503. If you serve pre-built pages from a CDN, as in the static setups covered in Part 4, you may not need maintenance mode at all, because the pages can keep serving while you patch the parts behind them.

What about AI crawlers during downtime?

There is no published guidance to follow, so keep outages short and avoid changes that are slow to reverse. OpenAI’s crawler documentation explains how to control OAI-SearchBot, GPTBot and ChatGPT-User through robots.txt, and says search-related robots.txt changes can take about 24 hours to take effect. It does not describe how its bots treat 503 responses, retries or downtime. We did not find equivalent guidance elsewhere for this series, and we are not going to guess.

Two practical inferences, flagged as inferences:

• A page that returns 503 cannot be retrieved, so it cannot be quoted in an answer until it comes back. That is a cost of downtime, not a bug.
• Do not disallow AI crawlers in robots.txt as part of the outage. If those changes take about a day to reverse, a one-day outage could turn into a two-day absence. Our guides on robots.txt for AI crawlers and GPTBot vs OAI-SearchBot explain which agent controls what.

What should you check when you come back?

Confirm that every important URL returns 200 again, that robots.txt is unchanged and that nothing stayed in a half-maintenance state. Then watch recovery for a week.

Google says that after errors stop, it gradually increases the crawl rate, with no timeframe given. For larger sites, that recovery interacts with crawl budget. The technical SEO checklist for AI search is a good full review once you are stable.

Getting website maintenance mode right when you patch

The goal is to need maintenance mode rarely and to use it well when you do. Patch fast, use mitigations and a firewall to avoid downtime where you can, and when you must go offline, return a 503 with Retry-After, leave robots.txt alone and plan to be back in a day. Write the procedure down before you need it, because the next urgent patch will not wait for you to look up a header.

Ambeltek’s web development service includes setting up a hosting and deployment arrangement where routine updates do not require downtime. Our website maintenance tasks checklist covers the recurring work. The final part of the series steps back to the future of web development.