HTTP 401 Error Means Website Authentication Has Failed
An HTTP 401 error is a Hypertext Transfer Protocol status code saying that a server received and understood a request but did not receive acceptable credentials. The password, application password, API key or access token may be absent, malformed, expired, revoked or incorrect. Although the official label is “Unauthorized,” the practical meaning is usually “unauthenticated”: the server cannot establish who is making the request. By comparison, a 403 response means the server is refusing access even though identity is known or irrelevant.
A correct 401 response should include a WWW-Authenticate header, a piece of response information that identifies the expected authentication method, such as Basic or Bearer. Basic authentication sends encoded credentials with the request, while Bearer authentication uses an access token. Browsers may react by opening a credential dialog. Websites can instead show a blank page or messages such as “Authorization Required” or “Access denied due to invalid credentials.” Applications usually record the failure in their logs and receive a JSON or XML error body rather than a visible page.
The consequences depend on the affected address. Visitors cannot continue, public pages may become inaccessible to search crawlers and lose search visibility while the error persists, and a blocked login or admin path can prevent the site owner from making repairs. Intentional protection on staging, administration and API paths is normal. The problem is accidental protection of public content or an unexpected failure affecting legitimate users.
Common causes begin with credentials that were changed, disabled, rotated or allowed to expire. A stale login session can also make an authenticated user appear anonymous. This may follow a domain change, a move between www and non-www addresses, an HTTP-to-HTTPS migration or a plugin regenerating session keys. Security, membership, caching and single sign-on plugins can conflict when more than one component controls login or REST authorization, sometimes affecting only particular user roles or endpoints.
Authentication can also be imposed by the web server. Apache commonly uses an .htaccess configuration file and an .htpasswd password file, while Nginx can use an auth_basic block. A moved password file, unreadable stored-password format, restrictive file permissions or staging protection accidentally carried into production can all return 401 by design. A reverse proxy, which relays requests to the website, or a content delivery network (CDN), which serves content through distributed systems, may remove the Authorization header, cache a protected response or apply an overlooked access rule. Protected pages combined with aggressive caching can create intermittent failures that are difficult to reproduce.
Troubleshooting should start with the least disruptive checks. Open the browser’s developer tools, inspect the failed request in the Network tab and verify that the response really is 401 rather than 403, 419 or another code. Record the response headers, especially WWW-Authenticate. Test the same address in a private window and another browser. If it works there, clear cookies and site data for the domain, including both the www and non-www forms where applicable, and sign in again. Check whether the failure affects the entire site, only /wp-admin/, or one API route.
Next, reset the specific credential by changing the password, regenerating the API key or application password, or issuing a fresh token. Review Apache directives such as AuthType, AuthUserFile and Require, or the equivalent Nginx auth_basic block. Confirm that the password file exists and is readable. After making a backup, temporarily disabling that block can establish whether server-level authentication is responsible.
Clear every relevant cache, including the browser, WordPress caching plugin, server cache, object cache, which stores frequently reused database results, and CDN. If possible, test the hosting origin without the proxy, CDN or firewall. A failure that appears only through the intermediary points to its access rules, cached responses or header handling.
Plugins should be tested methodically. Deactivate all of them, verify whether access returns, and reactivate them individually until the failure reappears. If the WordPress dashboard is inaccessible, the plugins directory can be renamed through SFTP, a secure method for transferring site files, or through the host’s file manager to force bulk deactivation. Rename it back before testing each plugin. Temporarily using a default theme can reveal theme-level interference. Server access logs, error logs and firewall logs can then identify which component produced the response and which path was affected. Hosting support may also be able to see staging protection, edge restrictions or challenges that are not visible inside WordPress.
For a REST API, an interface through which applications exchange requests and data, inspect the actual outbound request while removing secrets from logs. Confirm that the Authorization header reaches the server, since proxies and some Apache CGI or FastCGI configurations can drop it. Compare the request with curl from the same network. Basic and Bearer schemes are not interchangeable, and the WWW-Authenticate response identifies what the endpoint expects. Tokens may also expire or be revoked; a connection that stops working at a regular interval should be checked for expiry first.
WordPress cookie-based REST authentication requires a valid nonce, a short-lived value used to verify that a request is intentional, for write operations from external contexts. Being signed in is not enough. Application passwords are normally used for server-to-server requests, but they must belong to a user whose role has the capability required by the endpoint. Check the base REST path as well, because rewrites or plugins can move routes. Firewall rules may challenge automated calls to admin or API paths. Allowlisting only the integration’s address or route is safer than weakening a rule globally. Excessive request rates normally produce 429 rather than 401.
Most 401 errors are configuration problems, but an unexplained pattern can justify a security investigation. Warning signs include administrators suddenly losing access while the public site continues working, a credential dialog appearing on a path that was never protected, failures spreading across many addresses, or a password reset failing to restore access. Injected code in a theme, plugin or must-use plugin, which WordPress loads automatically, can alter authentication, replace the login handler or impose another access check. Incomplete malware removal can also leave authentication hooks behind, while unauthorized directory protection may be intended to exclude legitimate administrators from an attacker’s foothold.
Do not treat a 401 alone as proof of compromise.