Free tools Windows power users keep installed
One-click scans. No signup required.
iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Antihost offers managed WordPress hosting with free migration, one-click staging and a 14-day free trial.
To put one password in front of every WordPress URL, use a site-wide protection plugin or authentication at the web-server layer. WordPress’s normal post and page password setting is not a complete site lock. A plugin is the practical choice when you manage WordPress but not the server; Apache Basic Authentication is broader and runs before WordPress, but requires hosting access. Whichever method you choose, keep HTTPS enabled, test cached and direct URLs, and preserve an SFTP or SSH recovery path before turning the lock on.
What “password protect the entire site” actually means
A whole-site gate challenges a visitor before the site serves its content. The challenge should cover the home page, deep links, archives, media files, feeds, login-related URLs, and any other path you do not want publicly readable. This is different from selecting Password Protected on a single post or page: that setting protects only that item and does not automatically cover the rest of the installation.
Recommended Free Tools
There are three ways to restrict WordPress content:
- Site-wide plugin: WordPress checks the visitor and presents a password screen. You configure it from the dashboard.
- Apache Basic Authentication: the web server checks credentials before PHP and WordPress run. A matching
.htaccessand.htpasswdsetup can protect the whole directory. - Built-in visibility controls: WordPress can mark individual posts and pages as Public, Private, or Password Protected. Its documentation says a complete private, password-protected blog requires a plugin.
The right method depends on who controls the hosting layer, whether static files must be hidden, how your cache is configured, and how you will recover if the gate blocks administrators.
#1 Best Overall
Plugin versus server authentication: a practical comparison
| Criterion | Site-wide WordPress plugin | Apache Basic Authentication | Per-post or per-page passwords |
|---|---|---|---|
| What it protects | Configured WordPress content; many plugins can include pages, posts, products, categories, custom post types, and partial content | Everything under the protected server directory, including WordPress output and static files | Only the selected posts or pages |
| Where it operates | Inside WordPress after the request reaches PHP | At the web-server layer before WordPress renders a response | Inside WordPress for an individual item |
| Setup access needed | Administrator dashboard, plus a recovery route | Hosting access to .htaccess, an .htpasswd file, and server configuration |
Editor or administrator access to each item |
| Visitor experience | A WordPress-generated password page; options may include bypass links or exclusions | The browser’s native username/password dialog | A password form on each protected item |
| Administrator bypass | Usually configurable; verify the plugin’s setting and test it | Not automatic; create a separate rule or credential strategy if needed | Logged-in users may still encounter item-level behavior |
| Caching and CDN behavior | Requires cache exclusions or purging because a cache can retain public or authenticated HTML | Still requires cache review, but the server check occurs before the origin serves the protected directory | Can be inconsistent when page caches serve a previously generated response |
| Recovery path | Disable or remove the plugin through SFTP or SSH if the dashboard is inaccessible | Restore or rename the configuration file through hosting file tools, SFTP, or SSH | Restore each item’s visibility setting in the dashboard |
| Best fit | Site owners who want a dashboard workflow | Owners or developers who control Apache configuration and need a WordPress-independent barrier | A small number of intentionally gated articles or pages |
Prepare the site before enabling a lock
A password gate is easy to switch on and surprisingly easy to make difficult to undo. Complete these checks while you can still reach the dashboard and hosting account:
- Confirm the scope. Decide whether “entire site” includes images, downloadable files, feeds, REST responses, the WordPress login screen, and a separate subdirectory such as a documentation area.
- Keep HTTPS working. Obtain a valid certificate for the public hostname and make sure both the visitor address and administrative address redirect to HTTPS. Basic Authentication credentials are only weakly Base64-encoded, so sending them over plain HTTP exposes them to interception.
- Save a recovery route. Verify that an SFTP or SSH account works, record the host, port, username, and key or password location, and confirm that you can reach the site files without relying on WordPress.
- Record the current configuration. Back up the database and WordPress files. Copy the current
.htaccessfile before editing it, and note the active theme and plugins. - Inventory integrations. List payment callbacks, uptime monitors, webhooks, search-console verification files, mobile apps, and other services that may need an exclusion or a separate credential.
- Plan a cache purge. Know how to clear the page cache, object cache, reverse proxy, and CDN. A stale public response can make a lock appear broken.
Method 1: protect the site with a WordPress plugin
A dedicated site-wide plugin is normally the simplest option for a nontechnical site owner. The WordPress.org listing for Password Protected — Lock Entire Site, Pages, Posts, Categories, and Partial Content describes a single master password for an entire site and additional controls for individual pages and posts, WooCommerce products and categories, custom post types, and partial content. Its listed options include IP-address whitelisting, bypass links, exclusions, password expiration or usage limits, and login-attempt limits. Treat those as plugin-specific capabilities: labels and defaults can change with updates, so review the settings screen you actually have installed.
Do these 3 things before closing this tab:
1Scan for outdated or missing drivers - takes under a minute2Clear out junk files and repair common Windows errors3Fix the driver behind crashes, sound loss and screen glitchesInstall and configure the gate
- Sign in to WordPress with an administrator account.
- Open Plugins → Add New.
- Search for the exact plugin name, inspect the author, compatibility information, and update history, then select Install Now.
- Select Activate. Open the plugin’s settings page from the new dashboard menu or from Settings.
- Enable the option described as complete-site, whole-site, or entire-site protection. Do not assume that an option for protecting selected posts has the same effect.
- Create a long, unique master password. Do not reuse an administrator password, hosting password, or a password used for email.
- Decide whether administrators bypass the gate. If you enable a bypass, test it with a separate logged-in browser and also test a logged-out visitor; otherwise it is easy to mistake an administrator session for public access.
- Configure exclusions only when a service genuinely needs them. Typical examples are a health-check endpoint, a payment callback, or a verification file. Every exclusion is an intentional opening, so document its URL and owner.
- Save the settings, open a private or incognito browser window, and request the home page. Repeat with a deep link that you have never visited in that browser.
Keep the SFTP or SSH details beside your maintenance notes before activation. The plugin documentation explains that, if its password screen also blocks the administrator, removing or disabling the plugin folder over SFTP or SSH can restore access. The exact folder name is shown in the plugin directory and can change, so identify it before an emergency rather than guessing.
When a plugin gate is the better choice
- You do not have permission to edit server configuration.
- Different areas need different rules, such as a public landing page plus a private catalogue.
- You want dashboard controls for IP allowlists, bypass links, expiration, or attempt limits.
- Your host uses nginx or IIS and does not support Apache
.htaccessfiles.
A plugin runs as part of WordPress, so a PHP fatal error, an incompatible cache, or a misconfigured maintenance mode can affect the gate. Keep WordPress, the plugin, and the active theme updated and test after updates.
Method 2: use Apache Basic Authentication with .htaccess
Apache Basic Authentication is independent of WordPress. The server requests credentials before it passes the request to PHP, which makes it suitable when you want to cover WordPress pages, wp-login.php, uploads, feeds, and other files under one directory. WordPress’s installation FAQ points to this approach but cautions that there is no guaranteed, universal way to make a blog private. Hosting layouts, Apache modules, and permission policies differ.
Create the password file
Use the host’s control-panel tool or the htpasswd command supplied by Apache. Store the file outside the public document root when the host permits it. A typical command is:
htpasswd -c /home/account/.htpasswd privateuserThe -c option creates a new file; omit it when adding another user to an existing file. The command prompts for the password and stores a hash rather than the plain text password. If your host does not provide shell access, use its protected-directory feature or ask support for the correct absolute path.
Add the authentication rules
In the directory that contains the WordPress installation, add rules similar to these, changing the password-file path to your host’s real path:
AuthType Basic
AuthName "Private WordPress site"
AuthUserFile /home/account/.htpasswd
Require valid-userDo not put custom directives inside WordPress’s managed # BEGIN WordPress and # END WordPress section. WordPress can rewrite that section during permalink changes and overwrite your authentication rules. Place the directives outside it, and keep a backup of the original file.
Apply and verify the server lock
- Save the file and open a new private browser window.
- Request the home page. The browser should show its native credential prompt before the page loads.
- Enter the test username and password, then request a deep permalink, an image URL, a PDF in uploads, the feed, and
/wp-login.php. - Open the same URLs after signing out of WordPress. A logged-in WordPress session does not replace server authentication.
- If the server returns a 500 error, immediately restore the previous
.htaccesscopy or use the host’s file manager. A misspelled directive, an unavailable Apache module, or an incorrect password-file path can make the directory inaccessible.
Basic Authentication is not encryption. Base64 makes credentials readable encoding, not a protective cipher. Use HTTPS for every request and avoid sending the password through an untrusted network. Change the credentials if you suspect they were exposed.
Know your server stack
.htaccess applies to Apache only. Nginx uses server-block configuration, and IIS uses web.config. Managed WordPress hosts may prevent customers from editing any of these files or may provide a dashboard control instead. Check the host’s documentation before inserting directives from an Apache tutorial into another server. If you cannot confirm the stack or reload procedure, use a plugin or ask hosting support to configure a protected directory.
Method 3: WordPress’s built-in visibility settings
In the editor, the Visibility control lets you set a post or page to Public, Private, or Password Protected. This is useful when only a few items need a shared password. WordPress stores the entered password in a browser cookie so a reader does not have to re-enter it on every visit, and the core behavior tracks one password at a time for protected posts.
It is not a dependable whole-site gate. The home page, navigation, archives, media, feeds, and unrelated posts remain governed by their own settings. If protected posts must be removed from home or archive queries, WordPress documents a custom pre_get_posts and posts_where approach; that is a development customization, not a replacement for site-wide authentication.
Use this method when the requirement is explicitly “protect these two articles” or “send a password to members for this page.” Choose a plugin or server authentication when every URL must challenge an unauthenticated visitor.
The Tool Desk
Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Test the lock beyond the home page
Perform the following checks from a private browser session with no WordPress cookies:
- Canonical pages: home page, a nested page, a post, category and tag archives, author archives, search results, and a 404 URL.
- Files: an image, a stylesheet or script URL, a file in the uploads directory, and a downloadable document. Confirm that a visitor cannot fetch a sensitive file by pasting its direct URL.
- Feeds and APIs: the RSS or Atom feed and any REST or JSON endpoint your site exposes. Decide deliberately whether an integration should remain available.
- Authentication paths:
/wp-login.php, password-reset links, and any custom login URL. Verify which prompt appears and that the intended administrator workflow still works. - Sessions: test logged out, logged in as an administrator, logged in as a non-administrator, and after clearing cookies. A bypass that works only because of an old cookie is not a reliable test.
- Networks: repeat from a second connection, such as a phone hotspot. A corporate proxy or local cache can hide a configuration error.
If a public page still appears, purge every page cache and CDN layer, then test again with a cache-busting query only for diagnosis. Do not treat a cached response as proof that the origin is unlocked; determine whether the cache is serving old HTML or deliberately bypassing the authentication request.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Troubleshooting common failures
| Symptom | Likely cause | Action |
|---|---|---|
| The administrator sees a loop or cannot reach the dashboard after activating a plugin | The plugin is configured to protect administrators, or a cookie/session conflict exists | Use SFTP or SSH to disable or remove the plugin folder, clear browser cookies, and re-enter the dashboard. Re-enable it only after confirming the bypass setting. |
| The home page is protected but an image or PDF is public | The plugin excludes static files, or the server rule covers only a subdirectory | Check the plugin’s exclusions and test the file’s real path. For complete file coverage, protect the document root at the server layer. |
| Visitors see old public HTML after the lock is enabled | A page cache, reverse proxy, or CDN retained a previous response | Purge all cache layers, exclude the gate and authenticated responses from caching, and repeat the test from another network. |
| Apache returns a 500 error | Invalid directive, unavailable module, incorrect AuthUserFile path, or a host policy that disallows overrides |
Restore the backup .htaccess, inspect the server error log if available, and ask the host which authentication directives are supported. |
| The browser repeatedly asks for credentials | Wrong username/password, a stale saved credential, or a password file that Apache cannot read | Delete the saved browser credential, recreate or update the user with htpasswd, verify file permissions, and confirm the absolute path. |
| A webhook or monitoring service fails | The endpoint is now behind the gate | Either give that service a narrowly scoped exclusion or move the endpoint to a separately secured location. Record the exception and monitor it. |
Security and maintenance after protection is enabled
The gate controls who can reach content; it does not harden WordPress itself. Continue applying core, theme, and plugin updates, use least-privilege accounts, maintain tested backups, and remove unused extensions. Protect the hosting account and SFTP or SSH keys with strong, unique credentials and multi-factor authentication where available.
Rotate the site password when a contractor leaves, when a shared link has circulated beyond its intended audience, or when you suspect disclosure. If you use a bypass link, treat it like a credential: make it unguessable, set an expiration if the plugin supports one, and revoke it when the project ends. Keep a written list of every exclusion, who approved it, and when it should be removed.
For a development site, consider whether a separate staging environment with its own hostname and access control is safer than placing a temporary gate on a production site. A staging copy prevents unfinished pages from leaking while keeping production’s cache, analytics, and integrations predictable. If you must lock production during construction, schedule a short maintenance window, announce the expected behavior to collaborators, and test the unlock procedure before publishing.
Which method should you choose?
Choose a plugin when
- You manage the site through WordPress and do not control Apache, nginx, or IIS.
- You need dashboard-level exclusions, IP allowlists, bypass links, expiration, or attempt limits.
- You want to protect selected content differently while keeping the configuration visible to editors.
Choose Apache authentication when
- You control the Apache document root and want a barrier that runs before WordPress.
- Static assets and direct file URLs must be covered by the same credential prompt.
- You can maintain HTTPS, edit configuration safely, and recover through hosting tools if a syntax error occurs.
Choose built-in visibility when
- Only a small, known set of posts or pages needs a shared password.
- You accept that the rest of the site, media library, feeds, and other URLs are not automatically hidden.
For most WordPress owners building or temporarily closing a site, start with a reputable site-wide plugin and preserve SFTP or SSH access. Use server authentication when you need WordPress-independent coverage and have the hosting expertise to operate it. Do not mistake individual post passwords for a site-wide lock, and do not activate any gate until HTTPS, cache behavior, and recovery have been tested.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
