How to hide pages, make your site private, or put it under construction

“Can you just hide this?” covers at least four different problems, and the fix for one is actively wrong for the others. A page you want out of the main menu is different from a page you want kept from strangers, which is different from a whole site that is not ready to launch, which is different from a live site that needs to disappear for an hour while you swap the theme. Use the wrong mechanism and you either expose content you thought you hid or lock yourself out along with the visitors.

This guide walks through the four situations people actually mean when they ask to hide something in WordPress, points out the right tool for each, and calls out the traps – wrong HTTP status codes, search engines indexing the “coming soon” page as the final page, wp-admin getting locked behind its own protection – that turn a simple hide into an SEO or access problem.

Which situation are you in?#

Before touching anything, match the goal to one of these four rows. Every section below expands one of them.

You want to…	The right tool	What it returns
Launch a placeholder before the site exists	Coming soon page (plugin or static HTML) + noindex	200 OK with noindex, or 503 if pre-launch
Take a live site offline briefly for work	Maintenance mode	503 Service Unavailable with Retry-After
Hide specific pages from the menu but keep them reachable by URL	Remove from menu, leave page public	200 OK
Keep specific pages – or the whole site – private	Post-level “Private” visibility, password protection, or HTTP Basic Auth	200 OK to authorized users, 401 or redirect otherwise

The rest of this article works through each row in turn. If you only need one, jump to that section – they are independent.

Situation 1: Coming soon page (site has not launched yet)#

The site is being built. The domain resolves. You want visitors who stumble onto it to see something that sets expectations – “launching in May, leave your email” – and you want search engines to hold off indexing until the real site is ready.

The three decisions that matter

What status code to return. This is the part most tutorials get wrong. A coming soon page is usually not a maintenance event – the real site does not exist yet. In that case the coming soon page is the site, and it should return 200 OK with a noindex meta tag in the HTML head. That tells crawlers “this is a real page, but please do not include it in results.” A 503 is appropriate only if you are actively pre-launching and expect the real content to appear on the same URLs within days; otherwise Google eventually decides your site is just broken and demotes it.

Whether to collect emails. Most coming soon plugins include an email capture form. If you have a mailing list or an ESP (Mailchimp, ConvertKit, Klaviyo), wire it in – a pre-launch list is the cheapest marketing asset you will ever build. If you do not, skip the form. An empty-looking signup is worse than no signup.

How to keep wp-admin reachable. Every plugin worth using has a toggle for this, but you should verify before flipping the site live, because locking yourself out of a site you are actively building is a particularly annoying mistake.

Option A: SeedProd (plugin, most common)

SeedProd is the most common WordPress coming soon plugin as of 2026. The free version handles the basics: template selection, logo/headline/background, email capture, and – critically – a “hide from visitors but not from logged-in users” toggle so you can keep working on the real site while the public sees the placeholder.

Install SeedProd, go to SeedProd > Pages, click “Set up a Coming Soon Page,” pick a template, customize it, and activate. The plugin injects its page at the site root and returns 200. Verify the noindex tag is set in SeedProd’s settings before launching – it is usually on by default but double-check.

Option B: “Discourage search engines” setting (insufficient on its own)

WordPress has a checkbox under Settings > Reading called “Discourage search engines from indexing this site.” It adds <meta name="robots" content="noindex,nofollow"> to every page and a Disallow: / rule to robots.txt. This is not a coming soon page – it is a request to crawlers, nothing more. Use it alongside a coming soon plugin, not instead of one. And turn it off when you launch, or the live site will silently refuse to rank.

Option C: Plain HTML, no WordPress

If the site does not exist yet, the simplest coming soon is a static index.html in the web root that contains your headline, maybe a signup form (posting to an ESP directly or to a simple form endpoint), and a <meta name="robots" content="noindex"> tag. No plugin, no PHP, no database. When you are ready to launch WordPress, delete the static file and let the CMS take over.

This works especially well for domains that do not have WordPress installed yet. The page loads fast, there is nothing to maintain, and there is no attack surface.

What not to do for a coming soon page

• Do not return 503 for a long-running pre-launch. Google treats 503 as “temporarily unavailable” and eventually interprets “temporary” running for weeks as a signal to deprioritize you.
• Do not redirect to a parked page on another domain. You lose any SEO equity the domain accumulates and confuse anyone trying to verify ownership.
• Do not password-protect the whole site while collecting pre-launch emails. A basic auth prompt kills lead capture – visitors hit the credential dialog and leave. Coming soon pages need to be publicly visible.
• Do not forget the noindex comes off at launch. Schedule the check: on launch day, verify that Search Console’s URL Inspection says the homepage is indexable, not blocked.

Situation 2: Maintenance mode (live site, temporarily offline)#

The site is live, indexed, ranking. You need to take it down for 30 minutes while you swap the theme, restructure WooCommerce products, or deal with an incident. Visitors should see “we will be back shortly” and search engines should understand this is temporary, not a permanent disappearance.

This is the case where returning 503 Service Unavailable is correct. The 503 status with a Retry-After header tells Googlebot “come back later, this is not a permanent state change.” Pages stay in the index, rankings are preserved. Return 200 for a maintenance page and you risk the maintenance message itself becoming your cached snippet for every query you ranked for.

WordPress’s built-in .maintenance file

When WordPress runs a core, plugin, or theme update, it creates a file called .maintenance in the web root and briefly serves a plain “Briefly unavailable for scheduled maintenance” page with a 503 status. The file is auto-deleted when the update finishes.

The pain point: if an update crashes midway, the .maintenance file sticks around and the site stays stuck on the maintenance page forever. The fix is manual – SSH or FTP into the server and delete the .maintenance file from the site root. Nothing else needed. If you do not have SSH, most hosts let you do this through a file manager in their control panel.

The built-in mechanism is fine for the brief updates it is designed for. It is not a feature you enable or configure – it is a side effect of core/plugin updates.

Plugin-based maintenance mode (for planned work)

For planned maintenance (a theme swap, a major WooCommerce migration, a data import), use a plugin that gives you control over the page content, the 503 status, and the bypass for logged-in admins. “WP Maintenance Mode” and “LightStart” (formerly Coming Soon Page & Maintenance Mode by NiteoThemes) are both solid free options.

What to verify in any maintenance mode plugin:

• It returns 503, not 200. Check with curl -I https://yoursite.com/ and look for HTTP/2 503 in the response.
• It sends a Retry-After header (either a duration in seconds or an HTTP date). This tells crawlers when to come back.
• It has a logged-in user bypass, so administrators can see the real site while visitors see the maintenance page.
• It does not block /wp-admin/ or /wp-json/ , or you will lock yourself out of the dashboard you need to finish the work.

Maintenance mode belongs to a bigger conversation about ongoing site care – what to do monthly, who should do it, and what agencies actually charge for “we keep your WordPress alive” is covered in WordPress maintenance plans – what they include and what to charge.

Situation 3: Hide specific pages from navigation (but keep them accessible by URL)#

This is the lightest of the four cases and by far the most common. You have a Thank You page, a landing page you only want visitors to reach from an ad, a page you link to from an email. It needs to be live and indexable (or not – your call), but it does not belong in the main menu.

The fix: do not add it to the menu

WordPress does not automatically put every page in the navigation – you choose what goes there. Go to Appearance > Menus, select the menu that appears in your header, and if the page is in the menu list, remove it. Save. Done.

The page still exists at its URL, is still linkable, is still searchable if it is linked from anywhere else, but stops cluttering the navigation.

Common complications

Some themes auto-include every page. Older themes or themes using WordPress’s legacy “auto-generate menu from pages” feature add new pages to the navigation automatically. Switch to a custom menu (Appearance > Menus > “create a new menu” and assign it to the primary location) and you regain control.

The page still shows up elsewhere. Removing from the menu does not remove it from: sitemaps (if you use Yoast/Rank Math, they decide via per-page settings), archive pages, search results on your site, or widgets like “Recent Pages.” These are separate controls.

You actually want it out of sitemaps and search results too. If you also want the page hidden from Google, use the SEO plugin’s per-page setting (“noindex this page”) and make sure internal links to it use rel="nofollow" if you do not want PageRank flowing there. Full control over which URLs Google sees is in WordPress permalinks – how to configure them for SEO.

If you want the page completely orphaned

For a Thank You page that nobody should find by browsing: do not link to it from anywhere on the site, add it to the SEO plugin’s noindex list, and optionally set the slug to something unguessable ( /thank-you-x7f3b2/ instead of /thank-you/ ). The page is unreachable unless someone has the direct URL – which is the point.

Situation 4: Keep pages or the whole site private#

Private means “only specific people can see this.” There are three strengths of private in WordPress, and you pick based on how sensitive the content is and how many people need access.

Strength 1: WordPress “Private” visibility (weakest)

In the block editor’s right sidebar, under Post > Visibility, “Private” hides the page from everyone except logged-in users with the Editor or Administrator role. It does not return a 401 or a password prompt; it returns 404 to anyone who does not have permission. To someone who is not logged in, the page effectively does not exist.

Use it for: Draft content you want teammates to review. Internal documentation that lives on the same WordPress install as the public site. Any case where the people who need access are already users on the site.

Do not use it for: Anything sensitive. The protection is only as strong as your login – which means WordPress’s whole authentication stack (and any plugin vulnerability in it) is the threat model. For real privacy, move up a level.

Strength 2: Password-protected post (medium)

Set Visibility > Password protected on an individual post and enter a password. The URL still works, but visitors see a password form instead of the content. Anyone with the password reads the post.

This is a shared-secret mechanism – everyone with the password has equal access – with no user accounts and no audit trail. It is the right fit for “share this draft with a client” and the wrong fit for anything you would be embarrassed to see leak.

Full coverage of what this actually protects (and the traps around caching, media files served directly from /wp-content/uploads/ , and the REST API) is in how to password protect a WordPress site, page, or directory – it is worth reading before relying on this for anything important.

Strength 3: HTTP Basic Auth on the whole site (strongest common option)

For a staging site, a pre-launch build, or any environment that needs to be completely invisible to anyone without credentials, HTTP Basic Auth at the web-server layer is the right tool. The browser shows a native credentials dialog; nothing loads without the password; search engines never see the content because they do not solve Basic Auth challenges.

This is the protection you want for:

• Staging environments. A duplicate of your live site where you test changes. Staging must be completely unindexable or Google treats it as duplicate content and penalizes the real site.
• Development sites. Work-in-progress WordPress installs that should not appear in any search engine anywhere.
• Internal tools. Any WordPress install that is not meant for the public internet at all.

The mechanics (writing .htpasswd files, configuring nginx, dealing with the wp-cron and REST API gotchas that break WordPress when the whole site is behind basic auth) are detailed in the password protection guide. The short version: exclude /wp-cron.php and /wp-json/ from the protection, or WordPress will silently break on you.

For a full staging setup – not just the protection, but the whole workflow of duplicate environments, database sync, and deploying changes to production – see how to create a WordPress staging site.

Combining private + coming soon

A common real-world case: the site is pre-launch, you want the public to see a coming soon page at / , but you want the actual in-progress WordPress build reachable at /wp-admin/ and at every URL for you and your team. The clean solution:

1. HTTP Basic Auth on / with team credentials
2. A static index.html or a SeedProd coming soon page that is NOT behind basic auth (allowlist it)
3. Exclude /wp-admin/ , /wp-login.php , /wp-cron.php , /wp-json/ from basic auth

Visitors see the coming soon page. Anyone who knows the basic auth credentials can browse the real site in progress. wp-admin stays reachable for anyone with WordPress credentials.

Keeping wp-admin reachable in all four scenarios#

The most common self-inflicted outage from every technique on this page: locking yourself out of the admin dashboard you need to undo what you just did.

Coming soon plugin: Verify the “exclude logged-in users” or “exclude admins” toggle is on before activating. If you get locked out, add ?no-coming-soon=1 (plugin-specific query param) or manually deactivate the plugin via FTP/SSH by renaming the plugin folder.

Maintenance mode plugin: Same deal – “bypass for logged-in administrators” must be on. The built-in .maintenance file never blocks /wp-admin/ , so that one is safe by default. Plugin maintenance modes sometimes do, so check before enabling.

“Private” visibility: Does not affect wp-admin at all. Safe.

Password-protected post: Does not affect wp-admin. Safe.

HTTP Basic Auth site-wide: This is the trap. If you apply basic auth to / without excluding /wp-admin/ , you can still log in to wp-admin – basic auth does not replace WordPress login, it runs in front of it. But the editor will break because Gutenberg uses /wp-json/ , and autosave/publish will fail with 401. Always add exclusions for /wp-login.php , /wp-admin/admin-ajax.php , /wp-cron.php , and /wp-json/ .

Lockout recovery. If you completely lose access, the nuclear options in order: (1) deactivate the misbehaving plugin by renaming its folder via FTP/SSH, (2) remove the basic auth directives from nginx config, (3) delete the .maintenance file from the web root, (4) restore from backup.

Common mistakes#

• Returning 200 for a maintenance page on a live site. Google eventually caches the maintenance message as your homepage snippet. Always 503 with Retry-After for temporary unavailability.
• Returning 503 for a months-long coming soon page. Google treats sustained 503s as a broken site. A pre-launch placeholder should be 200 + noindex.
• Leaving “Discourage search engines” on at launch. The single most common cause of “my site went live two weeks ago and is not ranking for anything.” Uncheck the box in Settings > Reading on launch day.
• Hiding a page by setting it to draft. Draft status removes the page from the URL entirely – anyone with a bookmark or a link gets a 404. If you want the page reachable but just not in the menu, keep it published and remove it from the menu.
• Password-protecting a staging site at the WordPress level instead of the server level. WordPress post passwords or “private” visibility do not prevent bots from discovering URLs and do not keep out search engines reliably. For staging, use HTTP Basic Auth at the server level.
• Coming soon plugin that blocks /wp-admin/ . You cannot finish the site you are trying to launch. Verify the bypass before enabling.
• Forgetting robots.txt when going live. If you edited robots.txt during development to Disallow: / , restore it on launch day. Same category of mistake as the “Discourage search engines” checkbox.
• Using “Private” visibility for confidential content. It is not a security boundary; it is a convenience feature for logged-in editors. For anything sensitive, use proper authentication.

How Hostney handles this#

Hostney includes HTTP Basic Authentication as a built-in feature of the control panel, which covers the hardest case on this list – fully private site or staging environment – without needing to SSH in and edit nginx config. Under Security > Password Protection, pick the subdomain, set the path (default is / , which protects the whole site), and enter an email and password. The control panel writes the .htpasswd file, updates the nginx config, and reloads it. Protection is live within seconds, and the same page manages multiple users per subdomain if you need to share access with a team.

Password complexity is enforced server-side (12-128 characters with mixed case, number, and special character), so the usual “admin/admin” convenience credentials are not possible. Every add/update/delete goes through the same audit log as the rest of the control panel, so you have a record of who enabled or rotated protection.

For the coming soon and maintenance cases, Hostney’s container isolation means you can run a production WordPress install and a pre-launch or maintenance variant on separate subdomains without their plugins, themes, or databases touching each other. The typical pre-launch workflow: put the real WordPress build on a subdomain like staging.yoursite.com with Password Protection enabled, put a SeedProd coming soon page or a static index.html on the main domain, and flip them when you launch.

When the site is ready to go public, delete the Password Protection entry for the subdomain or move WordPress onto the main domain – both take seconds through the control panel, no downtime, no config edits, no support ticket.

For the bot side of the equation: once you put a site behind basic auth, Hostney’s edge bot-detection treats authenticated requests more leniently than anonymous ones, so your team does not get caught in the same challenge sampling that filters anonymous crawler traffic. Pre-launch sites stay responsive for the people who should be accessing them.

Summary#

Four different “hide it” goals, four different tools. For a pre-launch placeholder, serve a coming soon page with 200 + noindex . For a live site taken offline briefly, return 503 with Retry-After via a maintenance plugin. For pages that should exist but not clutter the menu, just remove them from the menu. For pages or whole sites that need to be genuinely private, layer the protection to match the sensitivity: WordPress “Private” for internal drafts, post passwords for shared-secret access, HTTP Basic Auth for full staging or pre-launch privacy. In every case, verify before activating that wp-admin still works for you, that the HTTP status code matches the real situation, and that whatever setting you flipped on during development gets flipped off the day you launch.