If WordPress links began returning 404 or 500 errors immediately after you protected a directory, the usual cause is a conflict between the web server’s rewrite rules and the folder’s authentication rules. On Apache, back up .htaccess, regenerate the WordPress rules from Settings > Permalinks, and keep Basic Authentication directives outside the # BEGIN WordPress and # END WordPress markers. On Nginx, do not edit .htaccess at all: the equivalent rules belong in the site’s server block.
Antihost offers managed WordPress hosting with free migration, one-click staging and a 14-day free trial.
This guide explains how to repair the rules without losing custom redirects, how to tell a 404 from an authentication failure, and how to prevent a protected physical directory from colliding with a WordPress permalink.
As an Amazon Associate I earn from qualifying purchases.
Why password-protecting a folder can break pretty permalinks
WordPress pretty permalinks are virtual routes. A request such as /news/example-post/ normally does not point to a file named example-post. Apache passes requests that are not real files or directories to WordPress’s index.php, where WordPress resolves the post or page.
The standard Apache rules use two important conditions: the requested path must not be an existing file (!-f) and must not be an existing directory (!-d). A physical directory therefore changes the routing decision. If you create /news/ on disk and also use news as a page or post base, Apache can stop at that directory instead of sending the request to WordPress. Adding Basic Authentication to the directory can make the symptom look like a WordPress problem, but the request may never reach WordPress at all.
Password-protection tools can also insert AuthType, AuthName, AuthUserFile and Require directives into .htaccess. If those lines are placed inside WordPress-managed markers, a later permalink save can overwrite them. Conversely, a malformed directive, an inaccessible password file or an unsupported override can cause a 500 Internal Server Error.
WordPress describes .htaccess as a distributed configuration file that lets Apache apply per-directory changes. Nginx has no per-directory .htaccess mechanism, so the same repair must be made in the Nginx server configuration.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Identify the server and the exact failure first
Do not replace configuration until you know which web server is serving the request and what status code the browser receives. Hosting dashboards often identify the stack; your host can confirm it if the dashboard does not. The following distinctions determine the correct fix.
| What you observe | Likely layer | First check |
|---|---|---|
| Pretty permalink returns 404, while the home page works | Rewrite rule is missing, not loaded, or bypassed by a directory | Server type, mod_rewrite, the WordPress block, and folder-name collisions |
Every request produces a 500 error after editing .htaccess |
Apache configuration syntax or an unsupported directive | Restore the last known-good file and inspect the server error log |
| Protected folder prompts for credentials and then shows its files normally | Authentication is working | Check only URLs outside that folder for rewrite failures |
| Protected asset returns 404 instead of a login challenge | Wrong path, missing file, or a rewrite rule intercepting the request | Request the asset’s exact physical path and verify the folder’s rules |
Nginx site has no useful .htaccess file |
Expected on Nginx | Inspect the server block and the host’s reload procedure |
A 401 response normally means the server is asking for credentials; a 403 means access is refused after authorization checks. A 404 means the requested route was not found. These are different problems and should not be “fixed” with the same rule.
Back up configuration before making any change
Make a backup copy of .htaccess before editing it. WordPress migration documentation calls this a requirement, not merely a recommendation. The file may contain redirects, security exceptions, cache rules, PHP settings and other directives unrelated to permalinks.
- Use your host’s file manager or SFTP to download the current
.htaccessfrom the document root. - Keep a second copy outside the web root, labelled with the date and the site name.
- If you have shell access, copy it before editing, for example:
cp public_html/.htaccess public_html/.htaccess.backup-2026-10-15 - Record any custom redirect or rewrite sections. Do not assume that a replacement generated by WordPress contains them.
If the site is already returning 500 errors, download the file first and then rename the live copy to something such as .htaccess.disabled. Renaming is safer than deleting because it preserves a recovery copy. If the error disappears, the file contains the fault; restore directives one group at a time.
The Tool Desk
Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →Repair an Apache site step by step
1. Confirm that Apache can use rewrite rules
Pretty permalinks require Apache’s mod_rewrite module and permission for directory-level overrides. Depending on the host, the relevant setting may be called AllowOverride FileInfo or AllowOverride All. If overrides are disabled, WordPress may display a message that it cannot write the rules, or the file may change without affecting requests. Ask the host to enable the required rewrite support rather than adding broad permissions yourself.
2. Regenerate the rules from the dashboard
- Sign in to WordPress.
- Open Settings > Permalinks.
- Leave your intended permalink structure selected.
- Click Save Changes, even if you did not change the selection.
- Check whether WordPress reports that it could not update
.htaccess. If it does, follow the manual method below or ask the host to correct override permissions.
Saving this screen causes WordPress to write the appropriate rewrite block for the installation. It does not know about every custom rule in your file, so compare the result with your backup and restore non-WordPress rules in their original locations.
3. Restore only the standard block when the file is damaged
For a typical single-site installation in the domain root, the core block resembles the following:
# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPressUse the block generated for your installation whenever possible. A WordPress site installed in a subdirectory needs a matching base and front controller path, such as /blog/ and /blog/index.php; copying the root-site block unchanged can create new 404s. Multisite installations also have additional rules, so do not replace a multisite file with the short single-site example.
4. Keep authentication outside the managed markers
Place folder-specific authentication in that folder’s own .htaccess, or place it above or below the WordPress block in the document-root file. Never put it between the managed markers, because a future permalink save can regenerate that section.
A conventional Apache folder-level configuration has this shape, with an absolute path to a password file:
Rank #3
AuthType Basic
AuthName 'Restricted area'
AuthUserFile /absolute/path/outside-the-web-root/.htpasswd
Require valid-userThe exact password-file path and permitted directives depend on the host. The password file should not be downloadable from the web. If your hosting control panel created the protection, use its remove-and-recreate function rather than hand-editing credentials you cannot verify.
5. Check permissions without making the site writable to everyone
WordPress needs enough permission to write .htaccess when it regenerates Apache rules. The permissions documentation also warns that broad write access can let an attacker alter files and take control of the site. Do not “fix” a failed save by making the whole web root world-writable or by using 777. Ask the host to align the file owner and web-server user, grant temporary least-privilege write access, save the permalinks, and then return the file to a restrictive mode.
Crashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minuteWindows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstall6. Clear caches only after the server rules are correct
Clear a page cache, reverse proxy cache or CDN cache after repairing the server configuration. A cached 404 can survive a correct rewrite change and make troubleshooting appear unsuccessful. Test in a private browser window or with a fresh request so previously cached credentials and responses do not obscure the result.
Protect a folder without colliding with WordPress routes
Choose a directory name that is not used by a page, post, category base, author base, REST endpoint or other intended permalink. For example, if WordPress uses /reports/ for a page, do not create a physical protected directory at /reports/. Rename the folder to a clearly separate path such as /private-reports/, update links, and then apply authentication there.
This matters because Apache’s !-d condition deliberately allows existing directories to bypass the front controller. Authentication can be perfectly configured while WordPress still appears to lose the route. Renaming the directory removes the ambiguity instead of adding more rewrite exceptions.
Protecting an uploads subdirectory, backup directory or downloadable archive is a different use case from protecting /wp-admin/. WordPress’s hardening guidance notes that server-side Basic Authentication around /wp-admin/ adds a second layer around the login screen and administrative files. Apply it only when your workflow supports the extra prompt, and test scheduled tasks, XML-RPC or API clients that may not handle browser authentication.
Recommended Free Tools
Repair Nginx sites in the server block
Nginx does not read per-directory .htaccess files. Editing one on an Nginx deployment will not change routing and may distract you from the active configuration. The equivalent WordPress front-controller rule is normally defined with a try_files directive in the site’s server block, conceptually like this:
location / {
try_files $uri $uri/ /index.php?$args;
}Your host may use a different PHP location, multisite rules or an include file. Treat the example as a pattern, not a complete server configuration. Put Basic Authentication in the specific Nginx location for the protected path, using the host’s supported auth_basic and password-file settings. Do not paste Apache AuthType directives into Nginx.
- Identify the active server-block file or managed include.
- Back up that configuration before editing.
- Verify that the WordPress
try_filesrule sends non-file requests toindex.php. - Keep authentication limited to the intended location and ensure the password file is readable by Nginx but not publicly downloadable.
- Validate the configuration with the host’s supported test command, then reload Nginx using the hosting provider’s procedure.
On managed hosting, configuration reloads may be restricted. Provide the host with the failing URL, status code, protected path and the time the change was made; ask them to verify the server block and error log rather than asking them to “reset permalinks” blindly.
Use the symptom to choose the next diagnostic
| Symptom | Checks in order | Safe correction |
|---|---|---|
| Only URLs whose first segment matches the protected folder fail | Compare the URL with physical directories; inspect the !-d behavior |
Rename the directory or choose a non-conflicting permalink base |
| All pretty URLs fail, but direct PHP or the home page works | Check mod_rewrite, override permissions and the WordPress block |
Save Settings > Permalinks or restore the generated block |
| 500 begins immediately after adding authentication | Inspect syntax, password-file path and allowed overrides | Restore the backup, then recreate protection through the host’s supported method |
| Permalink save succeeds but behavior does not change | Determine whether the site is Nginx, behind a proxy, or using another document root | Edit the active server block or ask the host which configuration serves the domain |
| Rules work until the next permalink save | Look for custom directives inside WordPress markers | Move authentication and custom redirects outside the markers |
| Only a protected file or image fails | Check its exact filesystem path, file permissions and authentication response | Correct the path or location rule; do not send every asset through WordPress unnecessarily |
If you cannot reach the WordPress dashboard
You can still recover Apache routing without logging in to WordPress:
Free tools Windows power users keep installed
One-click scans. No signup required.
- Download and rename the current
.htaccessso Apache stops reading the suspect file. - Request the home page and one known post. If they now work, the previous file or one of its custom directives was responsible.
- Create a minimal, backed-up WordPress block appropriate to the installation path, or ask the host to generate it.
- Restore custom redirects and folder authentication one section at a time, testing after each addition.
- Once the dashboard is available, open Settings > Permalinks and save the structure to let WordPress normalize its managed rules.
If renaming the file does not change the response, the site may be running Nginx, using a different document root, or failing before rewrite processing. The server error log and host confirmation are more useful than repeated edits to an inactive file.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Special cases that need extra care
Subdirectory installations
When WordPress is installed at example.com/blog, every generated path must include /blog. A root-level rewrite sent to /index.php can bypass the installation or create a loop. Use the exact block shown by the Permalinks screen for that installation.
Multisite
Multisite networks use additional rewrite conditions and, in some modes, different handling for subdirectory sites. Preserve the existing network-generated rules and take a network backup before changing them. A short single-site block is not a safe substitute.
Host-managed protection panels
Control panels may store credentials in a host-managed file and inject rules automatically. Removing lines by hand can leave the panel and filesystem out of sync. Disable the protection in the panel, regenerate permalinks, then re-enable protection on a non-conflicting directory if necessary.
Custom redirects and application rewrites
Redirect plugins and hand-written rules may intentionally run before or after WordPress. Preserve their order from the backup. A redirect placed before the WordPress block can prevent a protected path from reaching its authentication location; one placed after it may never run for an existing directory.
Which repair approach fits your situation?
| Approach | Best when | Risk or limitation |
|---|---|---|
| Save Settings > Permalinks | Apache is confirmed, the dashboard works and the file is writable | May overwrite custom lines inside WordPress markers |
| Restore the standard block manually | The dashboard is unavailable or the file is visibly corrupted | Requires the correct root, subdirectory or multisite variant |
| Move authentication to the protected folder | Folder-level Basic Authentication is needed | Requires a valid password-file path and host support for auth directives |
| Rename the physical directory | A real folder shares a slug with a WordPress route | Links, scripts or downloads pointing to the old path must be updated |
| Ask the host to enable rewrite support | mod_rewrite, overrides, ownership or Nginx access is outside your control |
Resolution depends on the provider’s configuration and reload policy |
Test the repaired site with representative requests
Do not stop after the home page loads. Test each routing layer separately:
- The home page, to confirm the web root still serves normally.
- One published post with a pretty permalink.
- One static page, preferably under a different path.
- An asset that should remain public.
- An asset or document inside the protected folder.
- An unauthenticated request to that protected path, which should receive the intended authentication challenge or denial response rather than a WordPress 404.
- An authenticated request, confirming that the expected file or index is actually reachable.
- A custom redirect, if the site uses one.
- Any scheduled job, API client or mobile app that accesses a protected endpoint.
Repeat the checks after clearing the relevant cache. Record the URL, status code and whether the response came from Apache, Nginx, a proxy or WordPress. That record lets a host identify the failing layer quickly.
When to stop editing and contact the host
Escalate when you cannot identify the active server, do not have access to the document root, receive a 500 after restoring a known-good file, or need changes to AllowOverride, mod_rewrite, an Nginx server block or file ownership. Include your backup, the exact failing URL, the response code, the protected directory name, whether the site is Apache or Nginx, and the time of the first failure. Do not send passwords or the contents of a password file.
Quick wins for a faster PC:
Repair Windows errors before they cause bigger problemsFix Now →Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Clear out junk files and repair common Windows errorsFree Scan →The most reliable long-term arrangement is simple: let WordPress own only the rules between its markers, keep folder authentication in the folder or a separate server location, avoid physical-directory/permalink collisions, and retain a dated backup before every configuration change.
Conclusion
Password protection does not inherently disable WordPress permalinks. Failures occur when the server processes a real directory before WordPress, when rewrite support is unavailable, when a managed block is overwritten, or when authentication directives are invalid for the server in use. Back up first, identify Apache versus Nginx, regenerate the correct WordPress rules, isolate authentication from the managed block, and test both public and protected URLs. That sequence fixes the common 404 and 500 patterns without sacrificing custom redirects or weakening file permissions.
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.
