Protect a Complete WordPress Website With One Password
There are many situations where a WordPress website needs to exist online without being publicly accessible.
An agency may be building a new client website on a staging domain. A company may be preparing a redesign before launch. A developer might need stakeholders to review a project remotely while preventing ordinary visitors from browsing unfinished pages.
Creating individual WordPress accounts for every reviewer can be unnecessary, while relying only on obscure URLs does not actually make the website private.
Password Protection adds a shared access gate in front of the WordPress frontend. Visitors who have not unlocked the site see the password screen instead of the requested page. Once they enter the correct password, they can browse the protected website normally for the remainder of their browser session.
The site password itself is stored using WordPress password hashing rather than as readable plain text. Changing the configured password also invalidates previously granted access, making it easy to revoke an old shared password when a project moves to another stage.
Create a Branded Password Screen
A client reviewing a development website should not necessarily see a generic WordPress access form.
Password Protection includes controls for customizing the gate so it can better match the project or company brand. You can set your own title, introductory message, and button text, upload or specify a logo, and control the logo width.
The page background can use a solid color or a full-screen image. When using an image, an adjustable overlay can improve readability and help the access form stand out against the background. Form-card colors, button colors, and hover styling can also be adjusted.
This makes the gate suitable for client previews and pre-launch sites where presentation still matters even though the website is not yet public.
The password screen itself is marked noindex,nofollow, reinforcing that the gate is an access screen rather than content intended for search results.
Protect More Than the Visible Frontend
Showing a password form on normal pages would provide incomplete protection if anonymous visitors could still retrieve site data through other WordPress interfaces.
While the gate is active, anonymous REST API requests are rejected until the visitor has valid access or qualifies for an administrative bypass. Unauthenticated XML-RPC access is also blocked.
This helps keep the protection consistent beyond ordinary browser page requests.
WP PowerSuite also handles public AJAX conservatively. Logged-in users can continue using admin-ajax.php, while anonymous AJAX requests are denied unless a developer explicitly allowlists the required action.
That distinction is important for custom websites. If a protected frontend depends on an anonymous AJAX action, that action may need to be intentionally allowed rather than opening every anonymous AJAX request by default.
For sites that want REST or XML-RPC restricted even after Password Protection is removed, the separate Disable REST API and Disable XML-RPC modules provide permanent controls for those interfaces.
Keep Search Engines and Crawlers Out of the Private Site
A protected development website should not present its password screen to search crawlers as though it were ordinary public content.
WP PowerSuite identifies common search-engine and crawler user agents and returns an HTTP 403 Access Denied response rather than showing them the password form. The gate HTML itself is also marked noindex,nofollow.
This helps communicate that the protected frontend is not intended for indexing.
However, Password Protection should not be treated as a search-engine removal tool. URLs that were already discovered or indexed do not automatically disappear simply because the site is now password protected, and static files or previously known sitemap URLs may still exist independently of the frontend gate.
For production SEO checks, WP PowerSuite's Search Visibility Warning can separately alert administrators when WordPress's own "Discourage search engines from indexing this site" setting remains enabled.
