XUmbrella Page Maintenance Controller

No. Users with the manage_options capability (administrators) always bypass the maintenance screen, regardless of the role settings.

Only the 503 response for public REST API requests that reach a targeted page. Turn it off when a headless front end or an integration has to keep talking to the REST API while a page is under maintenance. Excluding targeted pages from REST collections, the search endpoint, sitemaps, feeds, and front-end listings is not tied to that checkbox — those stay on for as long as maintenance is active, so turning the block off never puts a targeted page back into a listing. What it does allow is a request that already knows the exact post ID reading the targeted content directly, which is why the setting is marked as recommended.

Maintenance responses are sent with no-cache headers and the DONOTCACHEPAGE constant. For best results, also exclude targeted pages from your cache plugin while maintenance is active.

A URL containing a random token. Anyone who opens it can view the maintenance-targeted pages without logging in, until you regenerate or revoke the link. The token is stored as a hash and removed from the address bar immediately after access.

The list shows up to 500 items to keep the settings screen fast (adjustable via the pmctl_page_list_limit filter). Use the search box to find any page beyond that limit.

The plugin removes a targeted page from the places WordPress generates automatically: query results, listings, search, feeds, the built-in sitemap, the REST API, and menu entries that reference the page as a post. It does not rewrite content you wrote yourself. A hand-typed link, a custom-link menu item, a button or heading in a template part, or the page title written into another page's body are all authored content, and editing them is your decision, not the plugin's. Visitors who follow such a link still get the 503 maintenance screen and never see the page, but the wording and the URL remain visible until you edit them. If hiding every mention matters for a particular page, search your site for links to it before you enable maintenance. One structural case is worth knowing about: child pages keep their parent's slug in their own address, so a published child of a page under maintenance still carries the parent slug in its URL, and most themes name the parent in the breadcrumb trail. Select the child pages as targets too if that matters.

Targeted pages return HTTP 503 with a Retry-After header, which tells search engines the outage is temporary. They are also excluded from WordPress's built-in sitemap, feeds, and the site's own front-end search results and archive listings while maintenance is active. If an SEO plugin (Yoast SEO, Rank Math, All in One SEO, etc.) generates its own sitemap, it replaces WordPress's built-in one and is not covered by this exclusion — exclude the targeted pages there separately if you use one.

The plugin works on a per-site basis (each site has its own settings), and settings are migrated per site as each one loads the updated version. Network activation and network-wide uninstall are not officially tested; use it on individual sites within a network.

The plugin is fully internationalized and its translations are managed on translate.wordpress.org, so any locale the community translates is delivered automatically. Contributions are welcome.