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

“Can you just hide this?” covers at least four different problems in WordPress, and the fix for one is actively wrong for the others. Hiding a single page from Google is different from hiding a page out of the main menu, which is different from making the whole site private, which is different from a live site that needs to disappear for an hour while you swap the theme, which is different from a brand-new site that has not launched yet. 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 – hide a page from Google, hide a page from the menu, make a page or whole site private, or run a coming soon / maintenance page – and points out the right tool for each. It 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 a single page from Google but keep it live	Per-page noindex via Yoast / Rank Math / SEOPress	200 OK with <meta name="robots" content="noindex">
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 have an ESP yet, even an embedded Google Form is enough to capture pre-launch signups into a sheet. If you cannot wire something in at all, 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. Removing a page from the menu does nothing to keep Google from indexing it – that needs a separate step, covered in the next section.

How to hide a single page from Google in WordPress#

Removing a page from the menu hides it from your site’s navigation. It does not hide it from Google. If the URL is linked from anywhere – an old blog post, an external site, your sitemap, a social share – search engines can still find and index it. To actually keep a page out of Google’s search results, you need to tell crawlers explicitly with a noindex directive.

WordPress core does not ship a per-page noindex toggle. The SEO plugin you already have – Yoast, Rank Math, or SEOPress – adds one. Pick the plugin you use:

• Yoast SEO. Open the page in the editor, scroll down to the Yoast meta box, click the Advanced tab, set “Allow search engines to show this Page in search results?” to No. Save. Yoast writes <meta name="robots" content="noindex,follow"> into the page’s HTML head.
• Rank Math. Open the page, click the Rank Math icon in the top right, go to the Advanced tab, check No Index. Save.
• SEOPress. Open the page, scroll to the SEOPress meta box, Advanced tab, check Do not index this page (noindex). Save.
• No SEO plugin. Install one. Editing wp_head filters by hand to add a per-page meta tag is a maintenance burden you do not want, and Disallow: in robots.txt does not deindex – it just prevents future crawling, which can leave the page in the index based on external links.

After you save, verify the tag is actually rendering. Open the page in an incognito window, view source ( Ctrl+U ), and search for noindex . You should see something like <meta name="robots" content="noindex,follow"> near the top of <head> . If it is missing, your SEO plugin is not active for that post type, or a caching plugin is serving a stale version – purge the cache and re-check.

noindex,follow vs noindex,nofollow . Use noindex,follow (the default in every major SEO plugin). It tells Google “do not show this page in results, but follow its internal links normally.” nofollow would also prevent PageRank from flowing through any link on the page, which usually is not what you want for a utility page like Thank You or Terms.

Tell Google to drop it faster. The noindex tag only takes effect the next time Google crawls the page. To force a recheck, open Google Search Console, paste the URL into the URL Inspection tool, and click Request Indexing. The page will usually drop from results within a few days; without a manual request it can take weeks.

For a single urgent removal (within hours, not days), use Search Console’s Removals tool (Indexing > Removals > New Request). It blocks the URL from search for ~6 months while the noindex does the permanent work. Use this only for emergencies (leaked draft, accidentally published private content) – it is not a replacement for noindex .

For hiding entire archive layers – tag archives are the common case, where one post per tag creates dozens of thin index pages – WordPress tags and categories for SEO covers the sitewide taxonomy-noindex toggles in Yoast and Rank Math. For controlling which URLs Google sees at the structure level, see 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, set the per-page noindex toggle above, and optionally set the slug to something unguessable ( /thank-you-x7f3b2/ instead of /thank-you/ ). If you do not want PageRank flowing to it from the one or two internal links that do exist, mark those links rel="nofollow" (how to insert and edit hyperlinks covers the Mark as nofollow toggle in the link settings panel). The page is then 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. The same three mechanisms cover everything from “make a single page private” to “make my whole WordPress site private” to “set up a private blog where only invited members can read.”

Quick map: which strength do you need?#

• A single page or post for a small group of people who already have WordPress accounts – use “Private” visibility on that post.
• A single page for a small group who do not need WordPress accounts – use a password-protected post.
• A private blog where only members can read posts – “Private” visibility per post, plus a members plugin like Restrict User Access or MemberPress if you want self-service signup.
• The whole WordPress site invisible to the public and to search engines – HTTP Basic Auth at the web server layer. This is also the right answer for “make my site private while I rebuild it.”

The three mechanisms map to the three strengths below.

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.

Frequently asked questions#

How do I hide a single page from Google in WordPress?

Set noindex on the page using your SEO plugin’s per-page toggle (Yoast: Advanced tab; Rank Math: Advanced tab; SEOPress: Advanced tab). Save, then request a recrawl in Google Search Console’s URL Inspection tool so the page drops from results within days rather than weeks.

How do I make my WordPress site private?

For a single page or post, use the Private visibility option in the block editor’s right sidebar. For the whole site, enable HTTP Basic Auth at the web-server layer – this is the only mechanism that keeps search engines and casual visitors out completely, even from URLs they discover externally.

How do I make a private blog in WordPress?

Set posts to “Private” visibility one by one if your readers all have WordPress user accounts. For a self-service members area where people sign up and then read posts, add a plugin like Restrict User Access (free), MemberPress, or Paid Memberships Pro on top of “Private” visibility.

What is the difference between Private and Password-protected visibility?

Private hides the post from everyone except logged-in users with Editor or Administrator roles – the post returns 404 to anyone else. Password-protected leaves the URL public, but shows a password form instead of the content. Private uses WordPress accounts; password-protected uses a shared secret.

Will “Discourage search engines from indexing this site” hide my pages from Google?

It adds a sitewide noindex and a Disallow: / to robots.txt – it is a request, not enforcement. Google usually honors it but is not obligated to. It is fine while building a site, but turn it off the day you launch or the live site will never rank. For real privacy use HTTP Basic Auth, not this checkbox.

Can I hide a WordPress page from Google without a plugin?

Technically yes, via wp_head filters in your theme’s functions.php to inject a per-page meta tag based on post ID. In practice every site already has an SEO plugin and the per-page toggle is one click. Skipping the plugin trades a recurring maintenance burden for a one-time install.

Does removing a page from the menu hide it from Google?

No. Menu visibility and search-engine indexing are independent. Removing a page from the menu only hides it from your site’s navigation. To hide it from Google, set noindex on the page using the per-page SEO plugin toggle above.

How long does it take for a page to disappear from Google after I add noindex ?

Anywhere from a few days to several weeks, depending on how often Google crawls the page. Force a recrawl with Search Console’s URL Inspection > Request Indexing. For an emergency removal (leaked draft, sensitive content), use Search Console’s Removals tool to suppress the URL for ~6 months while noindex does the permanent work.

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.

For the specifically-staging use case, every WordPress install on Hostney also has a dedicated Staging tab that clones the site to an unguessable .staging.hostney.app URL with its own database. The staging URL is already noindex’d at the server level ( X-Robots-Tag: noindex plus a footer banner so any human visitor knows they are not on the real site), so you do not need to add Password Protection on top – the URL is unguessable and search engines are blocked before the page renders. When the staging copy is ready, Push to production promotes files and selected database tables back with URL rewriting handled automatically. Password Protection is still the right tool for any subdomain you want behind a credentials wall (an internal-only site, a pre-launch build on your own domain rather than .staging.hostney.app , a docs site for paying customers); the dedicated staging tab is the right tool when you specifically want a private clone of an existing WordPress install for testing.

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#

Different “hide it” goals, 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. To hide a single page from Google but keep it live, set per-page noindex in Yoast, Rank Math, or SEOPress and request a recrawl in Search Console. 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 – including a private blog where only members can read – 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.