I’ve encountered this frustrating issue numerous times over the years. Each time I hope “this will be fixed in the next version,” but unfortunately, it persists. Let me explain the problem and share the solution I’ve found.

The Problem

You have a directory that you want to password protect – let’s call it “secrets.” It resides in /home/mysite/public_html/secrets/ on your server. You’re using a hosting control panel like cPanel, and you’ve successfully password-protected directories before.

Before activating protection, you can view the contents of the directory without issues. However, after enabling password protection (which creates a .htaccess file in that directory), instead of being prompted for your username and password, you get:

  • A 404 error, or
  • A 403 message from WordPress saying “Sorry the page you are looking for cannot be found”

Investigating the Logs

As a diligent administrator, you might check the server logs and find something perplexing:

  • The access log shows a 404 error (page not found)
  • The error log tells a different story:
Permission denied: /home/mysite/public_html/secret/.htaccess pcfg_openfile: unable to check htaccess file, ensure it is readable

Past (Non-Recommended) Solutions

This error has had various proposed solutions over the years, including the infamous “reinstall FrontPage extensions.” However, these extensions are no longer supported and installing them is strongly discouraged – it will likely cause more problems than it solves!

The Actual Solution

The solution is surprisingly simple – just add a couple of lines to the WordPress .htaccess file in the root of your site (e.g., /home/mysite/public_html/.htaccess).

Find the file and locate the line that says #BEGIN WordPress. Just before this line, add the following:

ErrorDocument 401 /%{REQUEST_URI}/errors.html
ErrorDocument 403 /%{REQUEST_URI}/errors.html

Why This Works

The root of the problem lies in WordPress’s permalink structure. When you have “pretty URLs” enabled (which most WordPress sites do), here’s what happens:

  1. You request your password-protected directory
  2. The server tries to access it and encounters the .htaccess protection
  3. The protection mechanism attempts to redirect to an authentication prompt
  4. WordPress intercepts this redirect, treating it as a request for a non-existent page
  5. WordPress then returns its standard 404 error

Under normal circumstances, WordPress allows direct access to existing files and directories. However, when a directory is password-protected with .htaccess, WordPress doesn’t recognize the authentication request properly.

The added ErrorDocument directives essentially tell WordPress to stay out of the way when these specific authorization-related error codes (401 and 403) are triggered. This allows the .htaccess authentication process to proceed correctly and display the password prompt as intended.

Implementation Tips

  • Make sure you add these lines before the WordPress section in the .htaccess file
  • The errors.html file doesn’t actually need to exist – this is just a way to pass control back to the server’s authentication system
  • After making this change, you should get the expected username/password prompt when accessing your protected directory

I hope this solution saves you time and frustration if you encounter this common WordPress and .htaccess conflict.