WordPress password protected pages are useful when a page or post should remain published but should not be immediately visible to every visitor. Agencies can use them for client website previews, design reviews and approval pages, while site owners can use the same built-in visibility setting for limited-access content. The visitor receives a password prompt instead of the protected content, so the workflow does not require the visitor to have a WordPress account.
However, a post or page password should not be presented as comprehensive protection for every related asset, integration or delivery layer. WordPress documents specific behavior for the main content, excerpts, browser cookies, archives and custom fields. Themes, page builders, plugins and other systems may alter what is displayed. The practical approach is therefore to configure the visibility setting, test the public-facing URL while logged out and verify every location where the content or its metadata may appear.
When to Use Password-Protected WordPress Pages and Posts
Password Protected visibility is a practical option for a client preview, an approval page or other content that should be accessible to visitors who know a shared password. The content remains published, but WordPress replaces the normal view with a password prompt until the visitor supplies the required password. This makes the setting relevant when an external client needs to review a page without receiving a WordPress user account.
It is important to define the scope correctly. The documented behavior concerns page and post visibility; it does not establish complete protection for every cache, API response, feed, search system, attachment, media URL or other delivery layer. A protected page may also contain output generated by a theme or plugin. That output must be tested separately rather than assumed to inherit the same protection.
What visitors see before entering the password
Before entering the correct password, a visitor sees a password form instead of the protected content. For protected posts, WordPress also changes the displayed title and excerpt. This means the client-facing experience can differ from the normal published page, and the review should be performed from the public URL rather than from an authenticated administration view.
After a visitor successfully enters a password, WordPress stores it in a browser cookie so the visitor does not need to enter it again on every visit to the same protected content. When multiple posts use one password, the visitor may access them without entering the password again. WordPress tracks only one post password at a time, so separate project passwords should be planned with this behavior in mind.
Where the built-in setting may not be enough
The password setting should not be treated as equivalent to user-account authentication, role-based access control or comprehensive site security. The research does not establish that every related asset or integration is protected. This matters particularly when a page includes forms, embeds, custom metadata or content displayed through another template.
Do not place confidential information in custom fields or other output locations without verifying that the relevant implementation suppresses it until the correct password is supplied. Themes, page builders, caching systems and plugins may change the way protected content is displayed, so their behavior must be tested separately.
How to Password-Protect a WordPress Page or Post
The core WordPress workflow is available for both pages and posts. You change the visibility of the selected item in the editor, enter a password and save the change. The password requirement does not take effect until the page or post is published or updated.
The editor workflow for pages and posts
- Open the relevant page or post in the WordPress editor.
- Open the Visibility setting in the Publish or Status & Visibility panel.
- Change the setting from Public to Password Protected.
- Enter the password that visitors must supply.
- Publish the page or post, or update it if it is already published.
The setting applies to the individual page or post being edited. Record which password belongs to which preview and avoid assuming that a visibility change is active before the content has been saved.
Confirming the result
Open the public-facing URL in a logged-out browser session or a private browser window. Confirm that the password prompt appears before the protected content. This check is more useful than relying on an administrator view, because Editors and Administrators can see and modify protected content in the dashboard.
Enter the password and verify the resulting page. Check the layout, content and any elements that matter to the client review. If the prompt does not appear, return to the editor and confirm that the visibility setting was saved by publishing or updating the page or post.
Password Protected vs Private: Which Setting Should You Choose?
Both settings control visibility, but they serve different audiences. Password Protected content remains published and can be viewed by visitors who know the password. Private content is restricted to authorized WordPress users, documented in the default behavior as Editors and Administrators. The choice should therefore follow the way the intended audience is expected to authenticate.
Password Protected for external review
Password Protected is the more relevant built-in option when a client should review a page without creating or using a WordPress account. The client receives the public URL and a password, then sees the protected content after supplying that password.
This is suitable for a limited-access preview or approval workflow, but a shared password does not restrict access among site administrators or editors. It also does not prove that every related representation of the content is protected. The page should be checked while logged out and across the site components that display its information.
Private for authorized WordPress users
Private visibility is intended for authorized WordPress users rather than anonymous visitors who know a shared password. Normal visitors cannot view private content even if they guess the URL. In the documented default behavior, Editors and Administrators can see and modify private content in the administration area.
Choose Private when the content is intended for authorized internal site users. Do not use it as a substitute for a client password workflow, because it does not provide the same anonymous visitor experience.
Using Protected Pages for Client Approvals
An agency can use a password-protected page as a practical review stage before a page becomes public. This is a workflow built from the documented visibility behavior, not a formal built-in approval system. The agency remains responsible for collecting feedback, making revisions and checking that the page behaves as intended.
Sharing a review link and password
Create a draft or published preview page and set its visibility to Password Protected. After saving the change, open the client-facing URL while logged out. Send the page URL and password through separate communication channels. Ask the client to use the public URL rather than an authenticated dashboard view, so the review reflects the visitor experience.
Use a separate password for each client or project where practical. This limits accidental reuse and aligns with WordPress behavior that stores a successful password in a browser cookie. Before sharing the link, verify the page itself and the elements included in the review, such as forms, embeds, related content and displayed metadata.
Reviewing revisions before launch
Keep the page protected while the client reviews it. Collect feedback, apply revisions and retest the same URL after each meaningful change. Open the page again in a logged-out or private browser session and confirm that the password prompt still appears before access.
Do not switch the page to Public until the intended review is complete and the page has been checked again. The workflow does not guarantee that every page element is protected, so the agency should separately verify the layout, forms, embeds, related-content blocks and any metadata output by the theme or plugins.
Why Protected Content Can Still Show in Archives and Custom Fields
Changing a page or post to Password Protected does not necessarily remove every representation of that content from the site. WordPress documents separate limitations for archive listings and custom-field data. This is why a protected item must be tested beyond its individual URL.
Archive and home-page listings
Password-protected posts may still appear in places such as the home page or archive pages unless the site implementation explicitly excludes them from those queries or changes how they are displayed. A listing may therefore reveal that a post exists even when its main content is replaced by a password prompt.
Check the home page, archive pages, search or listing components and related-content blocks. If a protected post should not appear in a particular listing, the implementation may need to exclude it or change the display behavior. The exact result can depend on the theme or plugins controlling those templates.
Custom fields and metadata
Custom-field data is not automatically protected by the main post or page password mechanism. If a theme, template or plugin outputs metadata separately, that output may remain visible unless the implementation checks whether a password is still required before displaying it.
For this reason, do not store confidential information in custom fields or assume that a password prompt hides every associated value. Review every visible metadata location, including labels, summaries and related blocks that may be generated outside the main content area.
Troubleshooting and Safety Checklist
A short verification sequence helps identify problems before a preview is sent to a client. The goal is not only to confirm the password form, but also to check the other places where the content may be represented.
A pre-share verification sequence
- Confirm that the visibility change was saved by publishing or updating the page or post.
- Open the actual client-facing URL in a logged-out or private browser session.
- Check the main page or post before and after entering the password.
- Review the home page, archives, search or listing components and related-content blocks.
- Check custom fields and other metadata displayed by the theme or plugins.
- Verify the forms, embeds and layout elements relevant to the client review.
- Consider caching, API exposure, media URLs, feeds and search systems as separate layers requiring independent verification.
Repeat the check after revisions. A successful test in an administrator session is not enough, because authorized dashboard users can see protected and private content without representing the anonymous visitor experience.
What not to assume
Do not assume that a password prompt means every related asset, integration or delivery layer is protected. The documented WordPress behavior does not provide a complete security model for caches, feeds, APIs, attachments, media URLs or search systems.
Do not describe Password Protected visibility as full authentication or comprehensive site security. Do not promise that protected content is absent from every listing or indexing system unless those layers have been independently verified. Finally, remember that themes, page builders, custom fields, caching systems and plugins may alter default display behavior.
For a visitor-supplied client preview, choose Password Protected visibility, save the page or post and test it while logged out. For content intended for authorized WordPress users, choose Private visibility instead. In both cases, verify archives, custom fields, related output and other delivery layers before sharing or relying on the content as restricted. Explore our WordPress plugins, WooCommerce extensions, themes and membership plans to find the right tools for your website.