Your staging site is live. Anyone can see it.
You're building a client site. It's on a live URL, staging.clientsite.com or a temporary domain. The design isn't done, the content is placeholder, but the URL is accessible to anyone who stumbles on it. Google might index it. A competitor might find it. The client might share the link before you're ready.
WordPress doesn't have a built-in "lock the whole site" feature. Individual posts can be password-protected, but there's no site-wide toggle.
What most people do instead
How to password protect a WordPress site without a plugin
The no-plugin route is HTTP Basic auth at the server level (Apache). You create a credentials file with htpasswd, then point an .htaccess rule at it in the WordPress root:
# 1. create the credentials file (run over SSH, outside the web root)
htpasswd -c /home/you/.htpasswd previewuser
# 2. .htaccess in the WordPress root
AuthType Basic
AuthName "Restricted"
AuthUserFile /home/you/.htpasswd
Require valid-userVisitors now get the browser's native login box before any page loads. It works, but it is a blunt instrument:
- It blocks everything, including wp-admin, the REST API, and
admin-ajax.php, so the block editor and many AJAX features break until you add explicit<Files>exceptions. - You get the browser's grey auth dialog, no branded form, no styling.
- It needs FTP/SSH access and the absolute server path to the
.htpasswdfile. - It is Apache only. On Nginx this lives in the server config, which you may not control on shared hosting.
If you want a branded wall that leaves admins and wp-admin working, the next section does it in one command.
A better way: one command, site locked
Open the navigator. Type tp password protect -password=clientpreview. Hit enter. Every frontend page now shows a password wall. Logged-in admins bypass it automatically. wp-admin, REST API, AJAX, and cron all continue working.
Shown in advanced mode, where commands start with tp. In easy mode you type the same command without the tp prefix.
Admins never see the wall. Logged-in users, wp-admin, REST API, AJAX, cron, and login pages all bypass protection automatically. Only anonymous visitors see the password form.
How it works
tp password protect -password=yourpassword enables the wall. Auto-registers as a startup command so it persists across page loads.| Detail | Value |
|---|---|
| Command name | password protect |
| Set password | -password=yourpassword |
| Scope | All frontend pages |
| Bypasses | Logged-in users, wp-admin, REST API, AJAX, cron, login page |
| Auth method | Cookie-based session after correct password entry |
| Can be used in |
Real example
You're building a WooCommerce store for a client. The site is on a temporary domain while development is in progress. The client wants to preview progress, but you don't want the public seeing an unfinished store with placeholder products and broken layouts.
You open the navigator and set a password. You send the client the URL and the password. They can browse the full site. Everyone else sees a password form. Google can't index it. Competitors can't screenshot it.
Two weeks later, the site is ready to launch. You remove the startup command entry. The password wall disappears instantly. The site is live.
Goes further with TrueCommander
Featured in: Lock down your WordPress site in 5 minutes and WooCommerce pre-launch checklist.
Frequently asked questions
.htaccess and an .htpasswd file on Apache, as shown above. It works, but it blocks wp-admin, the REST API, and admin-ajax.php too (so the editor breaks without exceptions) and shows the browser's grey login box. The command walls off only the front end and lets admins through..htaccess Basic auth, yes, everything is blocked unless you add explicit exceptions for wp-admin and admin-ajax.php.