How to password protect a WordPress page

Clients often want to see a page before it goes live. A printer needs to check the new menu, a client needs to approve a gallery, or a partner needs to read a draft announcement. WordPress has a built-in setting for this. It needs no plugin and no user accounts, and it takes about a minute.

It also does less than most people expect. The password covers the page’s main content. It doesn’t cover the files on the page, and it doesn’t record who got in. Most “it doesn’t work” reports come from caching, not from the setting itself. This guide covers the steps, how to check the result, what stays exposed, and how to fix it when the right password fails.

Password protected or private: which one do you need?

Choose Password protected when the people who need access don’t have accounts on your site. Choose Private when only logged-in staff should see the page. The WordPress.org support handbook says Private pages are visible only to logged-in users with the Administrator or Editor role. A password-protected page is visible to anyone who has the password.

Both options keep the page out of normal view. As our guide to adding pages in WordPress explains, they also keep it out of menus and the homepage selector. That is fine for a client preview. It can surprise you on a page you meant to link from the navigation.

How to password protect a page in the block editor

You need an account that can edit and publish the page, usually Editor or Administrator. Content access is all this task needs. You don’t need hosting or FTP access.

1. Go to Pages, then All Pages, and open the page in the editor.
2. If the right-hand sidebar is hidden, click the Settings icon in the top bar. Select the Page tab, not the Block tab.
3. Click the Status control. On older versions it is labelled Visibility: Public.
4. Choose Password protected. Some versions show it as a checkbox below the status options.
5. Type the password in the field that appears.
6. Click Update, or Publish if the page is new. The setting doesn’t apply until you save.

There are two other routes. On the Pages list, hover over the title, click Quick Edit, fill in the Password field and click Update. In the Classic Editor, the same control sits in the Publish box as Visibility: Public with an Edit link next to it.

A few mistakes come up again and again. People tick Private by mistake, close the editor without clicking Update, or set the password on the wrong page in a set of similar drafts. A WordPress.org support thread notes that if the option is missing completely, a theme or plugin has probably changed the editor. To check, test with a default theme.

If you’d rather not do this yourself, SiteSelf can set page visibility through chat. It uses the connector plugin’s access, then fetches the page and reports whether the password prompt appears. Pages owned by a visual page builder are refused, and the reason is given.

What a correct result looks like

A logged-out visitor should see your theme’s header and footer, the page title, and a password form where the content would normally be. After the right password, the full content loads. After a wrong one, current versions of WordPress show an error message on the form.

Test in a private or incognito window that has never opened the page. Two things can give you a false result in your normal browser:

• You’re logged in. Testing as an admin doesn’t show you what a visitor sees.
• The cookie. WordPress’s documentation says that after a correct entry, the browser stores a cookie. Visitors who return don’t have to type the password again. Your own browser may skip the prompt and make it look as if protection failed.

The cookie has one more effect. WordPress remembers one post password at a time. Pages that share a password unlock together. Pages with different passwords ask again when the visitor moves between them. A shared password across a set of client pages is convenient. It also means anyone with one link and the password can read all of those pages.

What the password does not protect

The setting hides the page’s main content from people who don’t have the password. Several things sit outside that.

Images, PDFs and other uploads

Files in the media library have their own URLs. Anyone with a file’s URL can still open it, and search engines can still index it. The plugin page for PPWP, one of the main protection plugins, says its page protection doesn’t cover uploaded files either. If a file is the confidential part, protect the file itself. Restrict direct access on the server or move the file to protected storage. Our guide to embedding PDFs in WordPress explains why hiding a download button protects nothing.

Custom fields and custom templates

WordPress’s documentation warns that custom field data isn’t protected automatically. WordPress hides what the_content() outputs. Content from ACF fields, a custom loop, or a template that prints post data directly can still show up under the password form. Wrap that output in a post_password_required() check:

<?php if ( ! post_password_required() ) : ?>
    <?php echo esc_html( get_post_meta( get_the_ID(), 'client_notes', true ) ); ?>
<?php endif; ?>

To find a leak, view the protected page logged out and read everything below the form. Anything you can read there is coming from a template or a field, not from the page content.

WooCommerce catalog listings

WooCommerce’s documentation says a password-protected product still appears in the catalog. Only the single product page asks for the password. To hide the product from the shop, category pages and search results, open the product. In the Publish box, click Edit next to Catalog visibility, choose Hidden, and update the product. Catalog visibility can also be changed for many products at once with Bulk Edit.

Search listings

A password hides the content. It doesn’t tell search engines to drop the page. The URL and title of a protected page can still appear in search results, and files linked from the page can be indexed separately. If the page shouldn’t be found at all, set it to noindex in your SEO plugin as well. Don’t count on robots.txt to keep it out of results.

Why the correct password does not work

The causes below are ranked by how often they come up in support threads and forums. The ranking reflects how often each cause appears in reports. It is not a measured failure rate.

1. A cache is serving the password form

Signs: the right password reloads the form, it works on the second try, or it works for some people and not others. A page cache, server cache or CDN has saved the locked version of the page and keeps serving it. In a 2023 WordPress.org thread, the fix was to clear the cache and exclude the page from LiteSpeed Cache. A 2025 r/Wordpress post reported the same problem with LiteSpeed Cache on OpenLiteSpeed. WP Super Cache has a GitHub issue on the same symptom.

1. Purge every layer: the caching plugin, the host’s server cache, then the CDN (Cloudflare or your host’s edge cache).
2. Exclude the protected page’s URL from page caching. Use your caching plugin’s “never cache” URL list, or ask your host to add the exclusion.
3. Retest logged out in a new private window. Check both that the password opens the page and that a fresh window still shows the form.

Step 3 needs both checks. In the LiteSpeed thread, changing the cache rules led to the page apparently skipping the password altogether. There’s also a cost: excluded pages load without the cache. One user with a gallery of more than 150 images found it slower and accepted that. If you use a protection plugin, follow that plugin’s own cache instructions. PPWP, for example, documents its own cookie names. Those names don’t apply to core or to other plugins.

2. You are testing in a browser that is already unlocked

If the page never asks for the password, check whether you’re logged in, or whether this browser has already entered the password. A private window, a different browser, or clearing the site’s cookies settles it. Browser extensions that block cookies can also stop the password from being remembered.

3. A blank page or the homepage after the right password

The password form sends the visitor to wp-login.php?action=postpass, which should then send them back to the page. Before WordPress 6.8, that return trip depended on the browser’s referrer. A Referrer-Policy: no-referrer header from a security plugin or server config could leave visitors on a blank screen. In a 2024 Bricks Builder forum case, the blank screen was /wp-admin/?action=postpass. The cause was a no-referrer policy, not the builder.

WordPress 6.8 added a hidden redirect_to field to the password form so the return no longer depends on the referrer. Check your WordPress version first. Updating core is the lasting fix. On one older install in a WordPress.org thread, changing the header to strict-origin-when-cross-origin fixed it. If you change the header instead, test anything else on the site that relies on referrers.

4. Theme code or a plugin is interfering

Injected code can break the form or the redirect. In a 2020 GeneratePress forum case, the cause was a Google Analytics hook added through the GP Premium Elements module. Switching themes didn’t help, because the module stayed active. The GoDaddy server cache also hid the result of each test until it was flushed by hand. Content-restriction plugins can also catch the request and send visitors to the homepage. In a 2023 case, a Profile Builder update fixed that.

To isolate the cause, switch to a default theme, then turn plugins off one at a time. Purge the cache between every test. Without the purge you’re testing a stale copy. Our guide to fixing plugins that are not working walks through the full conflict test.

When to stop and get help

Ask your host or a developer when any of these is true:

• The problem survives a default theme, all plugins turned off, and a full purge.
• You can’t see or change the server-level cache.
• You’d need to edit template files to stop a leak.

Give them the page URL, your WordPress version, your caching plugin, your host, and the exact screen or URL a visitor ends up on.

When a shared password is the wrong tool

A page password is light privacy for low-stakes content. One password goes to everyone, so you can’t remove one person without changing it for all of them. You also can’t tell who opened the page or passed the password on. Practitioners on r/Wordpress are blunt about it: it isn’t a way to share confidential documents securely.

• A whole-site lock, several passwords on one page, or protection for part of a page: you need a plugin. Password Protected and PPWP – Password Protect Pages both add these. Every plugin also adds its own updates and cache rules to maintain.
• Each person needs their own login, access is paid, or access must expire: use WordPress user accounts and roles, or a membership plugin.
• Personal data or work under NDA: don’t put it behind a shared password. Having a password doesn’t give anyone permission to share confidential client work.

A password set by your host is a different feature. It locks the whole site at the server, and some hosts say their site lock doesn’t work with their CDN or edge caching. It doesn’t fix a problem with one page’s password.

How to remove protection or replace a forgotten password

To remove the gate, open the page, set the status or visibility back to Public, and click Update. Then purge your caches. Otherwise visitors may keep getting the old password screen.

If you forgot the password but can still edit the page, just type a new one in the same field and save. Then send the new password only to the people who still need access. Everyone using the old one is locked out.

If you have server access but can’t log in, WordPress stores the page password in plain text in the post_password column of the wp_posts table. With WP-CLI, wp post update 123 --post_password='new-password' sets a new one, where 123 is the page ID. An empty value removes the password. Take a backup before you change the database.