How to Password Protect a Site Using Htaccess

When to Use Htaccess Password Protection

Htaccess password protection is a good fit for a narrow set of use cases:

• Staging or pre-launch sites — keep the unfinished work out of Google’s index and away from casual visitors until launch.
• Admin or internal tools — gate /wp-admin, a custom dashboard, or a private directory of scripts.
• Client previews and demos — share a single username and password with a client instead of rolling per-user accounts.
• Small private file areas — a handful of PDFs or downloads you want behind a gate without building an account system.

It’s not the right tool when you need per-user accounts, audit logging, password reset flows, or anything resembling a real authentication system. For those, move up to an application-level login, SSO, or a zero-trust service like Cloudflare Access. More on alternatives at the end of this guide.

Prerequisites

Before you start, confirm three things:

1. Your server runs Apache (not Nginx). Htaccess is an Apache-specific feature. On Nginx, the same idea works but the configuration lives in the main server config, not a drop-in file — covered below.
2. Your site runs on HTTPS. HTTP Basic Authentication sends the username and password Base64-encoded in every request. Base64 is not encryption — anyone on the same network can read it. TLS/HTTPS is what actually protects the credentials in transit. If your site isn’t on HTTPS yet, fix that first.
3. AllowOverride is enabled. On most shared hosts (cPanel, Plesk, DreamHost) it already is. On a VPS you control, check your Apache config (httpd.conf or the site’s vhost) for AllowOverride AuthConfig or AllowOverride All. Without it, .htaccess auth directives are silently ignored.

Step 1: Create the .htpasswd File (The Right Way)

The .htpasswd file stores usernames paired with hashed passwords. Never put plaintext passwords in this file — Apache won’t accept them, and even if it did, a leaked file would expose every credential.

The correct tool is htpasswd, a small utility bundled with Apache (official docs). Most Linux hosts have it pre-installed. If not, install apache2-utils (Debian/Ubuntu) or httpd-tools (RHEL/CentOS/Rocky).

To create the file and add your first user, run:

htpasswd -cB /path/to/.htpasswd yourusername

Flags:

• -c — create a new file. Only use this on the first user; it overwrites an existing file.
• -B — use bcrypt for the hash. Bcrypt is the only option in htpasswd that’s still considered strong in 2026; MD5 and SHA-1 should not be used for new files.

You’ll be prompted for the password. Don’t pipe it from the command line unless you’re careful about shell history.

To add more users later, drop the -c flag:

htpasswd -B /path/to/.htpasswd anotheruser

If you can’t run htpasswd — shared hosting with no shell access, for example — use a trusted htpasswd generator locally (run offline, not in a web form). Then upload the resulting file via FTP/SFTP. Never paste your real password into a random online generator.

Step 2: Place the .htpasswd File Outside the Web Root

Put the .htpasswd file in a directory that isn’t served by your web server. A common pattern:

• Web root: /home/username/public_html/
• Htpasswd file: /home/username/.htpasswd (one level up)

Putting it outside the web root means the file is unreachable over HTTP, so even a misconfigured server can’t accidentally serve its contents. If you have to put it inside the web root for any reason, add a matching <Files> block in .htaccess to explicitly deny access:

<Files ".htpasswd">
Require all denied
</Files>

Step 3: Create or Edit the .htaccess File

The .htaccess file — note the leading dot — goes in the directory you want to protect. On most WordPress and cPanel setups, there’s already an .htaccess in public_html/. Don’t overwrite it; open and edit it.

If you need to see hidden files (anything starting with a dot) in your file manager or FTP client, toggle “Show hidden files” — most clients hide them by default.

Add the following block at the top of the file:

AuthType Basic
AuthName "Restricted Area"
AuthUserFile /home/username/.htpasswd
Require valid-user

Four directives, each doing one thing:

• AuthType Basic — use HTTP Basic Authentication.
• AuthName — the text the browser shows in the login prompt (e.g., “Staging Site” or “Admin Access”). Put it in quotes.
• AuthUserFile — the absolute server path to your .htpasswd file. This is the line most often miswritten — double-check it.
• Require valid-user — anyone in the htpasswd file can sign in. To restrict to specific users, use Require user alice bob instead.

Save the file and upload it. The directory it sits in (and everything below it) is now protected.

Step 4: Test It

Open the protected URL in an incognito/private browsing window. You should get a browser-native login prompt. Three outcomes:

• Login prompt appears, correct credentials work — done, you’re protected.
• Login prompt appears, correct credentials rejected — check the .htpasswd file. Common causes: wrong hash format (re-run htpasswd -B), wrong AuthUserFile path in .htaccess, or stale browser auth cache (close and reopen the browser).
• No prompt at all, page loads normally — .htaccess isn’t being read. Either AllowOverride is disabled (see Prerequisites) or Apache isn’t loaded for that directory. Ask your host.

Common Mistakes

• Plaintext passwords in .htpasswd. Won’t work and is insecure. Use htpasswd -B.
• Relative path in AuthUserFile. It must be the absolute server path, not a relative path or URL.
• Overwriting an existing .htaccess. Edit it instead of replacing; WordPress and caching plugins rely on directives already in the file.
• Forgetting the dot. The files are .htaccess and .htpasswd, with a leading period. “Htaccess.txt” will not be recognized by Apache.
• Running without HTTPS. Basic Auth over plain HTTP sends credentials in clear. Get a free Let’s Encrypt certificate before you protect anything real.
• Weak passwords. Even with bcrypt, a password of “letmein” folds to a dictionary attack in minutes. Use a password manager to generate and store something long and random.

On Nginx Instead

Nginx doesn’t read .htaccess files at all. To get the same effect, you still generate a file with htpasswd -B, but the auth directives live in your Nginx server or location block (Nginx docs):

location /protected {
auth_basic "Restricted Area";
auth_basic_user_file /home/username/.htpasswd;
}

Reload Nginx with sudo nginx -s reload after editing. Unlike Apache, changes require root and a config reload — there’s no drop-in file.

WordPress-Specific Alternatives

If your site is on WordPress and you want a friendlier option than hand-editing config files, a plugin is often easier:

• Password Protected — locks the entire site behind a single password. 300,000+ active installs. Good for staging sites or “coming soon” pages.
• SeedProd or WP Maintenance Mode — replace the front end with a branded holding page and require a password to bypass.
• Built-in post/page password — WordPress has native per-page password protection in the Publish panel. Fine for a single protected page; not a site-wide lock.

Plugins authenticate at the application layer (PHP), not the server. That’s slightly easier to manage but slightly weaker than htaccess — a plugin misconfiguration or vulnerability can leak the content, where htaccess stops requests before PHP even runs.

Modern Alternative: Cloudflare Access

For teams, the cleanest modern option is identity-based access via a zero-trust service like Cloudflare Access. Instead of a shared password, each user signs in with Google, Microsoft, GitHub, or your company’s SSO. You get per-user access, audit logs, conditional policies (require a specific IP range, or a device with current OS patches), and an easy revoke.

Cloudflare Access is free for up to 50 users and sits in front of any site proxied through Cloudflare. For any staging or internal tool that more than two people need access to, it’s worth five minutes to set up instead of managing a shared htpasswd.

A Note on Crawlers and SEO

A password-protected page returns a 401 status to Googlebot and other crawlers, which keeps it out of search results — usually what you want for staging and private content. But the inverse matters too: if you run your own crawl (for a content audit or sitemap) against a password-protected site, you’ll need to supply the credentials. See our guide on crawling private pages of password-protected websites for how to do that with DYNO Mapper or any HTTP Basic-aware crawler.

Frequently Asked Questions

Is htaccess password protection secure?

Over HTTPS with bcrypt-hashed passwords and a strong password, yes — secure enough for staging sites, admin gates, and small private areas. Over plain HTTP, or with a weak password, no. It’s HTTP Basic Authentication underneath, which means the password travels on every request: TLS is doing the real work of keeping it private in transit.

What’s the difference between .htaccess and .htpasswd?

The .htaccess file is Apache’s per-directory configuration — it tells the server how to treat requests to that directory. The .htpasswd file stores the usernames and hashed passwords used for authentication. .htaccess points to .htpasswd; you need both.

Can I password protect a single page with htaccess?

Yes, using a <Files> block inside your .htaccess:

<Files "secret.html">
AuthType Basic
AuthName "Restricted"
AuthUserFile /home/username/.htpasswd
Require valid-user
</Files>

For more than one or two files, put them in a subdirectory and protect the directory instead — much cleaner.

Will password protection hurt my SEO?

Not for staging or private content — in fact, it’s better than a public-but-noindex page, because a 401 response keeps the URL out of Google’s index entirely. Don’t password-protect pages you want indexed; Google can’t read them.

Bottom Line

Htaccess password protection is a short, durable pattern: one .htpasswd file with bcrypt-hashed credentials, one .htaccess block with four directives, and HTTPS in front of the whole thing. Run it when you need a lightweight gate on a small site or directory. Reach for Cloudflare Access or a WordPress plugin when you outgrow shared passwords. And whatever you do, don’t skip the HTTPS — password protection without TLS is not protection.