Overview & Common Causes

1. Missing Password Authentication Files (.htaccesspasswd): A custom password protection rule inside the .htaccess configuration file references a password file path that no longer exists on the server.
    
2. Legacy Directory Paths Post-Migration: The domain was previously migrated or transferred, and the .htaccess file still references an outdated Linux file path (e.g., /home/username/ instead of /var/www/vhosts/[domain.com/httpdocs/](https://domain.com/httpdocs/)).

Our Support Boundary: Hosting Diagnostics vs. Code Maintenance

• What Hosting Support Provides: Server log diagnostics, identifying broken file path directives, resetting WordPress admin credentials via WP Toolkit, and verifying PHP/database connectivity.
   
• What Belongs to Your Web Developer: Modifying custom site security rules, generating custom .htaccesspasswd files, or rewriting custom .htaccess directives for complex application requirements.

Step 1: Identifying the Root Cause in Plesk

1. Log into your Plesk Panel.
2. Navigate to Files in the left menu and open the httpdocs directory.
3. Click on the .htaccess file to open the text editor.
4. Look for an HTTP Basic Authentication rule similar to the following:

<FilesMatch "wp-login.php">
AuthType Basic
AuthName "Secure Area"
AuthUserFile "/home/domain/.htaccesspasswd"
require valid-user
</FilesMatch>

5. Check whether the file listed under AuthUserFile actually exists in your server files. If the file is missing or the directory path is outdated from a past server migration, Apache cannot validate the login request and will return a 500 Internal Server Error.

Step 2: Resolving the Error

Option A: Restore Default WordPress .htaccess Rules (Recommended)

1. Open .htaccess inside Plesk File Manager (Files > httpdocs).
    
2. Save a backup copy of your current .htaccess contents to your local computer.
    
3. Replace the entire contents of .htaccess with the official, standard WordPress configuration code (provided by WordPress.org):

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteBase /
RewriteRule ^index.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

4. Click Save or Apply.
    
5. Test [yourdomain.com/wp-login.php](https://yourdomain.com/wp-login.php) in a new browser window. The login page will now render normally.

Option B: Update the .htaccesspasswd Path (For Custom Security)

1. Update the AuthUserFile path in .htaccess to point to the correct, absolute path on your server (e.g., /var/www/vhosts/[yourdomain.com/httpdocs/.htaccesspasswd](https://yourdomain.com/httpdocs/.htaccesspasswd)).
    
2. Ensure a valid .htaccesspasswd file containing encrypted user credentials exists at that exact path.

Step 3: Post-Recovery Environment Checklist

1. Reset Admin Credentials via WP Toolkit:
   If you or your web contractor do not remember your WordPress login password, navigate to Plesk > WordPress Toolkit > Set Up / Change Password to set a fresh password instantly without accessing the database.
    
2. Review PHP Environment Compatibility:
   Legacy WordPress installations experiencing login errors are frequently tied to end-of-life PHP versions (e.g., PHP 5.6). Once your core site files are updated, navigate to Plesk > PHP Settings to upgrade your site to a modern, supported PHP release (PHP 8.1+).
    
3. Update WordPress Core, Themes, and Plugins:
   Outdated plugins can introduce security vulnerabilities or conflicts. Run all pending updates directly within the WordPress Toolkit dashboard.