How to create maintenance pages in WordPress
For a short maintenance window, WordPress can serve a custom page from a maintenance.php drop-in in wp-content, activated with WP-CLI. For longer or branded downtime, a plugin is safer because the manual method has no built-in scheduling, access controls, countdowns or email capture.
- 01Choose the maintenance approach
- 02Back up before switching modes
- 03Create the manual page
- 04Activate and check maintenance mode
- 05Finish work and deactivate it
- 06Use the fast plugin route
What you need
- Administrator or server access
- A recent backup of the site files and database
- WP-CLI access or your host’s file manager
- A maintenance message and expected return time
Choose the maintenance approach
Use the manual route for a short, technical maintenance window where a plain message is enough. WordPress’s built-in maintenance mechanism is mainly used during updates, and its default response is a temporary 503 Service Unavailable with a Retry-After header.
Use a plugin when visitors need a branded page, countdown, signup form, scheduled activation, or continued access for logged-in staff. A normal WordPress Page is not enough on its own because visitors can still reach the rest of the site.
Back up before switching modes
Take a current database and file backup before updating themes, plugins or core files. Maintenance mode does not protect you from a failed update, incompatible plugin or server problem.
Do not activate the page until you know how to turn it off. Keep hosting file-manager or SSH access available, because a mistake in a maintenance file can also block the WordPress dashboard.
Create the manual page
Create a file named maintenance.php inside wp-content. Add self-contained HTML and CSS with your logo or site name, a clear reason for the downtime, an expected return time, and an alternative contact method. WordPress loads this drop-in instead of its default maintenance message when maintenance mode is active.
Keep the file independent of your theme, plugins and database. That makes it more likely to work while those parts of the site are being changed. The manual page will not provide a countdown, email collection or logged-in-user bypass unless you build those features yourself.
Activate and check maintenance mode
From a shell, run wp maintenance-mode activate. Check the status with wp maintenance-mode status, then open the site in a private browser window while logged out. WP-CLI provides commands to activate, deactivate and inspect WordPress maintenance mode.
Test the home page, a typical internal URL and the contact route. Check the response status as well as the appearance: a proper planned-maintenance response should be temporary and use HTTP 503 rather than a permanent redirect or a normal 200 page.
Finish work and deactivate it
When the site is ready, run wp maintenance-mode deactivate and remove or archive the custom maintenance file if you will not use it again. Clear page, server and CDN caches, then test the site while logged out.
WordPress also creates a hidden .maintenance file in the installation root during updates. If an update is interrupted, that file can leave the site showing the default maintenance message; deleting the leftover file through FTP or your host’s file manager normally clears it. Make hidden files visible before looking for it.
Use the fast plugin route
Install and activate Coming Soon and Maintenance Mode by Traslatability, choose a ready-made maintenance design, add your branding and message, then switch the mode on. This is the quicker route when you need a presentable page without writing a drop-in or maintaining custom CSS.
It is suited to pages with countdowns, email capture, responsive layouts and access control for logged-in users. It also handles SEO-focused 503 responses and Retry-After headers, which removes several details you would otherwise need to implement and verify yourself.
Let Coming Soon and Maintenance Mode by Traslatability do it
Ready-made maintenance pages with countdowns, email capture, and SEO-safe 503 responses; ideal when you need setup without a page builder.
Sources
- developer.wordpress.org /reference/functions/wp_maintenance/?utm_source=openai
- developer.wordpress.org /cli/commands/maintenance-mode/?utm_source=openai
- developer.mozilla.org /en-US/docs/Web/HTTP/Reference/Status/503?utm_source=openai
- developer.wordpress.org /advanced-administration/wordpress/common-errors/?utm_source…
Questions
- Can I use a normal WordPress Page as a maintenance page?
- A normal WordPress Page does not put the rest of the site into maintenance mode. Visitors can still open other URLs, and the page normally returns a successful 200 response rather than a temporary 503. Use a maintenance mechanism that intercepts requests, such as the core drop-in method, a server rule or a dedicated plugin.
- Where should the custom maintenance file go?
- Place the custom file at <code>wp-content/maintenance.php</code>. WordPress checks for that drop-in when its maintenance mode is active and loads it instead of the default maintenance message. Do not confuse it with <code>.maintenance</code>, which is a hidden temporary file in the WordPress installation root and is commonly created during updates.
- Will maintenance mode keep administrators out of the site?
- The manual core method should be treated as capable of blocking normal front-end and dashboard requests, so keep hosting or command-line access available before activating it. It does not automatically provide a logged-in-user bypass. A dedicated maintenance plugin may offer role-based access, but you should still test the bypass in a separate browser session.
- What status code should a maintenance page return?
- A planned temporary outage should return HTTP 503 Service Unavailable, ideally with a Retry-After value indicating when the service may be available again. Returning 200 can make search engines treat the maintenance content as the real page, while a permanent redirect is unsuitable for temporary downtime.
- Why is my WordPress site stuck on the maintenance message?
- The usual cause is a leftover <code>.maintenance</code> file after an interrupted WordPress, plugin or theme update. Connect through FTP, SSH or your host’s file manager, show hidden files, and delete that file from the WordPress installation root. If the problem returns, investigate update timeouts, permissions, memory limits and plugin conflicts rather than repeatedly deleting the file.