Temporarily disabling a website should usually mean serving a real HTTP 503 status code, not just showing a friendly “maintenance mode” page. A maintenance page can help users understand what is happening, but the server response matters more for search engines, monitoring tools, APIs, and browsers. Google Search Central states that a 503 response tells Googlebot the outage is temporary and that the page should be crawled again later [source: Google Search Central].
TLDR: Use HTTP 503 Service Unavailable when a website is temporarily offline, and add a clear maintenance page for humans. If a store gets 12,000 visits per day, a 2-hour shutdown may affect about 1,000 visitors, so the message must be clear and the downtime short. For example, “We are upgrading checkout and expect to return at 14:30 UTC” is far better than a blank error screen. Maintenance mode alone is fine only when it also sends a proper 503 response.
Maintenance mode and HTTP 503 are not the same thing
Maintenance mode is usually a feature in a CMS, hosting panel, plugin, or deployment tool. It shows visitors a custom page that says the site is under maintenance. The page may include a logo, message, support email, or estimated return time.
HTTP 503 Service Unavailable is a server response code. It tells clients that the server cannot handle the request right now, but the problem is temporary. This is the cleaner technical signal.
The catch is that many “maintenance mode” plugins show a nice page while still returning HTTP 200 OK. That is bad. A 200 response says, “This page is working.” If the content is actually a shutdown notice, search engines may treat that notice as the real page content. That can cause indexing trouble, ranking changes, or awkward snippets in search results.
When to use maintenance mode
Use maintenance mode when people will still reach the site and need a plain explanation. It is the human side of the shutdown.
A good maintenance page should include:
- A short reason: “We are upgrading our payment system.”
- An expected return time: “Expected back by 03:00 UTC.”
- A support option: email, status page, or help desk link.
- No blame: do not mention vendors, internal errors, or security details.
- Plain language: avoid vague lines like “Something went wrong.”
Maintenance mode is useful during planned work such as database migrations, server patching, redesign launches, DNS changes, or checkout updates. It lowers support requests because users are not left guessing.
Honestly, it feels like some plugins were built to make the page look pretty while ignoring the one thing that matters: the response code. Always test the status, not just the design.
When to use HTTP 503
Use HTTP 503 whenever the full site, key pages, or major functions are temporarily unavailable. This applies to planned downtime and unplanned incidents.
Common cases include:
- Planned maintenance: database updates, platform upgrades, server moves.
- High load: the server is overloaded and cannot respond safely.
- Emergency fixes: a serious bug needs fast repair.
- Security response: access is restricted during investigation.
- Dependency failure: payments, login, or inventory systems are down.
A 503 should not be used for content that is gone forever. If a page has been removed permanently, use 410 Gone or 301 Redirect where suitable. If a page was moved, use 301 or 302. If access is forbidden, use 403. Each code has a job.
Add the Retry-After header
A proper 503 response should include a Retry-After header when possible. This tells crawlers, browsers, and automated systems when to try again.
There are two common formats:
- Seconds:
Retry-After: 3600 - Date:
Retry-After: Wed, 21 Oct 2026 07:28:00 GMT
If you expect a one-hour outage, use Retry-After: 3600. If the return time is fixed, use a date. Do not set a fake short value if the work will take much longer. Monitoring systems may keep checking too often, and crawler behavior can become noisy.
What happens if you use the wrong status code?
If your maintenance page returns 200 OK, search engines may see the maintenance content as normal content. That is risky on important pages. A product page, service page, or homepage can temporarily look like a thin page with one message.
If the outage lasts only a few minutes, the risk is lower. If it lasts hours or days, the risk grows. Expect to waste time on cleanup if cached snippets, uptime alerts, and SEO reports start showing strange results.
If your site returns 404 Not Found during maintenance, the signal is worse. A 404 says the page is missing. That is not what you mean. For temporary downtime, 503 is the safer choice.
Best practice setup
A serious shutdown plan should combine both methods:
- Show a maintenance page so users understand the outage.
- Return HTTP 503 for unavailable pages.
- Add Retry-After with a realistic window.
- Keep static assets available if possible, so the page loads fast.
- Exclude health checks if your load balancer needs them.
- Test from outside your network before the work starts.
For a full-site shutdown, send 503 from the web server, reverse proxy, CDN, or application layer. Server-level handling is often cleaner because it works even if the application is unstable.
For a partial shutdown, be careful. If only checkout is down, you may serve 503 on checkout routes but keep product pages available. That is often better for users and search coverage.
How to test the response
Do not trust the browser alone. Browsers hide too much. Use a status checker, command line, or developer tools.
With curl, run:
curl -I https://example.comYou want to see something like:
HTTP/2 503
retry-after: 3600
content-type: text/htmlIf you see HTTP/2 200, your maintenance page is not sending the right signal. Fix that before the shutdown window begins.
What the maintenance page should say
The message should be short, calm, and useful. Users do not need technical detail. They need confidence.
A strong message looks like this:
We are performing scheduled maintenance.
The site is temporarily unavailable while we upgrade our checkout system. We expect to be back by 14:30 UTC. If you need help with an existing order, contact support@example.com.
A weak message looks like this:
Down for maintenance. Check back later.
The second version is too vague. It creates support tickets. It may also make users think the business is careless.
Security and access control
During maintenance, internal teams may still need access. Use IP allowlists, VPN rules, staging domains, or authenticated previews. Do not expose admin panels just because the public site is closed.
Also avoid putting sensitive information on the maintenance page. Do not say, “We are fixing a security breach” or “Our database migration failed.” Keep the message factual and limited.
How long is too long?
A 503 is meant for temporary downtime. Minutes or hours are normal. A day can be acceptable for major infrastructure work. Several days is a warning sign.
If downtime will be long, consider a lighter version of the site, a read-only mode, or a status page. For ecommerce, even read-only browsing can protect revenue. For SaaS products, keeping login status, documentation, and support pages online can reduce panic.
The safe rule
Use maintenance mode for people and HTTP 503 for machines. You usually need both. The page explains the interruption. The status code protects the technical meaning of the interruption.
Before taking the site offline, test the response code, add Retry-After, write a clear message, and set a return time you can meet. A temporary shutdown is normal. A sloppy shutdown is avoidable.
