Maintenance in Progress
We're improving your experience. The site will be back in a few moments.
We are performing an update. Please check back in a few minutes.
', 'Maintenance', array( 'response' => 503 ) ); } } add_action( 'template_redirect', 'activer_mode_maintenance' ); ``` This snippet does three things: 1. It checks whether the current user has the `manage_options` capability (reserved for administrators). 2. If not, it displays a maintenance message using `wp_die()`. 3. 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): ```apache 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: ```bash # 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
We're improving your experience. The site will be back in a few moments.
Please check back in a few minutes.
', '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: ```php 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: ```bash 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: 1. Log into Google Search Console. 2. Go to **URL Inspection** and test your homepage. Verify that the returned code is 503. 3. 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: 1. You activate maintenance mode. Your maintenance page displays correctly. 2. 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). 3. You deactivate maintenance mode. Your site is back. 4. 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: ```php 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( 'We are updating our store. Existing orders are being processed normally.
', '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: ```php 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: ```bash # 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: ```bash # Activate 0 2 * * * echo ' /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](/blog/wordpress/maintenance-guide) covers all recurring operations, from backups to database optimization. - The [monthly maintenance checklist](/blog/wordpress/wordpress-maintenance-checklist) gives you a list of actions to perform each month to keep your site fast and secure. - For [WordPress updates](/blog/wordpress/wordpress-update-guide), 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](/blog/wordpress/maintenance-page-guide), our dedicated guide goes deeper into design and UX. - And if despite everything you encounter a [bug or error](/blog/wordpress/common-bugs-fix) after maintenance, we've compiled solutions to the most common problems, including the [white screen of death](/blog/wordpress/white-screen-death-fix) and [500 errors](/blog/wordpress/erreur-500-solutions). If technical maintenance isn't your cup of tea, our [WordPress maintenance service](/services/wordpress/maintenance) handles it for you. And for any questions, [contact us](/contact).