What Actually Happens When You Password Protect a Page on Your Website

A wholesale bakery in Kildare supplies cafés and delis across the midlands. Every quarter the owner updates one page on the website with the new trade rates, then emails the address to the account list. That page is not in the navigation. Nothing links to it. As far as the owner is concerned it is private, because the only way to reach it is to be handed the address.

We see a version of this every few months, so take it as a pattern rather than one company's bad quarter. A competing supplier turns it up in a Google search for a product name and a price. Now a rival is holding the full trade sheet, line by line, and can price against every item on it. Nobody hacked anything. There was no password to guess, because nobody had set one.

Hiding a page and protecting a page are two different jobs. One relies on nobody looking. The other relies on a lock.

Unlinked Is Not Unlisted, and Unlisted Is Not Private

Google is unusually direct about this in its own crawling documentation. A page that is disallowed in robots.txt can still be indexed if it is linked to from other sites, and when that happens the address itself, along with the anchor text pointing at it, can appear in results. The same documentation adds a detail that catches people out constantly: a noindex tag only works if the crawler is allowed to fetch the page and read it. Block the page in robots.txt and the crawler never sees the instruction you left for it.

Google's guidance on controlling what you share leaves no room for interpretation either. If you have confidential or private content on your site, it says, you need to password protect it to ensure only authorised users can access it, and doing so will also prevent that content appearing in Google Search or eventually remove it if it already does.

Read that again. Password protection is not one option among several. It is the mechanism Google names when the content genuinely matters.

An address with no links pointing at it leaks in ways that have nothing to do with search engines crawling your menu:

• Somebody forwards the email, and it lands in an inbox that syncs to a device you have never heard of
• A sitemap plugin lists every published page by default, because that is what sitemap plugins are built to do
• A reader clicks an outbound link from your protected page and the referrer header hands your address to whatever site they landed on
• Someone pastes it into a group chat, a support ticket, or a shared document that later gets indexed

None of those require malice. They require one person being helpful on a Tuesday.

I spent a good while early on treating an unlinked address as a private one for a client-facing document, on the reasoning that you cannot find what you cannot see. Found it in search results a few months later. The lesson stuck, and it is the reason I now treat obscurity as a filing convenience rather than a control.

The Four Levels of "Not Public"

There are four distinct mechanisms here and they solve different problems. Choosing the wrong one is what produces the bakery's quarter.

Level	What it actually does	Who gets in	Right for
Unlinked or noindex	Removes the page from search results only	Anyone with the address	Thin or duplicate pages, nothing confidential
Password protected	Puts a password gate in front of the content	Anyone you give the password to	A group who all get the same access
Private visibility	Hides the page from the public entirely	Logged-in Administrators and Editors	Internal notes and staff-only material
Customer accounts	Restricts content to named logged-in users	One person, one login	Access you need to grant and revoke individually

Unlinked or noindex: keeps it out of Google, not out of reach

A noindex tag is a genuine tool and it does its job well. It tells search engines not to list the page, and unlike a robots.txt block it actually gets read, because the crawler is permitted to fetch the page in the first place. What it does not do is stop a human opening the address. Your trade prices are still one forwarded email from a competitor's inbox. Use noindex when you want a page tidy and uncounted, not when you want it confidential.

A password protected page: one lock, one shared key

This is WordPress's built-in answer and it is a good one. Open the page in the editor, change visibility from Public to Password Protected, set a password. Visitors who reach the address see the page title and a password box where the content used to be. For an account price list, a client download, or a members' notice, that is usually the correct level of protection.

There is a limitation worth knowing before a customer finds it for you. WordPress caps the password at 20 characters, and everyone you send it to holds the same one. Lose a trade customer and the only way to cut off their access is to change the password for every other customer at the same time, then send a new one to all of them. The documentation also flags something less obvious: anyone on your site holding an Administrator or Editor role can read protected and private content from the editing screen without the password, and can change it to public. That is fine when your team is three people who all know what they are doing. It matters when it is not.

Private visibility: for your own team, not your customers

Private is often confused with password protection and it behaves nothing like it. A private page vanishes from the public site entirely and appears only for logged-in users holding an Administrator or Editor role. Normal visitors will not know it exists. That makes it an internal tool, useful for a staff procedure or a draft you want out of the way, and completely useless for anything a customer needs to open. Send a private page's address to a café owner and they will get a page not found.

Customer accounts: a login per person

When access has to be granted and withdrawn one person at a time, you need accounts rather than a shared secret. Each customer logs in as themselves and the page checks whether they are entitled to see it. That solves the revocation problem cleanly, and it means you can tell who opened what.

It also changes your obligations, because you are now holding personal data. The Data Protection Commission's data minimisation principle requires that personal data be adequate, relevant and limited to what is necessary for the purpose you are processing it for. A trade login needs an email address and a password. It does not need a date of birth, a mobile number, or a copy of anything official. The Commission has taken that seriously in practice, having found that requiring photographic ID to verify a complainant's identity infringed data minimisation where the information at stake did not warrant it. Collect the minimum, say so in your Privacy Policy, and confirm any wider disclosure obligations with your solicitor.

The Trade-Off Nobody Mentions: Locked Pages Do Not Rank

Gating works by making content unreadable to anyone without the key, and search engines are firmly in that category. A protected page will not rank, will not accumulate authority, and will not send you a single visitor from Google. For a trade price sheet that is the entire point.

It stops being the point when the lock creeps outward. Gate a service description because it feels commercially sensitive and you have removed a page whose only job was being found by somebody who did not know you existed yet. That is not a security decision, it is a marketing decision made accidentally.

Publishers who need both, ranking and restriction, have a defined route. Google's structured data guidance covers subscription and paywalled content, and asks you to mark gated sections up so its systems can tell deliberate gating apart from cloaking, which is serving crawlers different content to what people see and which breaches its spam policies. Most local firms will never need that machinery. Knowing it exists is what stops you assuming a locked page is quietly still working for you in Search. It is not, and it was never meant to.

The blunt version: lock the pages whose value depends on being restricted, and leave everything else where customers can find it. If a page earns nothing by being hidden, hiding it costs you.

What a Proper Setup Looks Like

Before naming any platform, the criteria are worth stating on their own, because they are what you should be measuring against whatever you currently pay for.

A page restriction is doing its job when:

• The gate is enforced by the site itself, not by the address being hard to guess
• You can withdraw access from one person without disrupting everyone else
• The protected page is excluded from search results while the rest of the site stays fully indexable
• The restriction survives a plugin update, a theme change, and a migration to another host
• Adding it does not move you onto a more expensive plan

That last one is where hosted website builders quietly diverge from WordPress. On a platform that owns the whole stack, restricted content is a product tier, and the sophistication of your lock tracks what you pay each month. With full WordPress, the first three levels described above are core software behaviour. Password Protected and Private are visibility settings in the editor, available to every WordPress site that has ever existed, and account-based restriction is a plugin choice from the open directory rather than an upgrade. That is not a niche position to be standing in either: W3Techs put WordPress at 41.2% of all websites when I checked its figures this morning, which is roughly four in every ten sites on the web running software where this capability is simply present.

Web60 sites run full WordPress with the entire plugin and theme ecosystem available, on Irish infrastructure, and the €60 a year covers every feature with no per-feature charges. Locking a page is a setting you change, not a line item. If you would rather test the change before customers meet it, one-click staging environments let you set the restriction, open the page in a browser where you are not logged in, and confirm it behaves before it reaches production.

Access control only holds if the layer underneath it does. A page restriction sitting on a site with shared admin logins and no verified backups is a lock on a door in a wall nobody built, which is the argument made at length in our complete WordPress security and backup guide for Irish websites. The same logic applies inside your own team: if four people hold Administrator accounts, four people can read every protected page and republish it, so getting WordPress user roles right is part of this decision rather than a separate housekeeping task.

Where an All-In-One Platform Genuinely Wins

If what you actually want is to sell access, the calculation changes, and I would not pretend otherwise.

A business running paid memberships or an online course needs accounts, recurring billing, failed-payment handling, and content release schedules working together on day one. Hosted platforms such as Squarespace ship member sites with all of that assembled and supported as a single product. For someone who wants to charge for content this quarter and has no interest in choosing between plugins, that is genuinely the shorter route, and pretending otherwise would be dishonest.

Read the fee schedule before you commit, though. Squarespace's own billing documentation sets transaction fees on digital product revenue by plan tier, running from 7% on its entry plan down through 5% and 1% to 0% on its top tier, so the platform takes a cut of every membership sale that shrinks only as your subscription cost climbs. It also notes that standalone Digital Products plans stopped being available to new customers in July 2026, leaving a site plan upgrade as the route to lower fees. For a business simply restricting a price list to existing account customers, with no money changing hands on the page, that entire apparatus is overhead you would be paying for and never using.

Locking a Page Without Locking Yourself Out

Five steps, in order, before you restrict anything customers depend on.

1. Classify. Decide what the page is worth to someone who should not have it. Commercially sensitive means locked. Merely untidy means noindex.
2. Choose. Match the mechanism to the group. One shared audience gets a password, staff-only material gets Private, and anything you may need to withdraw from one person gets accounts.
3. Deploy. Apply the restriction on staging first, so the change is verified somewhere that does not have customers on it.
4. Verify. Open the address in a private browser window where you are not logged in, and confirm you are stopped. This is the step people skip, and it is the only one that proves anything.
5. Review. Put a date in the calendar. Rotate a shared password when someone leaves the group, and check who still holds accounts twice a year.

Nothing on that list takes more than a few minutes. The one that matters most is the fourth, because every failure described in this article is a failure someone would have caught by simply trying the address as an outsider.

Conclusion

That bakery's price list was never really hidden. It was published, and then not advertised, and the gap between those two things is where the damage sits. That gap is not obvious until something comes through it, which is why so few people close it in advance.

You already know which pages on your site you would not want a competitor reading over breakfast. The useful question now is a narrower one: for each of them, is there an actual lock, or just a quiet hope that nobody has the address? Checking takes about a minute per page, and the answer is either reassuring or extremely worth knowing.

Frequently Asked Questions

How do I password protect a page on my website?

In WordPress, open the page in the editor and change its visibility from Public to Password Protected, then set a password. Visitors who reach the address see the page title and a password box instead of the content. The password is limited to 20 characters and everyone you give it to holds the same one, so it suits a single group rather than individually managed access.

Is an unlinked page on my website private?

No. An address that is not linked from your menu can still be discovered through a forwarded email, an automatically generated sitemap, a referrer header, or a link posted anywhere else on the web. Google's documentation states that a page disallowed in robots.txt can still be indexed if it is linked to from other sites, and that confidential content needs to be password protected to keep it out of Search.

Will a password protected page hurt my SEO?

A protected page will not rank, because search engines cannot read content they cannot reach. For a trade price list or a client resource, that is the intended outcome. The risk is gating something you actually wanted found, such as a service description or a case study, so restrict only the pages whose value depends on being restricted.

What is the difference between private and password protected in WordPress?

Password protected shows a password box to anyone holding the address, which makes it usable by customers who have no account on your site. Private removes the page from public view entirely and shows it only to logged-in users with an Administrator or Editor role, which makes it an internal tool rather than a customer-facing one.

Can I give each customer their own login instead of one shared password?

Yes, by issuing user accounts and restricting the page to logged-in users. That lets you revoke one person without disturbing everyone else, which a shared password cannot do. It also means you are holding personal data, so collect only what the login genuinely requires and say so in your Privacy Policy.

Does a password protected page still work after I move hosts?

Visibility settings are stored in your WordPress database, so a complete migration carries them across intact. Restrictions added by a plugin depend on that plugin being installed and licensed on the new host, which is worth verifying on the destination site before you point your domain at it.

Sources

• Block Search Indexing with noindex, Google Search Central
• Control What You Share on Search, Google Search Central
• Subscription and Paywalled Content Markup, Google Search Central
• Set Blog Content Visibility, WordPress.org Documentation
• Principles of Data Protection, Data Protection Commission
• WordPress usage statistics, W3Techs