How to password protect a WordPress site, page, or directory

There are three completely different things people mean when they say “password protect my WordPress site,” and the right fix depends on which one you actually need. The method you pick for a single page that you want to share with a client is not the same method that keeps a staging site out of Google, which is not the same method that stops someone from downloading a PDF straight from /wp-content/uploads/ via a guessable URL. Picking the wrong one means either exposing content that should have been private or locking out people who should have access.

This guide walks through each scenario – individual pages, whole sites, specific directories, and the media-files edge case that most how-tos skip – explains when to use which method, and points out the specific failure modes for each.

The three layers you can protect at#

Before picking a method, it helps to understand that WordPress content can be protected at three different layers, and each layer stops a different class of access.

Application layer (WordPress itself). WordPress checks the user’s session or a page password before rendering content. This is what the built-in “password protected” post setting does, and what most “members only” plugins do. It runs after WordPress has already booted, after the database has been queried, after plugins have loaded.

Web server layer (nginx or Apache). The web server demands credentials before it will even hand the request to PHP. This is HTTP Basic Authentication, configured via .htpasswd files in nginx or Apache. Nothing reaches WordPress until the credentials check passes.

File system layer (direct file URLs). Requests for files that exist on disk – images, PDFs, video, any /wp-content/uploads/... URL – are usually served directly by the web server without involving WordPress at all. Page-level protection does not cover these. You need a specific approach, covered at the end of this guide, to protect them.

The right layer depends on what you are trying to stop. Casual “do not let random visitors read this page” is an application-layer problem. “Keep this entire staging environment out of Google” is a web-server-layer problem. “Do not let someone download the PDF I forgot to unlink from a private post” is a file-system problem.

Password protecting a single page or post (built-in WordPress)#

For a single page or post visible only to people who have a password, WordPress has this feature built in. No plugin needed.

1. Open the post or page in the block editor
2. In the right sidebar, under the Post tab, click Visibility (it says “Public” by default)
3. Select Password protected
4. Enter a password and click the Public button again to confirm

The page is now accessible at its normal URL, but visitors see a password form instead of the content. Anyone with the password can read it. That is the whole feature.

What this actually does. WordPress sets a cookie called wp-postpass_[hash] when someone enters the correct password. For the next 10 days (WordPress’s default), they can read this page (and any other page that uses the exact same password) without re-authenticating. The password lives in the post’s post_password column in the database and is stored as a plain hash.

What to use it for. Sharing something specific with a client, a private announcement to a small group, content you want readable by a handful of people without creating user accounts for them.

What not to use it for. Anything you seriously need to keep private. The protection is weak: the password is shared (anyone with the link and the password has access), cached copies of the rendered page may exist in browser history or CDN caches depending on your configuration, search engines may index the password prompt itself (which sometimes leaks the post title), and excerpts may still appear in RSS feeds and sitemaps. For genuinely private content, use proper user accounts with membership plugins, or move to the web-server-layer approach below.

One practical gotcha. If your site uses page caching (WP Rocket, W3 Total Cache, LiteSpeed Cache, Hostney’s built-in FastCGI cache, or a CDN), the password-protected page can end up cached as the password-entry form and served to everyone who entered the correct password once, or – worse – the unlocked content can be cached and served to visitors who never entered a password. Every caching layer needs to be told to respect the wp-postpass_* cookie and serve different variants based on it. Most caching plugins handle this correctly by default. CDN configurations and custom nginx cache rules often do not.

Password protecting the entire WordPress site (HTTP Basic Auth)#

For an entire staging site, a pre-launch site, or any site you want to keep out of search engines and away from casual visitors, web-server-layer HTTP Basic Authentication is the right tool. A browser dialog pops up asking for credentials, nothing loads without them, and the site is invisible to search crawlers, bots, and anyone without the password.

The mechanics: nginx (or Apache) reads a .htpasswd file containing username/hashed-password pairs. When a request arrives, the server checks the Authorization header against the file. No credentials or wrong credentials means a 401 Unauthorized response before the request ever reaches PHP.

Creating a .htpasswd file

If you are configuring this manually on your own server:

# Create the first entry (-c creates the file)
htpasswd -c /etc/nginx/.htpasswd yourname

# Add additional users (omit -c to append)
htpasswd /etc/nginx/.htpasswd secondname

htpasswd prompts for a password, bcrypt-hashes it, and writes the user:hash line to the file. The file lives outside the web root so it cannot be downloaded over HTTP.

nginx configuration

Add two directives inside the server block (or inside a specific location block if you only want to protect part of the site):

server {
    server_name staging.example.com;

    auth_basic "Staging site - credentials required";
    auth_basic_user_file /etc/nginx/.htpasswd;

    # ... the rest of the server block
}

Reload nginx ( nginx -s reload or systemctl reload nginx ) and the protection is active immediately.

The string in auth_basic is the “realm” – the browser shows it in the credentials dialog so you can tell which site is asking. Make it descriptive.

What this stops (and what it does not)

Stops: Casual visitors, every known search engine crawler (Googlebot, Bingbot, and so on – they do not solve Basic Auth challenges), AI training crawlers, most scanning bots, anyone who lands on a URL by accident.

Does not stop: Anyone who has the credentials. Basic Auth is a shared-secret mechanism – if the password leaks, rotate it. Also does not protect against someone on the same network sniffing the credentials over HTTP: Basic Auth base64-encodes the password but does not encrypt it, so HTTPS is mandatory. On a site without a valid certificate, the credentials are sent in effectively plain text on every request.

The REST API, cron, and loopback gotchas

The single most common problem with site-wide basic auth on WordPress is that WordPress itself does not know the credentials. Several features rely on WordPress making HTTP requests to itself:

• WP-Cron fires scheduled tasks by hitting /wp-cron.php on every page load. If the entire site requires basic auth, these requests fail with 401 and scheduled posts, scheduled backups, and transient cleanup all silently break.
• The REST API is used by the block editor (Gutenberg) for autosaves, by site health checks, and by many plugins. With basic auth in front, those features fail with 401 and usually surface as cryptic “updating failed” errors in the editor. The symptoms are covered in WordPress updating failed or publishing failed – how to fix it.
• Loopback requests (WordPress making requests to its own URL for background tasks) fail the same way. The Site Health screen in wp-admin will report this as a critical issue.

The fix is to exclude WordPress’s own internal paths from basic auth:

server {
    auth_basic "Staging site";
    auth_basic_user_file /etc/nginx/.htpasswd;

    # Let WordPress talk to itself without credentials
    location ~ ^/wp-cron\.php$ {
        auth_basic off;
    }

    location ~ ^/wp-json/ {
        auth_basic off;
    }
}

Be careful with the REST API exception: if you open /wp-json/ to unauthenticated requests, anything your site exposes over REST (including potentially the user list at /wp-json/wp/v2/users ) becomes visible again. For a genuine staging site that should be fully private, it is often simpler to leave /wp-json/ protected and disable server-triggered cron by setting define('DISABLE_WP_CRON', true); in wp-config.php, then trigger cron via a proper cron job that includes the basic auth credentials.

A 401 dialog where you did not expect one is covered in the 401 Unauthorized error guide, which walks through every common cause including .htpasswd misconfiguration, path mismatches, and credentials with special characters.

Why this is the right choice for staging environments

Staging environments benefit specifically from basic auth because it handles multiple concerns in one layer. It hides the site from search engines without relying on the fragile noindex meta tag. It prevents the accidental indexing of duplicate content that creates SEO penalties when staging gets discovered. It stops AI crawlers from training on content that is not public yet. And it blocks the whole class of bot traffic that would otherwise pointlessly hammer your staging WordPress install.

The full staging workflow, including how basic auth fits alongside search engine discouragement and subdomain isolation, is in how to create a WordPress staging site.

Password protecting a specific directory#

A specific directory – say, /wp-admin/ for extra login-form hardening, or a /docs/ folder for gated documentation – uses the same basic auth mechanism but scoped to a location block.

Protecting wp-admin with basic auth

Adding basic auth in front of /wp-admin/ is a long-standing WordPress hardening practice. It puts a browser credential dialog in front of the login form, which eliminates the entire class of brute-force attacks against /wp-login.php because the attacker never reaches the login form.

location ~ ^/(wp-admin/|wp-login\.php) {
    auth_basic "Admin area - credentials required";
    auth_basic_user_file /etc/nginx/.htpasswd-admin;

    # ... existing PHP handling
}

Note the regex matches both /wp-admin/ and /wp-login.php – brute-force attackers hit /wp-login.php directly, so protecting only /wp-admin/ does nothing.

Protecting a custom directory

For a static directory (documentation, internal resources, protected downloads):

location /private-docs/ {
    auth_basic "Private documents";
    auth_basic_user_file /etc/nginx/.htpasswd-docs;
}

Everything under /private-docs/ now requires credentials. This works for any directory whether it is served by PHP, served as static files, or generated by some other backend.

Allow specific IPs to skip authentication

A common pattern: office IPs should not be prompted for credentials, but everyone else should be. nginx supports this directly:

location /wp-admin/ {
    satisfy any;

    allow 203.0.113.0/24;   # Office network
    allow 198.51.100.42;    # Your home IP
    deny all;

    auth_basic "Admin area";
    auth_basic_user_file /etc/nginx/.htpasswd-admin;
}

satisfy any means the request is allowed if either the IP allowlist matches or the credentials are correct. Office visitors get through with no prompt. Everyone else sees the credentials dialog. Without satisfy any , the default is satisfy all , which requires both.

Protecting media files (the edge case most guides miss)#

This is the variant that trips most people up: you have a post that is password-protected at the WordPress level, and it has a PDF or an image attached. The post itself is locked. But the file lives at a URL like /wp-content/uploads/2026/04/confidential-report.pdf , and if anyone knows or guesses that URL, they can download it directly without ever seeing the password form.

The reason is structural. nginx (or any well-configured web server) serves static files – images, PDFs, videos – directly from disk without involving PHP. WordPress never sees the request, so WordPress has no opportunity to check whether the user has entered the post password. This is not a WordPress bug; it is the entire point of why static files are fast to serve. The tradeoff is that WordPress-level access control does not apply to them.

There are three real solutions.

Option 1: nginx X-Accel-Redirect (the fastest, most control)

Instead of exposing uploads directly, route them through PHP. PHP checks whatever access logic you want (post password cookie, user login, membership status), then hands the file back to nginx via an internal redirect. nginx serves it at full speed – the PHP check is the only extra cost.

Configure nginx to protect the real uploads directory and expose a public download path:

# The real uploads directory - only accessible internally
location /protected-uploads/ {
    internal;
    alias /var/www/site/wp-content/uploads/;
}

# Public downloads go through PHP
location ~ ^/download/(.+)$ {
    try_files $uri /wp-content/themes/your-theme/secure-download.php?file=$1;
}

Then the PHP handler (in your theme or a mu-plugin) checks whether the request is authorized and, if so, sets the X-Accel-Redirect header to the internal path:

<?php
// secure-download.php
require_once('/var/www/site/wp-load.php');

$file = $_GET['file'] ?? '';
$post_id = intval($_GET['post'] ?? 0);

// Your authorization check - adapt to your use case
if (post_password_required($post_id)) {
    status_header(403);
    exit('Access denied');
}

// Tell nginx to serve the file internally
header('X-Accel-Redirect: /protected-uploads/' . $file);
exit;

Links to files then point to /download/2026/04/confidential-report.pdf?post=123 instead of the raw uploads URL, and the PHP check runs on every download.

This is the cleanest and most performant approach, but it requires control over the nginx config and some PHP work. It is the right choice if you are routinely protecting media files as part of a paid-content or members-only setup.

Option 2: Move uploads outside the web root

If the files are highly sensitive and not many of them, move the protected files out of /wp-content/uploads/ entirely into a directory that the web server cannot serve at all, and write a small PHP handler that reads the file and streams it back after checking authentication. No X-Accel-Redirect needed, but every download goes through PHP top to bottom, so this does not scale to many concurrent downloads of large files.

Option 3: Use a plugin

Several plugins implement variants of the above. The well-maintained options as of 2026:

• Prevent Direct Access (Google Drive) – intercepts requests to files attached to protected posts and redirects unauthenticated visitors away. Has a free version; paid version adds features like preview-only links and integration with membership plugins.
• Download Monitor – originally for tracking downloads, now has robust access control including per-role/per-product restrictions. Good fit if you are gating downloadable files for a commercial product.
• WP File Manager (paid) – includes directory-level access control for /wp-content/uploads/ and custom directories.

The plugin route is faster to set up and works on hosts where you cannot edit nginx config. The downside is that it adds a PHP layer to every file request (even when the file is public), and the protection depends on the plugin staying installed and configured correctly – disabling the plugin exposes every file that was previously protected.

Important: Whichever option you pick, sensitive files should be named with something unguessable, not predictable titles. A URL like /wp-content/uploads/2026/04/q4-board-meeting-minutes.pdf is a direct invitation even with protection in place. Rename to /wp-content/uploads/2026/04/a7f3b2e1-4c9d.pdf to make URL guessing impractical, and rely on the access control for the actual policy.

Common mistakes#

• Password protecting a page and forgetting the cache. The cached version of the unlocked page gets served to everyone. Every cache layer needs to vary on the wp-postpass_* cookie.
• Basic auth with the REST API left open. You intended to protect the whole site but excluded /wp-json/ for the editor. Now /wp-json/wp/v2/users enumerates your usernames for anyone who asks, which feeds whatever brute force vector they try next. If you must expose REST, at least restrict the user endpoint.
• Basic auth without HTTPS. Credentials are base64-encoded, not encrypted. Any network path between the visitor and your server sees the password in effectively plain text. Always run basic auth behind a valid TLS certificate.
• Protecting a post password but not the media. The whole reason to pick this variant as a guide topic – most how-tos stop at the post-password setting and never mention that the attached PDF is still wide open.
• .htpasswd in the web root. If you create the file inside the document root ( /var/www/html/.htpasswd ), a misconfigured server can serve it over HTTP and leak every password hash. Always store it above the document root.
• Treating post passwords as authentication. The post-password cookie does not tie to a user account, is not logged, does not have session controls, and does not expire in any meaningful security sense. It is a “please do not read this unless you know the word” layer, not an access control system.
• Weak .htpasswd passwords. Basic auth credentials are the only thing between attackers and the site. Treat them like any other production password – 16+ characters, generated, stored in a password manager, rotated when team members leave.

How Hostney handles password protection#

Hostney includes HTTP Basic Authentication as a built-in feature of the control panel – there is no need to SSH into the server, edit nginx config, or manage .htpasswd files by hand. Under Security > Password Protection, you can add a protected area by picking the subdomain, choosing the path (default is / , which protects the whole site), and entering an email and password for the credentials. The control panel writes the .htpasswd file, updates the nginx config, and reloads it – the protection is live within seconds.

Password complexity is enforced server-side (12-128 characters, with uppercase, lowercase, number, and special character required), so “admin/admin” and similar convenience credentials are not possible. You can add multiple users per subdomain for team access, mark entries active or inactive without deleting them, and update the password later without recreating the entry. Every create/update/delete runs through the same audit log as the rest of the control panel, so you have a record of who added or changed protected paths.

For staging environments specifically, the common workflow is: create the staging subdomain, enable password protection at / , share the credentials with the client, and the site is immediately invisible to search engines and casual visitors. When the site is ready to launch, delete the protection entry and the subdomain becomes public. No config edits, no rewrites, no downtime.

Beyond the built-in basic auth feature, Hostney’s edge bot-detection layer treats authenticated requests differently from unauthenticated ones – once someone passes basic auth, they are not subjected to the same aggressive challenge sampling that anonymous traffic sees, which keeps staging environments responsive for the people who should be accessing them while still filtering the junk traffic that finds every URL on the internet within hours.

Summary#

There are three layers at which you can protect WordPress content: application (WordPress post passwords, membership plugins), web server (HTTP Basic Auth via nginx or Apache), and file system (X-Accel-Redirect or move-out-of-web-root for media files). The right method depends on what you are trying to stop: a single page shared with a client is a one-click application-layer task, a whole staging site is a web-server-layer job that needs to account for WP-Cron and the REST API, a specific directory is the same mechanism scoped down, and protecting media files requires explicit routing because WordPress does not see those requests by default. Do not conflate post passwords with real access control, do not leave the REST API open when locking down a staging site, and do not forget that the PDF attached to your password-protected post is still downloadable unless you protected the file too.