Password-Protect a Folder in cPanel: Hide Staging From the Public

You password-protect a folder in cPanel with the Directory Privacy tool under Files. Pick the folder, tick "Password protect this directory", save, then create a username and password for anyone who needs in. Do it only after the domain or subdomain has a working HTTPS certificate, because the login travels with every request.

Here is a made-up scenario that is far too common in real life. A small bakery hires a freelancer to rebuild its site, and the freelancer puts the half-built homepage on staging.example.com with placeholder prices and a "lorem ipsum" About page. Two weeks before launch, a customer searches the bakery's name, lands on the staging copy, and phones to ask why a cake now costs 1 dollar.

Nothing was hacked. The folder was simply open to anyone with the address, and search engines found the address. By the end of this guide you will be able to lock a staging copy, a subdomain, a private download folder or an admin-tool folder behind a login, prove the lock works from the command line, and undo it cleanly on launch day.

What Directory Privacy actually does

Directory Privacy puts a login prompt in front of one folder on your website. When someone opens a page inside that folder in a browser, the server asks for a username and password before it sends anything back.

Think of your hosting account as a house. Directory Privacy fits a lock on one room door. The rest of the house stays open to visitors, and only that room needs a key.

Under the hood, cPanel's documentation says the tool works by changing the .htaccess and .htpasswd configuration for that folder. .htaccess is a small settings file the web server reads for each folder, and .htpasswd is the file that stores the allowed usernames and their passwords.

The lock also covers every room inside that room. cPanel's page says a protected directory's subdirectories inherit their parent directory's password protection, so locking staging also locks staging/wp-content and everything below it.

Now the part people miss. The lock only guards the website door. cPanel states plainly that Directory Privacy does not protect directories that people reach over FTP, SFTP, Web Disk or other services, and it does not affect local file access on the server.

Why this matters: anyone with your FTP or cPanel login can still read and change the files. Directory Privacy keeps strangers on the web out. It does nothing about weak FTP passwords or a shared cPanel login, and it does not encrypt anything.

It is also not a fix for a live public WordPress site. If your real shop or blog is public, a login prompt over it just locks out your customers. Use this tool for things that should never be public in the first place.

Good fits for Directory Privacy:

• A staging copy of a site, such as the document root of staging.example.com
• A subdomain you use for client previews
• A private download folder with files for a handful of people
• A folder holding an admin or database tool that only you should open

Before you start

Five minutes of preparation saves an hour of confusion later. Gather these first:

• Your cPanel login, and confirmation that you can see the Files section
• A valid HTTPS certificate on the domain or subdomain you are about to protect
• The exact folder name you want to lock, for example the folder behind staging.example.com
• A fresh backup of that folder, in case you need to undo something
• A note of the username you will create, such as staging-reviewer, and where you will store its password
• A private or incognito browser window for testing, so your normal browser's saved logins do not fool you

If you do not have a recent backup, follow our guide to backing up your website in cPanel with an offsite copy and a test restore before you change anything.

Step 1: Check HTTPS first

This step comes first for a reason, and it is the one most guides skip.

Directory Privacy uses what is called HTTP Basic authentication. That is the plain login box the browser draws itself. RFC 7617, the standard that defines it, says the browser joins the username, a colon and the password, then Base64-encodes the result and sends it in a header with each request.

Base64 is a way of writing data in safe characters. It is not encryption. Anyone who sees the header can turn it back into the password in a second. The RFC's own example uses the username Aladdin and the password open sesame:

Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==

RFC 7617 says in its security section that Basic is not a secure method of user authentication, and that it should not be used to protect sensitive or valuable information without enhancements such as HTTPS. The Apache documentation agrees: Basic authentication sends the password from the client to the server unencrypted, so it should not be used for highly sensitive data unless it is paired with mod_ssl, which is the part of Apache that provides HTTPS.

So, before you lock anything:

1. Open https://staging.example.com in your browser and confirm the padlock appears with no warning.
2. Open http://staging.example.com and confirm it redirects to the https:// address.
3. If either check fails, fix HTTPS first using our guide to redirecting HTTP to HTTPS.

Step 2: Turn on password protection

At the time of writing (10 November 2026), cPanel's documentation says the Directory Privacy page is valid for cPanel version 88 through the latest version. Your host's theme may look a little different, but the labels below come straight from that page.

Open Directory Privacy

Log in to cPanel and go to cPanel > Files > Directory Privacy. You should see a list of folders with an "Actions" column on the right.

If you cannot find it, do not hunt for long. Your host can switch this tool on or off in WHM > Home > Packages > Feature Manager, so a missing menu usually means the host has hidden it. Ask them to enable it.

Select the folder

Click the name of a folder to open it. To reach a subfolder, click the parent first, then click the subfolder inside it.

Keep clicking until the folder you want to protect is in the list, for example the folder that serves staging.example.com.

Click Edit

In the "Actions" column next to your folder, click Edit. You should now see the security settings for that one folder.

Tick the box and name it

Tick the checkbox labelled "Password protect this directory".

Then type a label into the box labelled "Enter a name for the protected directory". Something like Staging preview works well.

Quick tip: this name is only a label. cPanel's page says it functions as a label in the folder's .htaccess file and should not be confused with the folder's actual name. Keep it plain and avoid anything that hints at what is inside.

Save, then go back

Click Save. This click is the one that turns protection on, so do not leave the page without it.

You should see a confirmation message. Click Go Back to return to the folder's settings, where you will add a user next.

Step 3: Create an authorized user

The lock is on, but nobody has a key yet. cPanel's page says that after you enable protection you must create a user that can access the directory.

Enter a username

In the user section of the same screen, type a name into the "Username" text box. For our example, use staging-reviewer.

Pick a name per person or per role if several people need access. That way you can remove one person later without changing everyone's password.

Set a password

Type the password, then type it again in the confirm box.

cPanel shows a strength meter that scores the password from 0 to 100, where 0 is weak and 100 is very secure. Aim near the top of that range.

Quick tip: click Password Generator to have cPanel create a strong password for you. Copy it into your password manager before you move on, because you will need it in a minute.

Save the user, then go back

Click Save. You should see a confirmation, then click Go Back.

Check the Authorized Users list

Your new user now appears in the "Authorized Users" menu for that folder. This list is your record of who has a key.

To change someone's password later, enter their username and the new password in the same form and click Save.

Remove a user you no longer need

When a reviewer finishes, select them in the "Authorized Users" menu, click Delete User, confirm when asked, then click Go Back. Do this the day the job ends, not "sometime later".

Step 4: Keep the folder out of search

The made-up bakery problem began with search, so let's close that loop properly.

Many people try to hide staging with a robots.txt rule. That file asks well-behaved crawlers not to fetch certain paths. It sounds right, but Google's documentation explains why it backfires.

Google says it does not support a noindex rule placed in robots.txt. It also says that if robots.txt blocks a page, the crawler will never see the page's own noindex rule, and the page can still appear in search results, for example if other pages link to it.

A noindex rule, by contrast, is an instruction on the page itself, as a robots meta tag or an X-Robots-Tag response header. It tells Google not to show that page in results. Google notes the page can still be linked to and visited, it just will not appear in Search.

Password protection goes further. Google's guide on controlling what you share says that if you have confidential or private content, you need to password protect it so only authorized users can access it, and that this also keeps the content out of Google Search, or eventually removes it if it already appears.

Why this matters: noindex asks politely and only works if the crawler can read the page. A password stops the crawler and every stranger at the door. For staging and private folders, the password is the stronger control.

You can still keep a noindex rule on your staging copy as a second layer. Just do not rely on it alone. If you manage crawler rules for the main site, our guide to robots.txt rules for GPTBot, ClaudeBot and Google-Extended covers how those rules really behave.

How to check it worked

Never trust a checkbox. Test the lock the way a stranger would meet it.

Test 1: ask for headers only

From your own computer, run curl -I against the protected address. The curl manual describes -I (or --head) as fetching the headers only.

curl -I https://staging.example.com/

You want to see a 401 status and a WWW-Authenticate header. RFC 9110 defines 401 as a request that lacks valid authentication credentials for the target resource, and says a server sending a 401 MUST include a WWW-Authenticate header. The output should look roughly like this:

HTTP/2 401
www-authenticate: Basic realm="..."

The text after realm will vary from server to server. What matters is the 401 and the presence of the header.

If you get 200 instead, the lock is not active. Jump to the troubleshooting section.

Test 2: try the real login from curl

Now check that the right user gets in. Give curl the username only, and let it ask for the password.

curl -I -u staging-reviewer https://staging.example.com/

The curl manual says that if you give only the username with -u, curl prompts for the password. It also warns that a password typed on the command line can briefly be visible to other users on the same system, which is why the prompt is the safer habit. A correct password should give you a normal status such as 200 or a redirect.

Test 3: a private browser window

Open a private window and visit https://staging.example.com. Your browser should draw its own login box before showing any page.

Test 4: a wrong password

Enter staging-reviewer with a deliberately wrong password. The prompt should come back, or you should see an "Unauthorized" page. If a wrong password lets you in, something is badly wrong, so stop and check the user list.

Test 5: a subfolder

Open a deeper address, such as https://staging.example.com/wp-content/uploads/, in a fresh private window. It should ask for the login too, since subfolders inherit the parent's protection. Run curl -I on a direct file URL inside the folder as well, because files are what leak most often.

Troubleshooting

No login prompt appears

Symptom: the folder opens as normal and curl -I shows 200.

Likely cause: the Save click after ticking "Password protect this directory" was missed, or you protected a different folder from the one the site actually serves.

Fix: go back to Files > Directory Privacy, open the folder, click Edit and confirm the box is ticked, then click Save.

You cannot create a user

Symptom: protection is on, but saving a user fails.

Likely cause: a permissions problem on the folder.

Fix: cPanel's own page says that if you cannot create a user, change the directory's permissions to 0700 using cPanel > Home > Files > File Manager. If you are not sure what that will change for your site, ask your host before you do it.

The browser lets you straight in

Symptom: you tested in your normal browser and it never asked for a password.

Likely cause: as general caution, browsers usually remember a Basic authentication login for the rest of the session, so your earlier login is being reused.

Fix: close every private window, open a brand new one, and test again. The curl -I test without -u is the honest answer here, because curl does not reuse your browser's session and sends no login unless you supply one.

A 500 error after a hand edit

Symptom: the whole folder, or even the whole site, shows "Internal Server Error" after someone edited .htaccess by hand.

Likely cause: as general caution rather than something on the cPanel page, a typo in an .htaccess rule is a common cause of this error.

Fix: restore .htaccess from your backup, or undo the last hand edit in File Manager. Then make protection changes through Directory Privacy instead of editing the file yourself.

Directory Privacy is missing from cPanel

Symptom: there is no Directory Privacy icon under Files.

Likely cause: the host has turned the feature off in WHM > Home > Packages > Feature Manager for your hosting plan.

Fix: open a ticket and ask the host to enable Directory Privacy for your account. Do not assume every host offers it on every plan.

Background tasks break on a WordPress staging copy

Symptom: the staging site loads, but some features that call back to the site itself fail.

Likely cause: as general caution rather than something on the cPanel page, some WordPress features send requests to their own site in the background, and those requests do not know your staging password.

Fix: accept a few odd behaviours on staging, or test those features on a copy without protection that has noindex set and a hard-to-guess address. This is another reason not to put a login prompt over a live public site.

Pro tips and when to ask the host or a developer

Basic authentication is a good front door for staging. It is the wrong tool for anything truly sensitive, such as customer records, financial exports or medical files.

For that kind of data, ask a developer for a proper application login with per-user accounts, rate limits and an audit trail. Or ask your host about putting the tool on a private network or behind a VPN so it is never exposed to the public internet at all.

Two more habits help a lot:

• Give each reviewer their own username, and delete it with Delete User the day their work ends.
• Tighten the other doors too. Directory Privacy does nothing for FTP or SFTP, so use strong passwords there, or move to keys with our guide to SSH key login on cPanel hosting.

When launch day comes, remove the lock cleanly. Open Files > Directory Privacy, click Edit next to the folder, untick "Password protect this directory", and click Save. cPanel's page describes exactly this as the way to remove protection. Then delete the old users, run curl -I once more, and confirm you now get 200 on the public address.

If staging was a separate copy, it is usually better to leave it protected after launch than to open it up. An old staging copy that is still public is how the bakery story happens a second time.

The one message worth forwarding

If you would rather hand this to your developer or your host, send this:

Hi, please password-protect the folder that serves staging.example.com using cPanel Directory Privacy. First confirm HTTPS works on that subdomain and that http redirects to https. Then tick "Password protect this directory", save, and create one user named staging-reviewer with a generated password, shared with me through our password manager. Please confirm with curl -I that the address returns 401 with a WWW-Authenticate header, and that a subfolder does the same. Do not apply this to the live public site. Thanks.

A password on the folder keeps strangers and search engines out of staging, but only after HTTPS is working and only for visitors who come in through the website.