Password Protect a WordPress Page

The built-in password, in five clicks

Open the page in the editor, click Visibility under the summary panel, choose Password protected, type a password and press OK, then Update. The page body is withheld until the visitor enters it. One password covers everyone, and the text is stored unencrypted in the posts table.

1. Go to Pages, then All Pages, and open the page you want to lock. The block editor and the classic editor both work.
2. In the right-hand panel, open the Summary tab (or the Publish box in the classic editor) and click Edit next to Visibility.
3. Select Password protected, type the password, and click OK. The button label changes to Password protected.
4. Click Update to save the page.
5. Open the page URL in a private window while logged out. You know it worked when the page shows a password form instead of the content, and the content appears only after the password is entered.

The same Visibility control exists for posts, so a single post can be locked the same way. The password is per item: two locked pages can have two different passwords.

What the built-in password does and does not do

WordPress checks a cookie before it renders the page body. That is enough for a client preview or a pre-launch page, and not enough for anything confidential.

That last row is the one people miss. Treat the built-in password as a curtain, not a lock: it keeps casual visitors and search crawlers out, and it does nothing against someone with wp-admin or a database dump.

Different passwords for different people

The core feature has one password per item and no usernames. When that is not enough, the options are three, and they solve different problems.

• Several shared passwords: a plugin such as Password Protected or Passster issues a role-based password and its own login screen.
• Real accounts: create a user with a role that can read the content, then set the page to Private so only users with editing rights see it.
• Membership: a membership plugin gates by role or subscription, which is the only option that scales past a handful of people.

Each adds a login surface to the site. If the group is external and temporary, a password is simpler than an account; if people leave and must lose access individually, accounts are the only workable answer.

Lock the whole site instead of one page

For a staging site or a pre-launch build, lock everything rather than a page at a time. Three routes work, and they differ in where the password is checked.

1. Plugin route: install Password Protected, enable it site-wide, and set one password in Settings, then Password Protected.
2. Server route, Apache: add a .htpasswd file outside the web root and an AuthType Basic block in .htaccess. The browser prompts before WordPress loads at all.
3. Panel route, cPanel: use Directory Privacy to protect the document root. This is the fastest method and needs no plugin.
4. Either way, exclude the health check and any webhook URL, or cron and uptime monitors will fail silently.

The server and panel routes protect static files and the admin area too, which the plugin cannot. That is why staging sites should use them rather than the built-in page password.

Caching, search and the leaks that surprise people

A protected page can still leak through three channels, and each has a specific fix.

• Page cache: a full-page cache can store the unlocked version and serve it to the next visitor. Exclude protected URLs from the cache, or purge after changing the password.
• Search: a page that was public before you locked it can stay in the index for weeks. Request removal in Search Console, and confirm the crawler now gets the password form.
• Media: an image uploaded to a protected page still sits at a public URL in wp-content/uploads. Crop or watermark anything genuinely private before upload.

After changing the password, the old cookie stops working and every visitor is asked again. That is the behaviour you want, and it is also why a cache purge belongs in the same maintenance step as the new password.

When the password stops working

Four causes cover almost every report of a protected page that opens without a prompt.

• You are still logged in as an editor, so WordPress shows the content and skips the form. Test in a private window.
• A caching plugin or CDN is serving a cached copy of the unlocked page. Purge it, then retest.
• A security or membership plugin has taken over the login flow and is bypassing the core check.
• A password with an apostrophe or a space was saved with a stray character. Reset it to letters and digits and retest.

If none of those apply, deactivate plugins one at a time on a staging copy. The cache clearing guide covers the purge steps for the common caching plugins and for a CDN in front of the site.

Where this fits on WebJi® hosting

None of this needs special hosting. It needs a WordPress install you can update and a cache you can purge, both of which are standard on WordPress hosting.

Email support@webji.services if a protected page behaves differently on the live site than on staging; include the URL and whether a cache or CDN sits in front. Support is 24/7 by email in Hindi and English, average first reply under 60 minutes. The office phone is not a support line.