How to show a "down for maintenance" message on your website

When to use this

Use maintenance mode for planned work that would leave the site broken while you work: a theme change, a large plugin update, a database import or the final switch of a website migration. For small edits, a staging copy is better than taking the live site down.

If your site is showing a maintenance or 503 message you did not switch on, follow fixing 503 Service Unavailable instead.

Do it the right way: 503, not 200

A maintenance page should return HTTP status 503 Service Unavailable, ideally with a Retry-After header saying when to come back. Google's documentation explains that 5xx errors make its crawlers slow down temporarily, and that crawling speeds up again once the server returns success codes. A maintenance page that returns 200 looks like real content and may be indexed in place of your pages.

Avoid redirecting every URL to a maintenance page. A redirect tells search engines the content has moved.

Write a useful maintenance message

Keep it short and specific. Include what is happening, when it ends in IST, and how to reach you meanwhile:

<h1>We are updating our website</h1>
<p>Our site is down for planned maintenance from 11:00 pm to 1:00 am IST
on Sunday. Orders placed before 11:00 pm are not affected.</p>
<p>Need help now? Call [your phone number] or email care@yourbusiness.in.</p>

Put the styling inside the file. While maintenance mode is on, your normal images and stylesheets may also return 503.

Option 1: WordPress

WordPress has a built in maintenance mode that it uses during updates. Its developer reference shows that it returns a 503 status with Retry-After: 600 and the message "Briefly unavailable for scheduled maintenance". A file named maintenance.php in wp-content replaces that message with your own page.

That built in mode is meant for updates of a few minutes, not for longer planned work. For a longer window, use a reputable maintenance mode plugin and check in its settings that it sends a 503 status, lets logged in administrators see the site, and lets you set an end time. Switch it off from the plugin when you finish.

Option 2: .htaccess on Apache or LiteSpeed hosting

This works for any site on hosting that reads .htaccess files, including WordPress, and lets you keep working from your own connection.

1. Find your public IP address by searching "what is my IP" from the office or home connection you will work from.

2. Upload your maintenance.html page to the site's root folder (usually public_html). See uploading files with File Manager or FTP.

3. Download a copy of your current .htaccess file as a backup.

4. Add these lines at the top of .htaccess, above any # BEGIN WordPress block, replacing the example IP with yours:

   # Maintenance mode: everyone except one IP gets a 503 and maintenance.html
   ErrorDocument 503 /maintenance.html
   RewriteEngine On
   RewriteCond %{REMOTE_ADDR} !^203\.0\.113\.25$
   RewriteCond %{REQUEST_URI} !^/maintenance\.html$
   RewriteRule ^ - [R=503,L]
   <IfModule mod_headers.c>
     Header always set Retry-After "7200"
   </IfModule>
   

5. Test from mobile data: you should see the maintenance page, while your own connection still shows the site.

Apache's documentation confirms that an R flag with a status outside the 3xx range returns that status and uses any configured ErrorDocument. Retry-After here is in seconds, so 7200 means two hours. Set it to roughly your planned window.

Option 3: Nginx on a VPS

On a VPS running Nginx, create a flag file to switch maintenance on and off without editing the configuration each time. Inside the site's server block:

if (-f /var/www/maintenance/on) { return 503; }
error_page 503 @maintenance;

location @maintenance {
    root /var/www/maintenance;
    add_header Retry-After 7200 always;
    rewrite ^ /maintenance.html break;
}

Put maintenance.html in /var/www/maintenance/, run sudo nginx -t and reload Nginx. Create the empty file /var/www/maintenance/on to start maintenance and delete it to finish. Allowing your own IP needs extra rules, so test changes on a staging copy where you can.

How to confirm it worked

Check the status code from a terminal or an online header checker:

curl -sI https://yourbusiness.in/ | head -n 5

During maintenance you should see HTTP/2 503 (or HTTP/1.1 503) and a retry-after line. Afterwards, remove the lines or plugin and confirm the site returns 200. If you use an uptime monitor, pause it during the window so it does not alert everyone.

If it still fails

If the site shows a 500 error after editing .htaccess, restore your backup copy, then check the lines for typing mistakes. If you are still stuck, open a support ticket with the domain, the exact lines you added, the time you made the change in IST and what visitors see.