WordPress maintenance mode plugins and when to use one

Most people searching for a maintenance mode plugin want one of two things. Some want a holding page up while they change something. Others want to get rid of a maintenance screen they never turned on. These are different problems, and WordPress uses a different mechanism for each.

Start by working out which one you have. The rest of this page covers choosing the right kind of plugin, checking that it tells search engines the right thing, and knowing when maintenance mode is the wrong tool.

What does a maintenance mode plugin do that WordPress doesn’t?

A plugin gives you a holding page you control, and it stays up until you switch it off. WordPress core only has a maintenance state tied to updates. When you update core, a plugin or a theme, WordPress writes a hidden file called .maintenance to the site root. Visitors then see “Briefly unavailable for scheduled maintenance. Check back in a minute.” The updater normally deletes the file when the update ends.

A plugin’s maintenance mode is a saved setting. LightStart’s documentation says its mode is switched on and off manually in the plugin settings. Other plugins work the same way. As a result:

• Deleting .maintenance does not turn off a plugin’s mode.
• Switching a plugin off does not fix a failed update.
• WP-CLI’s wp maintenance-mode activate, deactivate and status commands control core’s maintenance mode, not a plugin’s setting.

You can usually tell them apart by eye. Core shows one plain line of text. A plugin shows a designed page with its own heading, a logo, and sometimes a countdown or a signup form. The 503 response code explained article has a table of which screen comes from which source.

Why is my site stuck if I never installed a maintenance plugin?

An update was interrupted before WordPress could delete .maintenance. Common causes include closing the browser tab, a timeout, low memory or disk space, wrong file permissions, and updating many plugins at once. Kinsta’s documentation lists bulk updates as a risk.

WordPress’s Advanced Administration Handbook gives the fix. First, make sure no update is still running. Then delete .maintenance from the folder that holds wp-config.php, which is often public_html. You can do this with your host’s file manager or over SFTP. The file name starts with a dot, so you may need to turn on “show hidden files.”

Deleting the file only takes the screen down. Your plugin or core files may still be half-updated. Go to Dashboard, then Updates, and run whatever didn’t finish, one item at a time. Our guide to fixing a failed WordPress update covers what to do if the update fails again.

Core treats the file as expired once its timestamp is ten minutes old, according to the wp_is_maintenance_mode() reference. So if the screen lasts for hours, the file may not be the only cause. Common culprits are a cached copy of the 503 page, a site broken by the half-finished update, or a plugin’s own screen.

If the site keeps getting stuck, another plugin may be interfering with the updater. In one WordPress.org support thread, updates stalled again and again, and clearing caches didn’t help. A moderator traced it to a starter-templates plugin that was blocking updates. The fix was to deactivate that plugin, update it, reactivate it, and then update everything else. Retrying the same bulk update without finding the cause just recreates the lock.

Which kind of maintenance plugin fits the job?

Pick the lightest tool that does the job. Plugins in this category range from a single switch to a full page builder, and the extra weight only pays off when you use it. Install bands below are from the WordPress.org directory.

The job	What you need	Example from the directory
A 20-minute update window	An on/off switch and a 503 status	Slim Maintenance Mode (10,000+ installs): no settings page, and only administrators see the site
A branded holding page for an established business	A logo, a message and access rules	Maintenance by WebFactory (1,000,000+): a 503 status and a temporary page you edit in its settings
A client reviewing work while the public sees a notice	A bypass by role or link	CMP by NiteoThemes (200,000+), recommended in r/Wordpress threads for its client bypass link
A pre-launch page with a signup form	A page builder and form handling	LightStart (400,000+), described on WordPress.org as a drag-and-drop page builder

Practitioners in WordPress.org and Reddit threads keep asking for the same three things: a plain switch for update windows, preview access for clients, and the option to use an existing WordPress page as the holding page. The third request usually ends with someone suggesting custom code. Test before you trust any feature list, including the one above. Bypass rules and paid tiers change between versions.

If you are writing the message itself, our coming soon text examples cover the difference between a launch announcement and a notice that the site is down.

Why does the plugin look broken when it isn’t?

Usually there are two reasons: you are logged in, or a cache is serving an old copy.

You are logged in. Administrators bypass the holding page, and on some plugins any logged-in user does. Owners who test while signed in often decide the plugin “won’t publish.” Test in a private window or on another device. Note whether your plugin’s bypass applies to administrators only or to every logged-in account. On a store, every customer who logs in counts as a logged-in user.

A cache is serving the old page. This can be a page cache plugin, your host’s server cache or a CDN. It explains both “I turned it on and nothing happened” and “I turned it off and visitors still see it.” In one resolved WordPress.org thread, the maintenance page stayed up after the plugin was deleted, and there was no .maintenance file. The cause was caching. LightStart’s FAQ advises turning off cache plugins while its mode is on, or clearing the cache after every change. Purge every layer each time you switch the mode on or off.

On LightStart, check the exclusions too. Its documentation says exclusions match parts of URLs, so excluding / matches every page and opens the whole site. If you use a custom login URL, add it to the exclusions, or you may lock yourself out of the login page.

What should the page tell search engines?

Visitors read the page. Search engines read the status code. A page can look like a maintenance notice and still return 200 OK. Search engines then treat it as the site’s real content.

Google Search Central gives specific guidance for closures:

• If the site is fully down for one or two days, return a 503 with a best-effort Retry-After header and show a short, helpful page.
• For longer closures, keep the site online and limit what it does, for example by disabling the cart.
• Don’t block the site in robots.txt, return 403, 404 or 410, or use noindex to signal a temporary closure.

A coming-soon page for a site that has never launched is a different case. It is common practice to serve it with a 200 status so it can be indexed as the real front page. Google’s closure guidance covers existing sites, not pre-launch pages.

Check the response, not the preview. Open your browser’s developer tools, select the Network tab, and load a deep page (not the homepage) while logged out. Or run:

curl -I https://example.com/some-page/

The first line should read HTTP/2 503 (or HTTP/1.1 503). Look for a retry-after line too. LightStart’s changelog includes a fix for a 503 problem in its selected-page mode, which is a good reminder that a correct-looking screen doesn’t prove a correct status.

How do you use maintenance mode around plugin updates?

On a simple brochure site, you often don’t need a plugin. Core already blocks visitors for the few seconds each update takes. On a store, or any site where a half-updated page could take a payment or a booking, use maintenance mode on purpose.

WooCommerce’s update guide sets out the order:

1. Take a current backup.
2. Test the updates on a staging copy first.
3. Put the live store in Coming Soon mode so customers can’t check out while files and the database change.
4. Run updates one at a time and wait for each to finish before refreshing, navigating away or starting the next.
5. Run the WooCommerce database update when you’re prompted.
6. Test the key store workflows: cart, checkout, and the payment method you use most.
7. Reopen. If anything is wrong, keep checkout closed, restore from the backup if needed, and troubleshoot on staging.

Step 7 is the one people skip. When the holding page comes down, all you have confirmed is that it’s gone. Load the checkout as a customer, then clear caches so nobody gets served the maintenance page.

Not everyone wants to run this routine every month. SiteSelf handles plugin and core updates on request through chat: before it starts, it says what is about to change and whether that can be undone, and afterwards it reports what it checked on the live page.

When is maintenance mode the wrong tool?

A maintenance plugin is meant for short, planned pauses that visitors will notice. It doesn’t fit these jobs:

• Weeks of rebuild work. In an r/woocommerce thread, practitioners advised building on staging and going live in a short window. Running a store behind a holding page for weeks risks search visibility. Copying a staging database over the live one can also wipe out orders placed in the meantime.
• A month-long holiday closure. Use catalog mode, a notice, or mark products out of stock. This matches Google’s advice to limit functionality. Replies in the same community strongly advised against pointing DNS somewhere else.
• Keeping a dev site out of Google. “Discourage search engines” relies on robots.txt and isn’t foolproof. A staging site needs real access control.
• Migrations and server-level risk. A plugin only runs once PHP and WordPress have loaded. If the change can break WordPress itself, a static HTML page or a rule on the server is more reliable.

Stop and call your host if the maintenance screen turns into “Error establishing a database connection” or 500-range errors that keep coming back. Learn WordPress’s debugging material for site owners treats those as signs of a wider server problem, not a plugin setting.