You've got a folder on your site that strangers shouldn't see. Maybe it's a half-finished redesign, a client preview, or a downloads area for paying members. Learning how to password protect a directory in cPanel takes about five minutes, and it puts a browser login box in front of that folder before a single page loads.
Quick Answer (as of September 2026): In cPanel, open Files > Directory Privacy, click Edit beside the folder, tick "Password protect this directory", give it a name and click Save. Then create at least one user. Every subfolder inherits the lock, and because Basic authentication sends passwords almost in the clear, only use it over HTTPS.
The clicks themselves are the easy part. The trouble shows up afterwards: WordPress dashboards that loop forever, staging sites whose SSL certificates suddenly refuse to renew, and protected folders that throw 500 errors after a server move. Our engineers resolve 20-30 client issues every day, and at a host like Hostaccent, those three problems come up again and again. This guide is built from those tickets, written so you can get the setup right the first time and fix it yourself when something breaks.
Below you'll find the exact steps, what cPanel quietly writes to your server, the safe way to lock wp-admin and staging sites, and a checklist of the mistakes we untangle most often. Our team has been hosting since 2016 (UK-incorporated 2018), so every tip here comes from live servers rather than a lab.
What cPanel Directory Privacy Actually Does
cPanel Directory Privacy puts HTTP Basic authentication in front of a folder, so the web server asks for a username and password before it serves anything inside. It doesn't encrypt your files, and it doesn't hide them from FTP, SSH or File Manager. It only controls who can open that folder in a browser.
When you tick the box, cPanel writes two things behind the scenes:
- A few lines in an .htaccess file inside the folder you chose:
AuthType Basic, anAuthName(the label you typed), anAuthUserFilepath andRequire valid-user. - A password file stored outside your web root, at a path like
/home/username/.htpasswds/public_html/private/passwd. It holds each username next to a hashed password, never the plain text.
Because the rules live in .htaccess, the feature depends on Apache (or a server that reads the same files). The Apache authentication how-to documents exactly the directives cPanel generates, which is useful when you need to troubleshoot by hand. On stacks where Nginx sits in front as a reverse proxy and passes requests to Apache, the .htaccess rules still apply. On a pure Nginx server they're ignored completely, and the folder stays wide open no matter what the panel says.
A cPanel password-protected directory uses HTTP Basic authentication: the browser shows a login box, the server checks the username against a hashed password file stored outside public_html, and every subfolder inherits the protection automatically. As of 2026, it takes about 5 minutes to set up, costs nothing extra on cPanel hosting, and needs HTTPS to be safe.
Is a password-protected folder actually secure?
Honestly, it's a good lock for a garden gate, not a bank vault. MDN's guide to HTTP authentication notes that the Basic scheme only encodes the username and password in Base64. Base64 isn't encryption, so over plain HTTP anyone on the same Wi-Fi network could read the credentials. Over HTTPS with a valid SSL certificate, the whole exchange is encrypted and that risk mostly disappears.
Two other limits are worth knowing. Browsers don't really "log out" of Basic auth; they cache your credentials until the browser closes. There's also no built-in lockout after failed guesses. That job belongs to the server firewall. On servers running CSF/LFD, like ours, repeated failed logins against a protected folder can trigger a temporary IP block.
So use it for staging copies, client previews, private downloads and as an extra wall around admin areas. Don't make it the only thing guarding payment data or customer records.
How to Password Protect a Directory in cPanel, Step by Step
You enable protection on the folder first, then add the users who are allowed in. Skip the second half and the folder locks out everyone, including you.
Before you start
- Your cPanel login. On Hostaccent's shared hosting, Directory Privacy sits in the Files group of the control panel. Some older cPanel themes call it "Password Protect Directories".
- The folder's location. Your main site usually lives in
public_html. Addon domains and subdomains use whatever document root you picked when you created them. - A working SSL certificate on the domain, for the reasons covered above.
- A copy of any existing .htaccess file in that folder. WordPress and caching plugins write rules there, and it's good practice to have backups before any edit.
Step 1: Open Directory Privacy
Log in to cPanel and click Directory Privacy in the Files section. If you can't spot it, type "privacy" into the search bar at the top of the dashboard.
Step 2: Pick the folder
You'll see a list of folders starting at your home directory. Click a folder's icon to open it, and click its name or Edit to select it. The Private column reads "No" for anything that isn't protected yet. Choose the lowest folder that covers what you want to hide. Protecting public_html locks your entire website.
Step 3: Turn on protection
Tick Password protect this directory, type a label in Enter a name for the protected directory, and click Save. Visitors see that label inside the login prompt, so write something friendly like "Client Preview" rather than the real folder path.
Step 4: Create an authorised user
Click Go Back, scroll to Create User, enter a username, then type the password twice. Use the Password Generator for something long and random, ideally 16+ characters. Click Save. Create one login per person so you can remove someone later without resetting everybody else.
Step 5: Test it with the Three-URL Lock Check
After every change, our team runs a quick routine we call the Three-URL Lock Check:
- Open the protected folder in a private browser window. You should see the login prompt, and a wrong password should give a 401 response.
- Open a file two levels deeper, such as an image or PDF. It should prompt too, which proves inheritance works.
- Open a page outside the folder, such as your homepage. It should load with no prompt at all.
If URL 3 asks for a password, you've protected a parent folder by mistake (nine times out of ten, that's public_html). Private windows matter because your normal browser caches credentials and can hide a problem.
Pro Tip: Want to htpasswd protect a folder from the command line instead of clicking through the panel? cPanel exposes the same feature through its UAPI documentation, so two commands do the whole job. This is the version worth scripting if you manage dozens of client folders. Clear your shell history afterwards, because the password is typed in plain text.
bashuapi DirectoryPrivacy configure_directory_protection dir='/home/username/public_html/private' enabled=1 authname='Private Area' uapi DirectoryPrivacy add_user dir='/home/username/public_html/private' user='client1' password='a-long-random-password'
Removing protection later
Go back to Directory Privacy, select the folder, untick the box and click Save. The folder becomes public straight away. cPanel keeps the user list in case you switch protection back on, so delete those users once a project is finished. Old credentials sitting on a server are a small risk you don't need.
The migration gotcha nobody mentions
Across the 4,000+ sites Hostaccent has migrated since 2016, the step people most often get wrong with protected folders is copying only public_html. The .htaccess file travels with the site, but the password file lives in /home/username/.htpasswds, outside the web root. On the new server, Apache can't open the file named in AuthUserFile, so the folder returns a 500 Internal Server Error instead of a login box.
It gets worse if your cPanel username changed during the move, because the path inside AuthUserFile now points to a home directory that doesn't exist. The fix is simple: copy the .htpasswds folder as well, or untick and re-tick protection in cPanel on the new server and add the users again.
Still blocked by this control-panel issue?
Send the exact error and the action that triggers it. We can diagnose account, DNS, SSL, mail, and server-side causes without requiring a hosting transfer.
How to Password Protect wp-admin in cPanel Without a Login Loop
You can lock the wp-admin folder with Directory Privacy, but you also need to exempt admin-ajax.php and fix the 401 error page. Skip either step and parts of your site break, or the login prompt loops endlessly.
WordPress keeps admin-ajax.php inside wp-admin, and plenty of front-end features call it: contact forms, WooCommerce cart fragments, live search and cookie banners. Lock the folder without an exception and those features quietly fail for every visitor, because their browsers get a 401 instead of a response. The official WordPress hardening guide is worth reading alongside this section.
1. Protect the folder. Follow the steps above and select public_html/wp-admin (or the wp-admin folder inside wherever WordPress is installed).
2. Allow admin-ajax.php. In File Manager, enable "Show Hidden Files", open wp-admin/.htaccess, and add this below the lines cPanel wrote:
apache<Files "admin-ajax.php"> Require all granted </Files>
3. Stop the loop. Open the .htaccess in your site root and add this line at the very top:
apacheErrorDocument 401 default
Why does this matter? When Apache challenges a browser for credentials, it looks for a 401 error page. If that page doesn't exist, WordPress's rewrite rules grab the request and serve their own response, so the browser never shows a proper prompt and you bounce around. This single line tells Apache to use its built-in page instead.
4. Lock wp-login.php too. That file sits in the site root, not in wp-admin, so bots hitting it bypass your new lock. Add this to the root .htaccess, copying the exact AuthUserFile path from wp-admin/.htaccess:
apache<Files "wp-login.php"> AuthType Basic AuthName "Admin Area" AuthUserFile "/home/username/.htpasswds/public_html/wp-admin/passwd" Require valid-user </Files>
Locking wp-admin in cPanel takes a few edits: enable Directory Privacy on the folder, allow admin-ajax.php with a 3-line Files block, and add ErrorDocument 401 default to the root .htaccess so WordPress stops intercepting the prompt. Protecting wp-login.php with the same password file then closes the second door that bots use.
You'll now see two logins: the browser's Basic auth box first, then the normal WordPress screen. That's expected. If you also use a security plugin that renames the login URL, pick one approach, because stacking both is a common source of confusing lockouts.
Insider Insight: The biggest benefit isn't secrecy, it's server load. A brute-force hit on wp-login.php normally starts PHP and queries MariaDB. With Basic auth in front, Apache rejects the request before PHP ever runs, so a bot hammering your login costs a fraction of the CPU and memory it used to. Even on NVMe SSD hosting, fewer wasted PHP workers means better performance for real visitors.
How to Protect a Staging Site with a Password (and Keep SSL Working)
Lock the staging site's whole document root with Directory Privacy, then leave one small gap for SSL validation so the certificate keeps renewing. A password is the most reliable way to keep a staging copy out of Google.
Many people reach for robots.txt instead, but a disallow rule is only a polite request. It doesn't stop Google indexing a URL that someone linked to. A 401 response is a hard stop: crawlers can't fetch the page, so your duplicate content never competes with the live site.
Start by finding the right folder. A staging subdomain usually has its own document root, such as /home/username/staging.example.com, or it sits in a subfolder like public_html/staging. Protect that folder only. If you pick public_html by accident, your live site goes behind the login as well.
Next comes the gap most guides miss. Free certificates from AutoSSL or Let's Encrypt prove you control the domain by fetching a file from the /.well-known/ path over HTTP, a method described in Let's Encrypt's challenge types documentation. If Basic auth sits in front of that path, validation can hit a 401 and the renewal quietly fails. Let's Encrypt certificates last 90 days, so you often don't notice until the browser warning appears. Add this to the staging folder's .htaccess:
apache<If "%{REQUEST_URI} =~ m#^/\.well-known/#"> Require all granted </If>
Test it by opening https://staging.example.com/.well-known/ in a private window. A 404 or 403 is fine. A login prompt means the exemption isn't working yet.
A password-protected staging site returns HTTP 401 to every visitor and crawler, which keeps it out of Google far more reliably than robots.txt. As of 2026, the one exception you need is the /.well-known/ path, because free SSL certificates are validated over HTTP and lapse after 90 days if renewal is blocked.
If the staging hostname runs through Cloudflare in Full (strict) mode, an expired origin certificate shows up as a 526 error rather than a browser warning, and you can fix Cloudflare Error 526 with that guide. Also switch off any "Cache Everything" rule on the staging hostname, so a cached page can never be handed to someone who hasn't logged in.
One more WordPress detail: WP-Cron works by having the site call its own wp-cron.php over HTTP. Behind Basic auth that loopback gets a 401, so scheduled tasks stall and Site Health reports a failed loopback. On staging this rarely matters. If you ever protect a live WordPress site, add define('DISABLE_WP_CRON', true); to wp-config.php and create a real cron job in cPanel that runs wp-cron.php every 5 minutes.
Common Mistakes After You Lock a Folder (and the Errors They Cause)
Most problems after you password protect a folder come from five mistakes: protecting the wrong level, skipping HTTPS, confusing 401 with 403, forgetting monitors and webhooks, and letting plugins rewrite your rules. In our experience, the first one causes the most panic.
Locking public_html by accident. Your whole site disappears behind a login. Uptime monitors report the site as down, and payment-gateway webhooks start receiving 401 responses, so orders can get stuck in "pending". If you truly need a private live site, exempt the webhook URLs with the same <Files> or <If> approach used above.
Running it over plain HTTP. Credentials cross the network as readable Base64. Install SSL first, then force HTTPS before you share the login with anyone.
Reading 401 and 403 as the same thing. A 401 means the server wants credentials, which is normal for a locked folder. A 403 means the server refuses access no matter who you are, usually because of file permissions or a deny rule. Our guide to the 403 Forbidden Error: How to Fix It covers that side. A 404 right after login usually points to the WordPress rewrite issue fixed earlier, and our breakdown of every cause of a 404 Not Found error helps if it doesn't.
After you password protect a folder, a 401 response is normal and means the server wants credentials, while a 403 means access is refused outright. A 500 error usually means the AuthUserFile path points to a password file that doesn't exist, and checking cPanel's error log for that one line solves most cases in under 5 minutes.
Expecting the same password to work in FTP. Directory Privacy users are web-only. They can't log in to FTP, SSH or cPanel. If your FTP client rejects a login, that's a completely separate account, and you can troubleshoot it with the FTP 530 login authentication failed walkthrough.
Letting a plugin rewrite .htaccess. Caching and security plugins regenerate .htaccess and can wipe your custom <Files> blocks. Keep your lines outside the # BEGIN WordPress and # END WordPress markers, and re-check the file after plugin updates. Make sure your backups include the .htpasswds folder too, or a restore brings back the rules without the passwords.
Pro Tip: Open cPanel's error log (Metrics > Errors) right after you lock a folder. A line saying the password file couldn't be opened means the AuthUserFile path is wrong, and spotting it there can save you 20 minutes of guessing.
Your Next Step: A Host Where the Lock Just Works
Now that you know how to password protect a directory in cPanel, and that the real work hides in the exceptions (admin-ajax.php, /.well-known/, the 401 page), you have a choice. You can wire up those rules yourself, or run your sites where engineers who handle these tickets daily are a message away, 24/7. Economy: $1.99/mo includes cPanel, NVMe SSD storage, free SSL and a 30-day money-back guarantee, and it renews at the same $1.99/mo. One honest caveat: if you're juggling several client sites plus staging copies, Standard at $4.58/mo gives you more headroom. When you're ready, start on the Economy plan at $1.99/mo and let Hostaccent handle the server side.
Frequently Asked Questions About Password Protecting cPanel Directories
How to password protect a directory in cPanel if Directory Privacy is missing?
Search the cPanel dashboard for "privacy" first, because older themes label the tool Password Protect Directories. If it's genuinely missing, your host has probably disabled that feature for your account, so ask support to switch it on. As a fallback, you can create the password file yourself with the htpasswd utility over SSH, write the .htaccess rules by hand, and point AuthUserFile at a path outside public_html so nobody can download it.
Does protecting a folder also protect its subfolders?
Yes. Directory Privacy rules sit in the folder's .htaccess file, and Apache applies them to everything beneath it: subfolders, images, PDFs and scripts. That's why locking public_html locks your entire website. If one subfolder needs to stay public, add an .htaccess file inside it containing Require all granted, which overrides the parent rule for that subfolder only. Test the result in a private browser window afterwards, since your normal browser caches the login.
Why does my browser keep asking for the password?
A repeating prompt almost always means the credentials don't match what's stored in the password file. Usernames are case-sensitive, and a pasted password often carries a hidden trailing space. On WordPress, a loop can also come from the missing 401 error page, which ErrorDocument 401 default in the root .htaccess fixes. If neither helps, reset that user's password in Directory Privacy and try again in a private window with a clean cache.
Will a password-protected directory hurt my SEO?
Only if you lock pages you want to rank. Google can't crawl anything behind a 401 response, so protected URLs drop out of search results over time, which is exactly what you want for staging copies, client previews and private downloads. The rest of your site isn't affected, and there's no ranking penalty for having a locked area. Just avoid linking heavily from public pages into the protected folder, or crawlers waste time hitting login prompts.
Is Directory Privacy enough to stop WordPress brute-force attacks?
It's a strong first layer, but it isn't the whole answer. According to Hostaccent's support-queue data for 2026, brute-force and malware problems make up about 25% of monthly support tickets, so we treat login protection in layers. Basic auth stops bots before PHP runs, a firewall such as CSF/LFD or a web application firewall blocks repeat offenders, and strong WordPress passwords with two-factor authentication protect the account itself if anything slips through.
How do I remove password protection from a folder?
Open Directory Privacy, select the folder, untick Password protect this directory and click Save. The folder becomes public straight away, although your browser may keep showing cached pages until you refresh. cPanel keeps the authorised users in case you re-enable protection, so delete them once the project wraps up. If you added custom Files or If blocks by hand, remove those lines from the .htaccess file as well, since cPanel only cleans up the rules it wrote.
Discussion
Have a question or tip about this topic? Share it below — your comment will appear after review.