401 Unauthorized means the request lacks valid authentication credentials for the target resource. Despite its name, it is about authentication ("who are you?"), not authorization. The server must send a WWW-Authenticate header with at least one challenge, such as Basic realm="Staging" or Bearer, that tells the client how to authenticate.
If the request already contained credentials, the 401 means they were rejected: a wrong password or an expired token. Browsers show a login dialog for Basic and Digest challenges. APIs return 401 for missing or invalid tokens so that the client can obtain a new token and try again.
Use 403 Forbidden when the user is known but not allowed, and 407 when a proxy rather than the origin server demands authentication.
Example response
HTTP/1.1 401 Unauthorized
Date: Fri, 06 Nov 2026 10:15:32 GMT
WWW-Authenticate: Basic realm="Staging", charset="UTF-8"
Content-Type: text/plain; charset=utf-8
Content-Length: 23
Authentication requiredSEO and redirect checking
Pages behind authentication cannot be indexed: crawlers do not log in, and URLs that return 401 are treated like other 4xx errors. That is exactly what you want for staging sites, admin areas and private content, and HTTP authentication keeps a staging site out of search results far more reliably than robots.txt. Make sure the production site does not keep the staging password by accident, and never answer crawlers with 401 on public pages.
To check a protected URL with TrueURL, you can add an Authorization header under Custom Request Headers. Use test credentials for this.
Common causes and use cases
- HTTP Basic authentication protects a staging or admin site.
- An API token is missing, expired or revoked.
- A session expired and the API answers 401 instead of redirecting to a login page.
- Credentials were lost on a redirect: many clients drop the
Authorizationheader when a redirect leads to another host.