Stop letting visitors catch the site mid-change
Maintenance Mode closes the public site to anyone not logged in while work is underway, showing a custom HTML page, or redirecting to a page or URL instead — so a visitor arriving mid-edit sees an honest message, not a half-updated layout or an error.
- Three destination modes: custom HTML, an existing page, or any URL.
- Redirect-loop protection built into both the page and URL modes.
- Matches WordPress core's own maintenance-mode HTTP behavior.
- Logged-in staff pass straight through, automatically.
What visitors see
Full HTML shown to guests on every page while maintenance mode is active. Leave empty to use the default message.
What does Maintenance Mode do?
When the maintenance_mode module is active, TOWP_Maintenance_Mode intercepts every front-end request from a visitor who isn't logged in, at the earliest point WordPress offers, before any other module gets a chance to serve or redirect it. By default it renders a full HTML page with a proper 503 status and Retry-After header, matching how WordPress core's own built-in maintenance screen behaves; instead, it can redirect to an existing page or any URL. The REST API gets its own dedicated 503 response, and since logged-in users bypass the entire mechanism automatically, wp-admin and the login screen never get gated.
A live edit, seen by someone who has no idea it's in progress
Since editing directly on a live site happens in full view of anyone browsing at the wrong moment, the results are often visible before they're finished.
A visitor mid-edit sees breakage, not an explanation
Working directly on a live site risks a visitor landing on a half-updated layout, a broken block, or a plain error, with nothing telling them what's actually going on.
Silence looks worse than an honest message
A page that simply looks wrong reads as neglect, while a page that says maintenance is underway reads as normal, expected upkeep.
An honest message, however the work needs to happen
The module closes the public site cleanly while work continues, with three ways to decide exactly what a visitor sees.
A custom HTML page, written once
Write a full page in Visual or Code mode, or instead leave it blank for a polished default message that still matches the site's own branding.
Redirect to a page or URL instead
Send visitors to an existing page on the site, or to any other address, instead of showing a maintenance message at all.
Staff keep working, uninterrupted
Anybody already logged in bypasses maintenance mode entirely, and maintenance mode never touches wp-admin or the login screen.
Careful engineering, not just a message
Every capability below is present in the supplied PHP class and its settings registration.
Priority 0 on template_redirect, deliberately
Maintenance mode registers specifically to fire before every other module hooked on the same action, so it covers a URL one of them would otherwise serve or redirect first.
503 status, Retry-After header, no caching
The default page responds the same way WordPress's own built-in upgrade-maintenance screen does, telling crawlers and browsers exactly how to treat the response.
Neither Page nor URL mode can loop forever
Page mode checks whether the visitor is already on the destination page before redirecting, and similarly, URL mode compares the current request against the target address, so neither mode can send a visitor in circles.
A safe fallback if a destination isn't set yet
If Page or URL mode is selected but no actual destination has been configured, the module falls back to the custom HTML page instead of leaving the site fully open.
A complete page, not sanitized post content
The custom HTML field skips the standard content filter specifically because it would strip the html, head, and style tags a full standalone page actually needs.
The same wp_safe_redirect() fix used elsewhere
A configured URL destination gets its host added to the allowed redirect list, so an external address doesn't silently fall back to the homepage.
Where an honest gate helps most
The module supports any moment when the public site genuinely shouldn't show what's currently happening behind it.
Live edits on a site that's already public
Close the site cleanly while making changes that would otherwise be visible mid-update to anyone browsing at the wrong moment.
Major updates, migrations, or theme changes
Show a clear, on-brand message for the duration of a bigger change, rather than an unpredictable broken state.
Redirecting an entire site elsewhere temporarily
Send every guest to a specific page or an external address during a transition, without touching the site's actual content.
A cleaner pause, not a visible mess
The module combines a genuinely honest visitor experience with defenses against the classic maintenance-mode mistakes.
One early check, then nothing else
The verified implementation stays lightweight regardless of which mode is active.
One early check, then nothing else
The check runs once per request, at the earliest point WordPress offers, before any other page logic executes for a gated visitor.
No effect on a logged-in visit
The check exits immediately for anyone logged in, adding no overhead to the normal admin or staff experience.
A single HTML render, no database-heavy logic
Showing the maintenance page is a straightforward render; the redirect modes involve only a lightweight status and path comparison.
Visibility control, not access control
The code changes what a guest sees, never what an account can actually do.
A visibility control, not an access-control mechanism
This module changes what a guest sees, not what any user account can actually do; it has no effect on any capability or permission.
External redirects are explicitly whitelisted, not opened broadly
The module adds only the host of a destination actually configured in the settings to the allowed list, not an open pass for any external URL.
The custom HTML field is trusted content, by design
Since only an administrator can set it, the module skips post-content filtering on the full HTML field deliberately, rather than by oversight.
Configuration requires the same access as any other setting
Choosing a mode and its destination happens through the standard TheOneWP settings screen, available only to an administrator.
Built directly around WordPress's own request and REST APIs
The supplied code integrates through APIs present in WordPress core; this page makes no compatibility claim beyond the verified implementation.
template_redirect action, priority 0
The native WordPress action used to intercept and gate every front-end page request before rendering begins.
rest_authentication_errors filter
The native WordPress filter used to reject a REST API request from a logged-out visitor with a proper 503 error.
allowed_redirect_hosts filter
The native WordPress filter used to permit wp_safe_redirect() to send a guest to an external host when explicitly configured.
TheOneWP versus common alternatives
Compare the verified Maintenance Mode implementation with a typical single-message plugin.
| Capability | TheOneWP Maintenance Mode | Other common solutions |
|---|---|---|
| Destination flexibility | Custom HTML, an existing page, or any URL | Often a single fixed maintenance message with no redirect option |
| Redirect-loop protection | Built into both Page and URL modes | A common oversight that can send visitors in circles |
| HTTP correctness | 503 status and Retry-After, matching WordPress core | Some approaches return a normal 200 status, misleading crawlers |
| Fallback behavior | Never left inert if a destination isn't configured | A misconfigured redirect can leave the site fully open by mistake |
| REST API coverage | A dedicated 503 check, closing a separate vector | Frequently left open even when the HTML pages are gated |
Close the site cleanly in four steps
Confirm the expected page or redirect from a logged-out view before starting the actual work.
Enable Maintenance Mode
Activate the module from the TheOneWP System settings tab.
Choose what visitors see
Pick Custom HTML page, Redirect to a Page, or Redirect to a URL, based on what fits the situation.
Configure the destination
Write the HTML message, select the page, or enter the URL, depending on the mode chosen.
Confirm as a logged-out visitor
Open the site in a private browser window and confirm the expected page or redirect appears.
Match the message to how long the work will actually take
The right approach depends mostly on how visible and how long the change actually is.
Leave the custom HTML field blank for routine, short maintenance
The polished default message covers most situations without needing to write anything.
Write a custom message for longer or more visible work
A specific message, even just a rough time estimate, therefore reads better than a generic notice for anything longer than a quick fix.
Use Redirect to a Page for content that still needs to be reachable
An existing page, like a status update or contact page, can stay genuinely useful during maintenance rather than being replaced by a static message.
Turn it off deliberately once work is finished
Disable the module explicitly instead of assuming it will simply stop mattering once changes finish.
Avoid a couple of details worth understanding first
A few behaviors are easy to misjudge the first time through.
Selecting Page or URL mode without setting a destination
The module falls back to the custom HTML page automatically in that case, so the site won't accidentally stay open, but it's still worth configuring the actual destination.
Assuming the custom HTML field gets sanitized like post content
The field intentionally skips standard content filtering, so a full HTML document, including its own head and style tags, renders correctly.
Forgetting search engines see the maintenance page too
The 503 status and Retry-After header tell search engines this is temporary, but leaving maintenance mode on far longer than expected can still affect how a site is perceived.
Maintenance Mode FAQ
These answers come directly from the verified class and its settings registration.
What does Maintenance Mode do?
It closes the public site to anyone not logged in, showing a custom HTML page, or redirecting to a page or URL, while work is underway.
Does this affect logged-in users?
No. Anybody already logged in bypasses maintenance mode entirely, and it never touches wp-admin or the login screen.
What happens if I don't write any custom HTML?
A polished default message appears instead, styled to match the site's own branding.
Can maintenance mode redirect visitors instead of showing a message?
Yes. Redirect to a Page or Redirect to a URL sends visitors somewhere else entirely instead of displaying a message.
Can a redirect destination cause an infinite loop?
No. Both redirect modes check whether the visitor is already at the destination before redirecting, preventing a loop.
What happens if I choose Page or URL mode but don't set a destination?
The module falls back to the custom HTML page automatically, rather than leaving the site fully open.
Is the REST API affected too, or just the pages?
Both. A separate check specifically returns a 503 response for the REST API.
Does this return the correct HTTP status for search engines?
Yes. The default page responds with a 503 status and a Retry-After header, matching how WordPress's own built-in maintenance screen behaves.
Is the custom HTML field sanitized like normal post content?
No. It's left unfiltered deliberately, since standard content filtering would strip the tags a full HTML page actually needs.
Who can configure Maintenance Mode?
Only an administrator with access to the TheOneWP settings screen.
Stop letting visitors catch a half-finished layout.Show an honest message while the work happens.
Use Maintenance Mode to close the public site with a custom page or a redirect, with staff bypassing it automatically and both redirect modes protected against loops.