How to create a maintenance page for your website

A maintenance page gives visitors a controlled response during a short full-site outage such as planned infrastructure work, a platform cutover, or an emergency rollback window. It replaces broken forms, application errors, and half-rendered templates with a single message that says the site is temporarily unavailable and where to look next.

For this page to do its job, the response has to come from a lightweight standalone document and the affected public URLs have to return 503 Service Unavailable instead of normal content. Current Google Search guidance still treats a whole-site 503 response as the short-outage status for an emergency shutdown, and the page is stronger when it also sends a best-effort Retry-After header and keeps robots.txt reachable.

Use this pattern only when the site really needs to stop serving normal pages for a short window. If only checkout, login, or another bounded feature is affected, keep the rest of the site online and limit that function instead of hiding the whole site behind a maintenance page.

Steps to create a maintenance page for your website:

Decide whether the maintenance response should cover the whole site or only the affected public URLs, and leave status, support, admin, or login paths outside the rule when the platform allows it.

Google's current documentation treats a whole-site 503 shutdown as a short measure for about 1-2 days, not as a multi-week placeholder.
Write a short message that says the site is temporarily unavailable, gives the expected return time or next update window, and points visitors to the best status or support contact.

Do not promise an exact recovery time unless the team can actually meet it.
Save the page as static HTML with no external dependencies so it can still load when the normal application stack is unavailable.
```
<!doctype html>
<title>Scheduled maintenance</title>
<h1>Scheduled maintenance</h1>
<p>The website is temporarily unavailable.</p>
<p>Expected return: 02:00 UTC.</p>
<p>Status page: status.example.com</p>
```
Keep the file self-contained so the maintenance page does not need the failing app, CDN bundle, or third-party script to render.
Publish the file at a path that the web server, reverse proxy, CDN, or CMS maintenance feature can serve directly even when the main app is bypassed or down.
A common pattern is a file such as
```
/maintenance.html
```
outside the application's template pipeline.
Configure the maintenance rule to return that page with 503 Service Unavailable and a best-effort Retry-After value on every affected public URL.
```
HTTP/1.1 503 Service Unavailable
Retry-After: 3600
Content-Type: text/html
```
Do not use 200 OK, 403 Forbidden, 404 Not Found, 410 Gone, or page-level noindex as the temporary shutdown signal, because they tell crawlers something different from a short maintenance outage.
Keep robots.txt publicly reachable during the outage and let any CSS, images, or fonts used by the maintenance page load normally.
Related: How to create a robots.txt file for your website
Do not return the maintenance page or a 503 response for
```
/robots.txt
```
, because that blocks normal crawl control checks.
Open an affected URL in a private browser window and confirm the visitor sees the maintenance message without login prompts, redirect loops, or missing text.

Use a browser path that is not already authenticated so the page is checked as an ordinary visitor instead of as an admin session.
Run curl -I https://example.com/ on one affected URL and confirm the live response is a temporary outage with the expected headers.
```
503 Service Unavailable
Retry-After: 3600
Content-Type: text/html
```
Retry-After can be either seconds or an HTTP date.
Run curl -I https://example.com/robots.txt and confirm robots.txt still returns normal text instead of the maintenance page.
```
200 OK
Content-Type: text/plain
```
This check catches broad maintenance rules that accidentally intercept the root crawl policy file.
Remove the maintenance rule as soon as the site is ready and confirm the same public URL returns its normal 200 OK response again.
```
200 OK
Content-Type: text/html
```
If a CDN or reverse proxy keeps serving the stale maintenance page after recovery, clear or bypass that cache before declaring the site back online.

Author: Mohd Shakir Zakaria
Mohd Shakir Zakaria is a cloud architect with deep roots in software development and open-source advocacy. Certified in AWS, Red Hat, VMware, ITIL, and Linux, he specializes in designing and managing robust cloud and on-premises infrastructures.