Websites
Password-Protecting a Site
Password protection puts a browser sign-in prompt in front of your whole site or a specific path, which is the simplest way to keep a pre-launch site, a staging copy, or an admin area private. This guide covers setting it up, managing users, verifying it works, and removing it again.
Where Password Protection Lives in KPanel
- Sign in to KPanel.
- Click Websites in the left sidebar, then click the site.
- In the site's tab strip, open Advanced, then Password protection.
The direct address is /websites/<site-id>/password-protect.
How It Works
Protection is applied by the web server using HTTP Basic Auth, before your application runs. A visitor to a protected URL gets the browser's own sign-in dialog and cannot see any of your content, or reach any of your application code, until they authenticate.
Because it sits in front of everything, it protects assets, uploads, and API endpoints under the same path too, not just rendered pages. It also blocks search engine crawlers completely, which is exactly what you want on a pre-launch site.
Choosing What to Protect
When you click Add protection the first question is scope, and there are two answers.
Protect entire site. Everyone visiting the domain, root, admin, everything, gets the sign-in prompt. This is the right choice for a site that is not launched yet, for a staging copy, or for anything that should not be publicly readable at all.
Protect a specific path. Lock one subpath and leave the rest of the site public. Everything beneath the path is included, so protecting /admin also covers /admin/users.
You can create more than one protection on a site, each covering a different path, with different users.
Setting It Up
- Click Add protection.
- Choose Protect entire site or Protect a specific path. For a path, type it starting with a slash, such as
/admin. - Set the Prompt label. This is the text shown in the browser sign-in dialog, up to 64 characters. It defaults to Restricted area. Something recognisable such as your site name helps visitors know the prompt is genuine rather than a phishing attempt.
- Add at least one user with a username and a password of at least 8 characters.
- Click Add user for each additional person who needs access.
- Click Apply protection.
The rule is applied and then checked against your site directly, so the status you see afterwards reflects real behaviour.
Basic Auth credentials are sent with every request. On HTTPS they are encrypted in transit, which is fine for gating a staging site or an internal area. It is not an identity system: there is no per-user audit trail, no session, no password reset flow, and no lockout after failed attempts. Do not use it to protect anything genuinely sensitive, and never reuse a password your team uses elsewhere.
Managing Users
Open an existing protection with its edit button to change the user list.
- Adding a user: click Add user, then enter a username and password.
- Changing a password: type a new one in that user's password field.
- Keeping a password: leave the field blank. Existing users show a placeholder saying the password is unchanged.
- Removing a user: click the remove button on that row.
Passwords are never displayed back to you. If someone has forgotten theirs, set a new one and tell them.
The scope of an existing protection cannot be changed. To move a protection from one path to another, remove it and create a new one.
Verifying It Works
Each protection shows a status badge:
| Badge | Meaning |
|---|---|
| Not yet verified | The check has not run yet. Refresh in a moment |
| Protection verified live (401) | We requested the URL from outside and got a genuine sign-in challenge |
| Applied but not challenging, with a status | The rule was written but the site answered with something else |
The middle badge is the one you want. It means an external request really was challenged, not that a configuration file was written.
There is also a Test button on each row, which opens the protected URL in a new tab so you can see the prompt yourself. Do that in a private window: once you have signed in, your browser will keep sending the credentials and the site will look open to you.
If you see a warning after saving that another configuration on the server claims the same domain, the protection will not apply until that conflict is resolved. The message names the other configuration. Contact support if you are unsure.
Removing Protection
Click the remove button on a protection and confirm. The confirmation is explicit about the consequence: the login prompt is removed and the path, or the whole site, becomes open to anyone.
After removal the panel re-checks the site. If it cannot confirm the site is open yet, it tells you to wait about 30 seconds and refresh rather than claiming success it has not observed.
Removing whole-site protection publishes the site to the entire internet immediately, including search engines. Before you do it on a launch day, make sure the content is genuinely ready: the right pages published, test content removed, and any placeholder pricing corrected.
Common Uses
Pre-launch. Protect the entire site while you build. Remove it when you go live. This is more reliable than a "coming soon" plugin, because it also hides your admin, your uploads, and your staging data.
Staging environments. A staging copy that is publicly readable is a duplicate-content problem and a data-leak risk. Protect it and leave it protected. See Staging Environments.
Admin areas on non-WordPress sites. For a static site or a custom application with an /admin path, this puts a second lock in front of whatever your application already does.
Client review sites. Give the client one username and password, and the prompt label tells them what they are signing in to.
Troubleshooting
I get the prompt but my password is rejected. Confirm the username has no leading or trailing space, and re-set the password from the edit dialog. Passwords must be at least 8 characters.
The site looks open to me but protected for others. Your browser has cached the credentials. Test in a private window.
Uptime monitoring now reports the site as down. Expected on whole-site protection: the checker gets a 401. See Site Uptime Monitoring, where the incident reason will show the 401.
Search engines dropped my pages. Also expected while protection is on. They return once you remove it and the site is crawlable again.
The badge says applied but not challenging. Something answered before the rule did. Note the status code shown, check whether a redirect on that path is catching the request first, and see Site Redirects.
I cannot remove the protection. Removing needs the site write permission. With a read-only role the buttons are disabled.
Related Pages
- Site Security for certificates, malware scanning, IP blocking, and login hardening.
- Country Blocking for a Site to restrict access by visitor country instead.
- Custom Error Pages to brand the 401 page visitors see.