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
A better way: one command, site locked
Open the navigator. Type 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.
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
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.