To password-protect a standard WordPress page or post, change its visibility to Password Protected, enter a password of 20 characters or fewer, and save. For a whole-site visitor barrier, use a plugin that documents the coverage you need or supported hosting-level authentication. WordPress core does not provide a native whole-site visitor password setting.
Choose the access model before changing settings. A shared content password works for a small preview audience, but it is not a complete security boundary for sensitive records. Use Private visibility when named WordPress users and their permissions should control access. For staging or a broad temporary barrier, server-level authentication can stop requests before they reach WordPress. AI is not needed to decide who may view content or to enforce these controls.
Choose the right kind of protection
| Access need | Suitable control | Important distinction |
|---|---|---|
| One standard page or post for visitors with a shared password | WordPress Password Protected visibility | A visitor-facing gate. Everyone uses the same credential. |
| Content for authorized WordPress staff | Private visibility and appropriate user permissions | Access depends on named WordPress accounts and roles. |
| A visitor barrier for an entire site or directory | A suitable plugin or supported hosting/server authentication | Check content coverage, files, caches, exceptions, and administrator recovery. |
These are different access models, not a universal security ranking. WordPress documents Password Protected and Private visibility for individual posts and pages. Its visibility guidance does not provide a native whole-site visitor password setting.
Password Protected
Useful for a small preview audience. Anyone who has the password can use it, and revoking one person means changing the shared credential for everyone.
Private visibility
Use for internal editorial content when individual accounts, role permissions, and per-user revocation matter more than a simple visitor prompt.
Password-protect one WordPress page or post
The built-in control is documented for standard posts and pages. In the Block Editor, open the content and find Status and Visibility or the publishing panel. Change Visibility from Public to Password Protected, enter the password, then select Publish or Update. Labels can vary by editor and WordPress version; the WordPress settings sidebar guide describes the current editor context.
- Open the page or post you want to protect.
- Open its visibility setting and select Password Protected.
- Enter a password no longer than 20 characters. WordPress core saves only the first 20 characters for this post-password mechanism.
- Select Publish for new content or Update for an existing page or post.
- Test the result in a logged-out or private browser session. Keep the shared password in an access-controlled location, not in the page text or a public change log.
The 20-character limit applies to WordPress core’s built-in post and page password mechanism. Do not apply it automatically to a plugin or hosting-level authentication. Also, do not assume this workflow covers a WooCommerce product or another custom post type. Confirm support for that content type on the target site or use a plugin that explicitly documents it.
A previous successful visit can leave a password cookie in the browser, so a logged-in or previously authenticated session is not a reliable visitor test. The verification section below covers a clean retest and alternate URLs.
Protect an entire site with a plugin
WordPress core does not include a whole-site visitor password. A plugin can be suitable when you need WordPress-level configuration or exceptions, but confirm the current edition and the exact content types it protects before relying on it.
PPWP, listed on WordPress.org, advertises site-wide protection. Its listing distinguishes some advanced capabilities, including protection for custom post types and search-result controls, as Pro features. The listing also says its site-wide protection does not cover media files. Treat these as the plugin’s advertised behaviors, then test the configuration on the target site.
A practical sequence is:
- Install the selected plugin through Plugins > Add New or its documented upload method, then activate it.
- Open the plugin’s site-wide protection settings and configure the documented gate, password, exclusions, or access rules.
- Record the intended scope before saving: pages, posts, custom post types, archives, feeds, and any exceptions.
- Test logged-out visitor access, administrator access, direct media URLs, and cache or CDN paths before rollout.
Do not infer file protection from a page prompt. A directly reachable PDF, image, or download can use a separate URL and may remain public. Check the plugin’s documented coverage and test the file URL directly.
Use hosting-level authentication for a site or directory
HTTP Basic Authentication places a server- or hosting-controlled credential challenge in front of a protected site, directory, or file. It can suit staging or a broad temporary barrier when you want the request stopped before it reaches WordPress.
Workflows are host-specific. Bluehost documents Directory Privacy in cPanel, where an authorized user can select a directory and configure access. DreamHost documents a more technical SSH method using .htpasswd and .htaccess. These are provider-specific examples, not universal instructions. Availability depends on the host, plan, permissions, and server stack.
- Ask the hosting administrator which supported control applies to the exact site path.
- Back up configuration files before editing them, then configure authorized accounts through the host’s documented method.
- Require HTTPS before sending credentials. Confirm that the CDN, reverse proxy, and host cache cannot serve the protected content without passing authentication.
- Test from an external logged-out session and verify that the WordPress dashboard and deployment recovery route remain available to authorized administrators.
Apache-specific directives should not be assumed to work unchanged on NGINX, LiteSpeed, or another server stack. If shell access or server directives are unfamiliar, have the host administrator make the change.
Access control is not the same as hiding a page from search
Password protection restricts access. A noindex directive asks a search engine not to include an otherwise accessible page in its results. Google must be able to crawl a page to see its noindex directive, so use authentication when unauthorized visitors must not see the content. Google’s noindex guidance explains the crawl requirement, while its guidance on controlling what you share covers protected content. A robots.txt crawl block is not a confidentiality control.
If visitors must not read the material, require authentication. If visitors may read it but you do not want it in Google Search, use an appropriate noindex implementation and allow Google to crawl the directive. A URL already indexed may not disappear immediately, so check existing results separately.
Verify the protection and preserve a recovery path
WordPress can remember a successfully submitted post password in a browser cookie. The developer reference for post_password_required() describes how core checks that cookie. Administrator permissions and cached responses can also make a test misleading. Use a clean private window or clear relevant cookies, and test administrator and visitor behavior separately.
- A logged-out visitor sees the expected prompt or denial.
- An incorrect password does not reveal protected content, while the correct password provides the intended access.
- Administrator and Editor behavior is tested separately from ordinary visitor behavior.
- Relevant excerpts, feeds, archives, XML sitemaps, REST responses, cached pages, and direct media URLs are checked.
- The site-wide control has a named recovery owner and a working route to disable or repair the lock.
- The test record contains outcomes, not passwords or other secret values.
For a team audit, record each configuration change as one event and keep periodic status snapshots in a separate dataset. The following is an illustrative record design, not a WordPress or plugin schema:
{
"event_id": "generated-unique-id",
"site_id": "site-01",
"content_id": 417,
"content_type": "page",
"protection_mode": "password",
"changed_at": "2026-10-14T14:30:00Z",
"changed_by": "user-23",
"verification_status": "passed"
}The row grain above is one protection-change event. Give event_id a generated unique value and enforce uniqueness in the database. If concurrent workers can write events, use a database uniqueness constraint and a transactional upsert rather than relying on a lookup followed by an insert. Store daily status snapshots separately at one row per site, content object, and calendar date. Do not use an IP address or an IP-plus-timestamp pair as the sole event key. Keep credentials outside the audit store.
Frequently asked questions
Can Editors or Administrators view a protected page?
WordPress permissions can let authorized users view content in the editing interface without behaving like a logged-out visitor. Test both paths separately.
Does the 20-character limit apply to every method?
No. It applies to WordPress core’s built-in post and page password mechanism, not necessarily to a plugin or hosting-level authentication.
Can a protected page’s PDF or image remain public?
Yes. A file has its own URL and may need its own control. Test the file URL directly instead of inferring protection from the page prompt.
Will a password-protected URL disappear from Google immediately?
No immediate removal is guaranteed. Authentication can prevent Google from accessing protected content, but an already indexed URL should be checked and handled separately.
What if caching hides or bypasses the prompt?
Retest in a clean session and compare the origin with the CDN or cache path. Ask the site or hosting administrator to review cache rules and purge relevant responses before considering the test complete.