Password Protect a WordPress Page

Open the page, change its visibility to Password protected, type a password and click Update; WordPress then shows a password form instead of the page body to every logged-out visitor. The feature is built into core, so no plugin is needed, and it works the same way for posts.

1. Go to Pages → All Pages and open the page you want to lock.
2. In the block editor's right-hand Page settings, open the Summary panel and click the status or visibility value. Recent versions show a Password protected checkbox in the Status popover; older versions and the Classic Editor show Visibility: Public → Edit in the Publish box.
3. Select Password protected, type the password and confirm.
4. Click Update (or Publish for a new page).
5. Open the page URL in a private window while logged out. It has worked when you see the title and a password form, and the content appears only after the password is entered.

Each page has its own password, so two locked pages can use two different ones. Pick a password you do not use anywhere else; the WebJi® password generator creates one in a click.

It is a curtain, not a lock: fine for a client preview, a draft price list or a pre-launch page, but not for confidential documents. The password itself is stored in plain text in the post_password column of the posts table, so anyone with database access or a backup can read it.

• One password for everyone: no usernames, so you cannot revoke access for one person without changing it for all.
• No file protection: attachments in wp-content/uploads keep public URLs. Do not upload genuinely private files to the media library.
• Other admins can read it: every Editor and Administrator sees protected pages in the editor, with or without the password.
• Search engines: crawlers receive only the password form, so the content is not indexed, but a page indexed before you locked it can show an old snippet for a while.

To lock an entire staging or pre-launch site, protect it at server level with HTTP Basic Authentication, which prompts for a username and password before WordPress, images or wp-admin load at all. A site-wide plugin is the alternative, but it cannot protect static files.

On cPanel, Directory Privacy sets this up for the document root without editing files. On any Apache or LiteSpeed host, create the password file outside the web root and add a block to .htaccess:

htpasswd -c /home/USERNAME/.htpasswds/staging.htpasswd client

AuthType Basic
AuthName "Staging site"
AuthUserFile /home/USERNAME/.htpasswds/staging.htpasswd
Require valid-user

Replace USERNAME with your account name; -c creates the file, so leave it off when adding a second user. Basic Authentication sends credentials with every request, so use it only over HTTPS. Uptime monitors, payment webhooks and external cron calls will now be refused too; exclude those paths or pause them. The full staging workflow is in how to create a WordPress staging site, and the file itself is explained in the .htaccess guide.

Almost always because you are logged in as an Editor or Administrator, a cache is serving an unlocked copy, or a plugin has replaced the core check. Work through these in order.

1. Test in a private window while logged out; editors never see the form.
2. Purge the page cache and any CDN copy, then retest. Exclude protected URLs from full-page caching so an unlocked copy is never stored; the steps for common caching plugins are in how to clear WordPress cache.
3. Remove any 10-day unlock cookie by testing in a fresh browser profile.
4. Deactivate security, membership and page-builder plugins one at a time on a staging copy to find one that bypasses the form.

Every step works on standard WordPress hosting. If the live site behaves differently from staging, email support@webji.services with the URL and whether a CDN sits in front.