WordPress Maintenance Mode: Enable and Customize

You launch a WooCommerce update on a Tuesday morning. For 47 seconds, your customers see a blank page. Three of them abandon their cart. One sends you an email to report that "the site is broken." Sound familiar?

WordPress maintenance mode exists to prevent this kind of situation. Instead of exposing your visitors to a half-functional site while you work on it, you display a temporary page that explains what's happening -- and sends an HTTP 503 code to search engines telling them to come back later.

In this guide, we cover everything: activation with or without a plugin, page customization, SEO impact, and special cases like WooCommerce or Multisite. Whether you're comfortable with functions.php or prefer a turnkey plugin, you'll find the method that suits you.

What is WordPress maintenance mode?

Definition and internal workings

When WordPress updates itself (core, theme, or plugin), it automatically creates a .maintenance file at the root of your installation. This file contains an $upgrading variable with a Unix timestamp. As long as this file exists, WordPress intercepts all requests via the wp_maintenance() function in wp-includes/load.php and displays the default message: "Briefly unavailable for scheduled maintenance. Check back in a minute."

The server then returns an HTTP 503 (Service Temporarily Unavailable) code with a Retry-After header. This is the native behavior -- no plugin required. The problem is that this default page is ugly, not customizable, and doesn't exactly reassure your visitors.

That's where manual methods and plugins come in: they let you control when maintenance mode activates, what your visitors see, and who can still access the site (administrators, editors, logged-in customers).

When should you activate maintenance mode?

You don't need to trigger it for every small CSS tweak. However, there are situations where it's essential:

Major updates -- WordPress core (5.x to 6.x), main theme change, or bulk update of critical plugins (WooCommerce, Elementor, Yoast). If an update modifies the database structure, a visitor loading a page at the wrong time can trigger a fatal error.
Site redesign -- Design change, menu restructuring, content migration. Your visitors don't need to see a half-assembled site.
Security issues -- Compromised site, urgent vulnerability to patch, malware cleanup. Maintenance mode isolates the site while you work.
Server or domain name migration -- DNS takes time to propagate. During the transition, maintenance mode prevents some visitors from seeing the old site and others the new one (or nothing at all).
Sensitive WooCommerce changes -- Payment gateway switch, shipping rule changes, bulk price updates. It's better to shut down shop access for 10 minutes than to risk an order with the wrong price.

For minor adjustments (typo fix, blog post addition, widget modification), a staging environment remains the best option. You test, you validate, you deploy -- without touching the production site.

Maintenance mode vs "coming soon" page vs password protection

These three options are often confused, but they don't serve the same purpose:

	Maintenance mode	"Coming soon" page	Password protection
Purpose	Temporary technical intervention	Prepare a launch	Restrict access to content
HTTP code	503 (come back later)	200 (normal page)	401 or 200
Typical duration	Minutes to a few hours	Days to weeks	Unlimited
SEO impact	None if < 48h	The page gets indexed	Variable
Logged-in visitors	Admins exempted	Admins exempted	Access via password

The critical point is the HTTP code. A 503 tells Google: "the site works normally, it's just temporarily unavailable, don't touch my indexing." A 200 on a coming soon page, on the other hand, can replace your content in the index if it stays up too long. And if you accidentally return a 404 or 500 during maintenance, Google could deindex your pages.

Activating maintenance mode with a plugin

If you don't want to touch code, a plugin is the quickest way to put your site in maintenance. In a few clicks, you get a customizable page with a countdown, a signup form, and a professional design.

SeedProd: step-by-step setup

SeedProd is the most widely used plugin for this use case. The free version is sufficient for basic maintenance mode. Here's how to set it up:

In your WordPress dashboard, go to Plugins > Add New and search for "SeedProd".
Install and activate the plugin.
Navigate to SeedProd > Pages in the sidebar menu.
Under the "Maintenance Mode" section, click Set up a Maintenance Mode Page.
Choose a template from the available options (or start from a blank page).
Customize your page with the drag-and-drop builder: add your logo, an explanatory message, your social media links, and optionally a contact form or newsletter signup.
In the Page Settings > SEO tab, verify that the returned HTTP code is 503. This is the default setting, but it's worth confirming.
Click Save, then go back to SeedProd > Pages.
Toggle the "Maintenance Mode" switch to Active.

Your site now displays the maintenance page for all non-logged-in visitors. WordPress administrators see the site normally -- allowing you to continue working.

An often-overlooked point: SeedProd also handles URL exclusions. If you have a WooCommerce order status page or a webhook that needs to remain accessible, you can exclude it from maintenance mode in the advanced settings. This prevents blocking critical processes during the intervention.

Alternatives: WP Maintenance Mode, LightStart, and CMP

SeedProd isn't the only option. Here are three other plugins that get the job done, each with its own strengths:

WP Maintenance Mode & Coming Soon (by Suspended Starter) -- This is the veteran. Over one million active installations. It offers a visual editor, countdown timer, subscription form, and Google Analytics integration. The standout feature: it lets you define which WordPress roles are allowed to access the site (not just admins, but also editors or authors if needed). The free version is generous.

LightStart -- Formerly known as "WP Maintenance Mode" (not to be confused with the previous one). A lightweight plugin, under 100 KB. It does the essentials: customizable maintenance page, 503 code, page exclusion by URL. It doesn't have a drag-and-drop builder, but if you're looking for a minimalist plugin that won't slow down your site, it's a solid choice.

CMP -- Coming Soon & Maintenance Plugin -- Its main strength: over 120 ready-to-use maintenance themes. It also offers a "coming soon" mode separate from maintenance mode, with distinct SEO settings (code 200 for coming soon, 503 for maintenance). Handy if you regularly switch between the two.

How to choose the right plugin?

It depends on your priorities:

Advanced design and visual builder > SeedProd
Fine-grained role and permission management > WP Maintenance Mode
Lightweight and performant > LightStart
Ready-to-use template library > CMP

Whichever plugin you choose, always check two things before activating maintenance mode: the returned HTTP code (503, not 200 or 302) and the fact that administrators can still access the site. Test in private/incognito browsing to see what your visitors actually see.

Activating maintenance mode without a plugin

Plugins add weight to your installation. If you're comfortable with an FTP client or file manager, manual methods are cleaner and leave no trace once maintenance is over.

Via the .maintenance file (native WordPress method)

This is the most direct method. WordPress checks for this file on every request. If it exists and the timestamp hasn't expired, maintenance mode activates automatically.

Create a .maintenance file at the root of your WordPress installation (at the same level as wp-config.php) with this content:

<?php
$upgrading = time();

That's it. WordPress now intercepts all requests and displays the default message "Briefly unavailable for scheduled maintenance." The server returns a 503 code with a Retry-After: 600 header (10 minutes).

To deactivate maintenance mode, simply delete the file via FTP or your file manager (cPanel, Plesk, etc.).

Two things to know about this method:

WordPress automatically deletes the .maintenance file after 10 minutes (600 seconds) if the $upgrading variable contains an expired timestamp. If your maintenance takes longer, update the timestamp or use a different method.
The displayed page is WordPress's default message. To customize it, you can create a maintenance.php file in the /wp-content/ folder. WordPress will automatically load it instead of the default message. We detail this customization in the next section.

Via functions.php (custom snippet)

This method offers more control. You decide who sees the maintenance page, what message is displayed, and what HTTP code is returned.

Add this code to your child theme's functions.php file (not the parent theme, or you'll lose everything on the next update):

function activer_mode_maintenance() {
    if ( ! current_user_can( 'manage_options' ) ) {
        wp_die(
            '<h1>Site under maintenance</h1><p>We are performing an update. Please check back in a few minutes.</p>',
            'Maintenance',
            array( 'response' => 503 )
        );
    }
}
add_action( 'template_redirect', 'activer_mode_maintenance' );

This snippet does three things:

It checks whether the current user has the manage_options capability (reserved for administrators).
If not, it displays a maintenance message using wp_die().
It returns an HTTP 503 code.

You can replace manage_options with edit_posts if you also want to allow editors and authors to access the site. WordPress's current_user_can() function accepts any capability defined in the roles system.

To deactivate: remove the snippet from functions.php or comment it out.

Via .htaccess (IP restriction)

If you want only your IP address to be able to access the site, the .htaccess method is drastic and effective. It operates at the Apache server level, before WordPress even loads.

Add these lines at the beginning of your .htaccess file (before the WordPress rules):

RewriteEngine On
RewriteCond %{REMOTE_ADDR} !^123\.456\.789\.012$
RewriteCond %{REQUEST_URI} !^/maintenance\.html$
RewriteRule ^(.*)$ /maintenance.html [R=503,L]

Replace 123.456.789.012 with your public IP address (type "what is my IP" in Google to find it). Then create a maintenance.html file at the root of your site with your custom maintenance page.

This method has the advantage of blocking all traffic before PHP even executes. Your server uses zero resources for visitors in maintenance. However, it only works on Apache servers. If you're on Nginx, the equivalent configuration is done in the server's virtual host file -- not in .htaccess.

Warning: if your ISP assigns you a dynamic IP, you'll need to update the rule every time it changes. Check your IP before locking yourself out.

Via WP-CLI (command line)

If you have SSH access to your server and WP-CLI is installed, this is the fastest method:

# Activate maintenance mode
wp maintenance-mode activate
 
# Check status
wp maintenance-mode status
 
# Deactivate
wp maintenance-mode deactivate

Three commands, no files to edit, no FTP. WP-CLI creates and deletes the .maintenance file for you. This is the preferred method in automated deployment environments (CI/CD, update scripts) because it integrates into any pipeline.

The wp maintenance-mode command has been available since WP-CLI 2.6.0. If your version is older, update it with wp cli update.

Customizing the maintenance page

WordPress's default page -- white text on a white background with "Briefly unavailable for scheduled maintenance" -- reassures no one. Your visitors deserve better. Here's how to create a maintenance page that does the job.

Creating a custom maintenance.php template

WordPress looks for a maintenance.php file in the /wp-content/ folder before displaying its default message. If this file exists, it's what gets displayed. No plugin required.

Create the file /wp-content/maintenance.php with this base template:

<?php
header( 'HTTP/1.1 503 Service Temporarily Unavailable' );
header( 'Retry-After: 3600' );
header( 'Content-Type: text/html; charset=utf-8' );
?>
<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>Maintenance in Progress - Your Site</title>
    <style>
        * { margin: 0; padding: 0; box-sizing: border-box; }
        body {
            font-family: -apple-system, BlinkMacSystemFont, 'Segoe UI', Roboto, sans-serif;
            background: #0f172a;
            color: #e2e8f0;
            display: flex;
            align-items: center;
            justify-content: center;
            min-height: 100vh;
            padding: 2rem;
        }
        .container { max-width: 540px; text-align: center; }
        .logo { width: 120px; margin-bottom: 2rem; }
        h1 { font-size: 1.75rem; font-weight: 700; margin-bottom: 1rem; color: #f8fafc; }
        p { font-size: 1.1rem; line-height: 1.7; margin-bottom: 1.5rem; color: #94a3b8; }
        .socials a {
            display: inline-block; margin: 0 0.5rem; color: #64748b;
            text-decoration: none; transition: color 0.2s;
        }
        .socials a:hover { color: #f8fafc; }
    </style>
</head>
<body>
    <div class="container">
        <img src="/wp-content/uploads/logo.svg" alt="Logo" class="logo">
        <h1>Maintenance in Progress</h1>
        <p>We're improving your experience. The site will be back in a few moments.</p>
        <div class="socials">
            <a href="https://twitter.com/youraccount">Twitter</a>
            <a href="https://linkedin.com/company/youraccount">LinkedIn</a>
        </div>
    </div>
</body>
</html>

This template does the minimum correctly: it sends the right HTTP headers (503 + Retry-After), it's responsive, it loads zero external resources (no Google Fonts, no CDN), and it displays instantly. Adapt the colors, logo, and links to your brand guidelines.

The Retry-After: 3600 header tells search engines to come back in one hour. Adjust this value in seconds based on your estimated maintenance duration.

Elements to include on your maintenance page

A good maintenance page doesn't just say "come back later." It should contain:

A logo -- So the visitor knows they're in the right place and the site hasn't been hacked.
A clear, honest message -- "We're performing an update" is better than "We're building something extraordinary." No vague promises.
An estimated duration -- Even an approximate one. "The site will be back in about 30 minutes" is more useful than "Soon."
Links to your social media -- If someone needs to contact you during maintenance, your Twitter/X or LinkedIn profiles are the fallback channel.
A contact form or email address -- For urgent cases (customer with an order in progress, partner with a deadline).
A countdown timer (optional) -- Effective if you know the exact duration. But if the maintenance runs over, a countdown stuck at zero looks bad. Use this only if you're confident in your timing.

What to avoid:

Heavy animations or background videos. Your page should load in under one second, even on a slow mobile connection.
A newsletter signup form on a maintenance page for an existing site. That's relevant for a "coming soon" page, not for maintenance.
Messages that try too hard to be cute ("Our hamsters are spinning the servers faster!"). Your visitors want to know when the site comes back, not read jokes.

Managing redirects from the maintenance page

By default, maintenance mode displays the same page for all URLs. But some URLs need to stay accessible:

/wp-admin/ and /wp-login.php -- So you can log in and work.
Webhooks -- If your site receives payment notifications (Stripe, PayPal), shipping updates, or other third-party service callbacks, these endpoints must remain open. Otherwise, you risk losing transactions.
Legal pages -- Depending on your jurisdiction, your legal notices and privacy policy must remain accessible even during maintenance.
Internal REST APIs -- If other services depend on your WordPress API, cutting their access breaks the entire chain.

If you're using a plugin like SeedProd, exclusions are configured in the plugin settings. With the manual method (functions.php), add conditions to your snippet:

function activer_mode_maintenance() {
    if ( current_user_can( 'manage_options' ) ) return;
    if ( strpos( $_SERVER['REQUEST_URI'], '/wp-admin' ) !== false ) return;
    if ( strpos( $_SERVER['REQUEST_URI'], '/wp-json' ) !== false ) return;
    if ( strpos( $_SERVER['REQUEST_URI'], '/wc-api' ) !== false ) return;
 
    wp_die(
        '<h1>Maintenance in progress</h1><p>Please check back in a few minutes.</p>',
        'Maintenance',
        array( 'response' => 503 )
    );
}
add_action( 'template_redirect', 'activer_mode_maintenance' );

This code exempts admins, the back office, the WordPress REST API, and the WooCommerce API. Add more URIs as needed.

Deactivating maintenance mode and unblocking a site

Activating maintenance mode is easy. Deactivating it is too -- in theory. But sometimes WordPress gets stuck in maintenance after an interrupted update. Here's how to handle both cases.

Normal deactivation

The method depends on how you activated maintenance mode:

Plugin (SeedProd, WP Maintenance Mode, etc.) -- Go back to the plugin settings and toggle the switch to "Disabled" or "Off." Test in private/incognito browsing to verify the maintenance page is gone.
.maintenance file -- Connect via FTP (FileZilla, Cyberduck) or your file manager (cPanel, Plesk) and delete the .maintenance file at the WordPress root.
functions.php snippet -- Edit your child theme's functions.php file and remove or comment out the maintenance mode code.
.htaccess rules -- Remove the RewriteCond/RewriteRule lines you added and save.
WP-CLI -- Run wp maintenance-mode deactivate via SSH.

In all cases, clear your site's cache (WP Rocket, LiteSpeed Cache, Varnish, or your host's cache) after deactivation. Otherwise, the cached maintenance page may continue to appear for some visitors for several minutes.

Site stuck in maintenance mode: diagnosis and solutions

This is a common problem. You launch an update, the connection drops or the server times out, and your site stays stuck on "Briefly unavailable for scheduled maintenance. Check back in a minute." even after 30 minutes.

Here are the possible causes and solutions, in the order you should follow:

1. The .maintenance file wasn't deleted

This is the cause in 90% of cases. WordPress creates this file at the start of each update and deletes it at the end. If the update is interrupted (PHP timeout, memory error, network disconnect), the file remains.

Solution: connect via FTP or the file manager and delete the .maintenance file in the WordPress root directory (where wp-config.php and wp-content/ are located). The site comes back immediately.

2. A plugin causes a conflict on restart

The .maintenance file no longer exists, but the site still shows an error? A partially updated plugin can cause a fatal error on load.

Solution: rename the /wp-content/plugins/ folder to /wp-content/plugins_disabled/ via FTP. This deactivates all plugins at once. If the site comes back, rename the folder back and reactivate plugins one by one from the dashboard to identify the culprit.

3. PHP memory limit exceeded

Updates consume more memory than normal operation. If your host allocates 64 MB or 128 MB of PHP memory, a heavy update can fail silently.

Solution: add this line to wp-config.php, before the /* That's all, stop editing! */ line:

define( 'WP_MEMORY_LIMIT', '256M' );

Then relaunch the update manually from Dashboard > Updates.

4. Corrupted WordPress core files

If a WordPress core update was interrupted, some files may be incomplete or missing.

Solution: download the latest version of WordPress from wordpress.org, extract the archive, and upload the wp-admin/ and wp-includes/ folders via FTP, overwriting the existing ones. Don't touch wp-content/ (that's where your themes, plugins, and uploads are).

5. Server cache keeps displaying the maintenance page

Your site works, but some visitors still see the maintenance page. The issue is caching -- either application cache (WP Rocket, W3 Total Cache) or server cache (Varnish, Cloudflare).

Solutions:

Purge the cache from the WordPress cache plugin.
If you use Cloudflare, go to Caching > Configuration > Purge Everything.
For Varnish, purge via your host's panel or SSH with varnishadm "ban req.url ~ /".
As a last resort, add a URL parameter ?nocache=1 to verify the site works properly without cache.

Preventing maintenance lockouts

A few habits to avoid ending up in this situation:

Update your plugins one at a time, not all at once. If one causes a problem, you'll know which one.
Increase your server's PHP timeout to at least 300 seconds for updates (max_execution_time parameter in php.ini or through your host).
Make a complete backup (files + database) before each major update. UpdraftPlus, BlogVault, or your host's backup tools will do the job.
Use a staging environment to test updates before applying them to production. Most managed hosts (Kinsta, WP Engine, Cloudways) offer this feature.

Maintenance mode and SEO: protecting your rankings

A poorly configured maintenance mode can cost you Google positions. A properly configured one leaves no trace in indexing. The difference comes down to three factors: the HTTP code, the duration, and communication with search engines.

The HTTP 503 code and why it matters

The HTTP code your server returns during maintenance determines how Google handles your site:

503 (Service Temporarily Unavailable) -- "The site is temporarily unavailable, come back later." Google keeps your pages in its index and doesn't change your rankings. This is the correct code for maintenance.
200 (OK) -- "Everything's fine, here's the content." If your maintenance page returns a 200, Google may index that page instead of your real content. On a 500-page site, that potentially means 500 pages replaced by "Maintenance in progress" in the index.
404 (Not Found) -- "This page doesn't exist." Google will eventually deindex your pages if they return a 404 for too long.
302 (Temporary Redirect) -- "Go look elsewhere temporarily." Less problematic than a 200, but not as explicit as a 503.

The 503 should also include a Retry-After header telling crawlers when to come back. Example: Retry-After: 3600 (1 hour). Without this header, Googlebot may come back every few minutes and accumulate 503 errors in Search Console. With the header, it waits patiently.

Check the returned code before publishing your maintenance. Open your terminal and run:

curl -I https://yoursite.com

You should see HTTP/1.1 503 Service Temporarily Unavailable in the response. If you see 200 OK, your configuration is wrong.

Robots.txt, sitemaps, and RSS feeds during maintenance

Common mistake: blocking robots in robots.txt during maintenance. Don't do this. If you add Disallow: / to robots.txt, Google won't be able to crawl your site -- but it also won't know you're returning a 503. The result: it might interpret the block as permanent and reduce crawl frequency even after maintenance ends.

Leave robots.txt unchanged. The 503 code already does the job.

For sitemaps: keep them accessible. They cause no issues during maintenance. When Google visits the URLs listed in the sitemap and receives a 503, it understands it's temporary. However, if the sitemap itself also returns a 503, Googlebot might stop checking it.

RSS feeds follow the same logic. If your RSS feed is inaccessible, aggregators (Feedly, NewsBlur) will show an error to your subscribers. Exempt your feed URL in the maintenance mode configuration.

Communicating with Google via Search Console

If your maintenance lasts more than a few hours, be proactive:

Log into Google Search Console.
Go to URL Inspection and test your homepage. Verify that the returned code is 503.
If you notice a spike in 503 errors in the Coverage report after maintenance, don't panic. This is normal, and the errors will disappear during the next crawl once the site is back online.

Google has officially confirmed that a 503 lasting less than two days has no impact on rankings. Beyond 48 continuous hours, the risk increases: Googlebot might consider the site permanently down and start demoting pages.

If your maintenance exceeds this window (complex migration, major redesign), consider keeping at least a few key pages accessible in read-only mode, or setting up a temporary public staging environment.

Purging cache and preventing conflicts

Cache plugins are the number one source of SEO problems related to maintenance mode. Here's the typical scenario:

You activate maintenance mode. Your maintenance page displays correctly.
WP Rocket (or LiteSpeed Cache, W3 Total Cache) caches the maintenance page with a 200 code (because the cache intercepts the request before the maintenance plugin).
You deactivate maintenance mode. Your site is back.
But the cache keeps serving the old maintenance page to visitors -- and to Googlebot.

To avoid this:

Purge the cache before activating maintenance mode (to clear cached pages).
Purge the cache after deactivating it (to remove the maintenance page from cache).
If you use the .htaccess method or a custom maintenance.php, the application cache doesn't come into play (the redirect happens at the server level). This is an advantage of these methods over plugins.
If you have a CDN (Cloudflare, Fastly, KeyCDN), purge the CDN cache as well. Otherwise, the CDN will continue serving the cached version, whether it's the maintenance page or the old version of the site.

A simple test after maintenance ends: check your site from a browser you've never used (or in private/incognito browsing, from a different network -- your phone's Wi-Fi, for example). If the maintenance page still appears, it's a caching issue.

Advanced cases

Standard guides cover maintenance mode for a blog or brochure site. But if you manage a WooCommerce store, a Multisite network, or an automated deployment, the logic changes.

Maintenance mode on WooCommerce

Putting an online store in maintenance isn't trivial. Unlike a blog where the worst-case scenario is a visitor who can't read an article, a WooCommerce store can lose money every minute.

Before activating maintenance mode on a WooCommerce site, consider these points:

Orders being processed -- Check that no payment is awaiting confirmation. Gateways like Stripe and PayPal send confirmation webhooks (IPN for PayPal, webhooks for Stripe). If your site is in maintenance and these endpoints are blocked, the order can remain in "Pending" status indefinitely. Exempt the URLs /wc-api/ and /?wc-api= in your configuration.
Transactional emails -- WooCommerce sends order confirmation, shipping notification, and other emails. If maintenance mode blocks the WordPress cron (wp-cron.php), these emails won't be sent. Exempt wp-cron.php or use a real server cron instead of the WordPress cron.
Stock and availability -- If you modify prices or stock levels during maintenance, make sure active carts are cleared upon reactivation. Otherwise, a customer could complete an order at an old price.

The safest approach for WooCommerce: create a maintenance page that only affects the frontend, while keeping the back office, webhooks, and cron active. The following snippet exempts critical endpoints:

function maintenance_woocommerce() {
    if ( current_user_can( 'manage_options' ) ) return;
    if ( defined( 'DOING_CRON' ) && DOING_CRON ) return;
 
    $uri = $_SERVER['REQUEST_URI'];
    $exempted = [ '/wp-admin', '/wp-login', '/wp-json', '/wc-api', 'wp-cron.php' ];
 
    foreach ( $exempted as $path ) {
        if ( strpos( $uri, $path ) !== false ) return;
    }
 
    wp_die(
        '<h1>Store under maintenance</h1><p>We are updating our store. Existing orders are being processed normally.</p>',
        'Maintenance',
        array( 'response' => 503 )
    );
}
add_action( 'template_redirect', 'maintenance_woocommerce' );

WordPress Multisite

On a Multisite network, maintenance mode can be applied at two levels: a single site in the network, or the entire network.

Single site maintenance -- The standard methods work (plugin, functions.php, .maintenance). The .maintenance file must be placed at the root of the main WordPress installation, not in the subsite directory. Maintenance mode will then apply to the entire network, which is probably not what you want.

To target a single site, the functions.php method with blog_id verification is more appropriate:

function maintenance_site_specifique() {
    if ( get_current_blog_id() !== 3 ) return; // ID of the site to maintain
    if ( current_user_can( 'manage_options' ) ) return;
 
    wp_die( 'This site is under maintenance.', 'Maintenance', array( 'response' => 503 ) );
}
add_action( 'template_redirect', 'maintenance_site_specifique' );

This code should be placed in a mu-plugin (/wp-content/mu-plugins/maintenance.php) so it runs across the entire network and filters by blog_id.

Entire network maintenance -- The .maintenance file at the root affects all sites. WP-CLI also offers wp maintenance-mode activate --url=site.com to target a specific site in a network.

Automating with cron jobs

If you regularly perform scheduled maintenance (nightly, weekly), automation prevents you from forgetting to deactivate maintenance mode at 3 AM.

A server cron (not the WordPress cron, which depends on visits) can activate and deactivate maintenance mode at specific times:

# Activate at 2:00 AM
0 2 * * * /usr/local/bin/wp maintenance-mode activate --path=/var/www/html
 
# Deactivate at 4:00 AM
0 4 * * * /usr/local/bin/wp maintenance-mode deactivate --path=/var/www/html

If WP-CLI isn't available, you can create and delete the .maintenance file directly:

# Activate
0 2 * * * echo '<?php $upgrading = time();' > /var/www/html/.maintenance
 
# Deactivate
0 4 * * * rm -f /var/www/html/.maintenance

Add a notification (email, Slack) at the end of the cron to confirm maintenance completed successfully. A simple curl -s -o /dev/null -w "%{http_code}" https://yoursite.com after deactivation gives you the returned HTTP code. If it's 200, all good. If it's still 503, there's a problem.

Monitoring with UptimeRobot or Pingdom

Maintenance mode makes your site intentionally unavailable. Your monitoring tool will therefore alert you -- unless you prepare it.

Before maintenance:

Pause the monitor in UptimeRobot, Pingdom, Better Uptime, or whichever tool you use. This prevents unnecessary alerts and keeps your availability statistics accurate.
If your tool supports it, schedule a "maintenance window" (UptimeRobot Pro and Pingdom offer this feature). The monitor continues checking, but alerts are suppressed during the defined window.

After maintenance:

Reactivate the monitor.
Verify that the first post-maintenance check returns a 200 code.
Check the response time: if your site takes 8 seconds to respond right after maintenance (because the cache is rebuilding), that's normal. If it's still the case an hour later, there's a problem.

These tools aren't a luxury. A forgotten .maintenance file can stay in place for days if nobody visits the site to notice. A monitor sends you an alert within 5 minutes.

FAQ

My WordPress site is stuck in maintenance mode -- what should I do?

Connect to your server via FTP or your host's file manager. Delete the .maintenance file located at the WordPress root (same level as wp-config.php). In 90% of cases, the site comes back immediately. If the problem persists, rename the plugins/ folder to plugins_disabled/ to deactivate all plugins, then reactivate them one by one to identify the conflict.

Does maintenance mode affect SEO rankings?

No, as long as you return an HTTP 503 code (not a 200 or 404) and don't exceed 48 hours of continuous maintenance. Google keeps your pages in its index and doesn't change your rankings during a temporary 503. Beyond two days, the risk of demotion increases. Also add a Retry-After header to tell crawlers when to come back.

Can you customize the maintenance page without a plugin?

Yes. Create a maintenance.php file in the /wp-content/ folder of your WordPress installation. WordPress automatically loads this file instead of the default message when maintenance mode is active. You have full control over the HTML, CSS, and HTTP headers. A working template with best practices is provided earlier in this guide.

What's the difference between maintenance mode and a "coming soon" page?

Maintenance mode returns an HTTP 503 code and is used for short-duration technical interventions. A "coming soon" page returns a 200 code and is used to prepare a launch over several days or weeks. The distinction matters for SEO: a 503 tells Google to keep your pages in the index, while a 200 on a "coming soon" page can replace your content in the index if it stays up too long.

How do I allow certain users to access the site during maintenance?

If you're using a plugin like SeedProd, configure the authorized roles in the settings (administrators, editors, etc.). With the manual method, use current_user_can() in your functions.php snippet. For example, current_user_can('edit_posts') authorizes editors and administrators, while current_user_can('manage_options') authorizes only administrators.

How long can you leave a site in maintenance mode?

There's no technical limit, but Google recommends not exceeding 48 continuous hours with a 503 code. Beyond that, Googlebot may start to consider the site as permanently down. For extended maintenance (migration, redesign), keep at least your most important pages accessible or set up a temporary staging environment.

Does maintenance mode block in-progress WooCommerce orders?

No, if your configuration is correct. Orders already placed continue to be processed in the database. However, payment webhooks (Stripe, PayPal) must remain accessible for confirmations to come through. Exempt the URLs /wc-api/ and wp-cron.php from your maintenance mode to avoid blocking transactions.

Going further

Maintenance mode is just one link in a broader WordPress maintenance strategy. If you regularly work on your site, these additional resources will come in handy:

Our complete WordPress maintenance guide covers all recurring operations, from backups to database optimization.
The monthly maintenance checklist gives you a list of actions to perform each month to keep your site fast and secure.
For WordPress updates, we've detailed the full procedure (core, themes, plugins) with the precautions to take.
If you're looking to create a more advanced custom maintenance page, our dedicated guide goes deeper into design and UX.
And if despite everything you encounter a bug or error after maintenance, we've compiled solutions to the most common problems, including the white screen of death and 500 errors.

If technical maintenance isn't your cup of tea, our WordPress maintenance service handles it for you. And for any questions, contact us.