Password Protecting a WordPress Page

Fifteen seconds, no plugin. Open the page, find the visibility or status setting in the editor sidebar, choose Password protected, type a password, and update. Visitors now get a password form instead of the content.

The rest of this page is the part that actually matters: what that protection does and does not cover, because several of the gaps are surprising.

Setting it

In the block editor the control is in the right-hand sidebar under the page's status settings. Pick Password protected, enter the password, then Update. The same control offers Private, which is a different thing covered below.

Three things happen immediately:

• The page now shows a password form to anyone who has not entered it.
• Its title stays visible everywhere, prefixed with "Protected:" in listings and archives.
• The password is one shared string. Everybody who needs access uses the same one.

To remove protection, set visibility back to Public. Clearing only the password field is not enough in every editor version, so check the front end afterwards.

What the protection actually is

Understanding the mechanism explains every limitation.

The password is stored on the post row. When a visitor submits the form, WordPress sets a cookie in their browser recording that they passed, and that cookie unlocks every post using the same password. It lasts about ten days by default. There is no account, no login, and no record of who entered it.

That second row is the one that bites. An image attached to a protected page still lives at its own wp-content/uploads/ address, served directly by the web server, which has never heard of post passwords. Anyone with the link opens it, and if the file is linked anywhere it can be indexed. The same applies to a PDF you attached, which is usually the file that mattered.

If protecting the files is the actual requirement, you need a plugin that moves uploads out of the public directory or serves them through PHP. The general behaviour of the uploads folder is covered in the WordPress media library.

Caching will leak it

This is the most common real-world failure, and it looks like WordPress is broken.

A page cache stores the rendered HTML and serves it to everyone. If the cache captures the page while you are viewing it unlocked, every subsequent visitor gets the unlocked copy without a password. Nothing in WordPress prevents this.

Two things to do:

1. Exclude protected pages from the page cache, by URL, in the caching plugin or at the CDN.
2. Purge what is already stored, then test in a private window, per clearing the WordPress cache.

Test from a browser that has never visited the page. Your own browser holds the unlock cookie, so it will show the content regardless and tell you nothing.

Password protected, private, or draft

Three different tools, regularly confused:

• Password protected. Anyone with the password, no account needed. For sharing with clients or a group.
• Private. Visible only to logged-in editors and administrators. Nobody else can reach it even with the URL, and it returns a 404 to everyone else. For internal pages, and it depends on roles, as WordPress user roles explained sets out.
• Draft. Not published at all. Preview links are the way to share it, and those links are guessable in some setups.

Choose Private when the audience already has accounts. Choose password protection when they do not and you do not want to create any.

When a plugin is genuinely needed

Core's version is deliberately simple. Reach for a plugin when you need:

• Different passwords for different people, or any record of who accessed what.
• Access that expires on a date or after a number of views.
• Protection for uploaded files, not just the page content.
• A whole site behind one gate, which is closer to maintenance mode or a coming soon page.
• Content tied to membership, where access follows a subscription rather than a shared secret. That is a membership system, described in building a WordPress membership site.

For a site-wide gate during development, HTTP authentication at the server is simpler and stronger than any plugin, and it covers the files too.

Be honest about the strength

A shared password protects content from casual access. It is not a security control, and it should not hold anything whose exposure would matter:

• The password is shared, so it leaks the moment one recipient forwards the email.
• There is no rate limiting on attempts by default.
• The URL and title remain public.
• The files are public, as above.

For anything genuinely sensitive, use accounts and roles, and treat the rest of the site accordingly, per the WordPress security checklist.

Common mistakes

• Testing in the browser you set it up in. The unlock cookie is already there.
• Assuming attached files are covered. They are not.
• Leaving the page in the cache. The most common leak by far.
• Using a memorable shared password across many pages. One cookie unlocks all posts sharing that password.
• Protecting the parent and forgetting the children. Protection does not cascade down a page hierarchy.
• Relying on it for confidential documents. Use accounts instead.

Verify

Open the page in a private window and confirm the form appears. Enter the password, confirm the content loads, then close the window and open a fresh one to check it locks again. Copy the direct URL of an image on that page and open it in the private window, so you see for yourself whether files are exposed. Finally, search your site for the page title while logged out and confirm what a stranger can learn from the listing alone.