401 Unauthorized Error: What It Means and How to Fix It

What is a 401 Unauthorized error?

A 401 Unauthorized error is an HTTP status code that means the server rejected your request because it found no valid credentials. The server either saw no username and password at all, or it did not recognize what you sent. The response usually carries a WWW-Authenticate header that tells the client which login method it expects.

We are a digital marketing and web team, not a hosting company. The technical explanations here rest on RFC 9110, MDN, Google Search Central and Apache documentation. Our goal is simple: when you see this code, you should know quickly who has to fix what.

According to the MDN reference, the code says the request lacks valid authentication credentials for the target resource. Despite the name, it usually means "we could not verify who you are", not "you have no permission". That difference matters, because it separates 401 from 403.

What is the difference between 401 and 403?

A 401 means the server does not know who you are, or it could not verify your credentials. A 403 means the server understood the request and still refuses to fulfil it. So for a 401 the fix is often "log in or send the right credentials", while for a 403 a permission, rule or firewall setting has to change.

The table below sorts both codes by who is responsible. Under RFC 9110, a server must include a WWW-Authenticate header in a 401 response. A 403 response has no such requirement.

If you see a 403, the problem most likely sits in a firewall or in file permissions. We do not cover that here; read our guide to ModSecurity and 403 errors instead.

Who should fix a 401 Unauthorized error: the visitor, the site owner or the server admin?

Finding the responsible person first saves hours of searching in the wrong place. The person who sees the error is often not the person who can fix it. So the first question is always: did somebody put a password on this page on purpose?

• Visitor: Enter the correct username and password, or clear the old session or saved password in the browser.
• Site owner: Find out which folder, application or integration carries the protection, and remove it if it should not be there.
• Server administrator: Review the authentication rules in the Apache or Nginx configuration, the password file and the proxy settings.

For example, when a client says "our site asks for a password", check first whether a staging protection travelled to the live site. That single check solves a surprising share of cases before anyone creates a new user.

On shared hosting you cannot reach server-level settings. In that case, the fastest route is to send your provider the evidence and let them look.

What does the WWW-Authenticate header tell you?

WWW-Authenticate is the header a server sends with a 401 to say "prove your identity this way". It names the authentication scheme and often a realm. When a browser sees it, the browser opens the username and password dialog.

A typical response looks like this:

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Basic realm="Staging"
Content-Type: text/html

Here "Basic" names the scheme and "Staging" is the area name shown in the dialog. For APIs the same header can announce another scheme, such as Bearer. In fact, the MDN example shows exactly a Bearer challenge.

When the client retries with the right data, it sends an Authorization header. If the server accepts it, you get a 200; if not, you get another 401. Reading both headers together shows you quickly on which side the problem sits.

Why does a 401 Unauthorized error happen?

Most causes fall into a few groups. Knowing your group shortens the diagnosis.

• A folder or the whole site uses Basic Auth, and nobody entered credentials.
• The username or password is wrong, or the password file is out of date.
• An API request has no token, an expired token or the wrong scheme.
• The session cookie vanished, or the server session ended.
• A reverse proxy or CDN does not forward the Authorization header to the origin server.
• Someone copied the staging protection to production.

In addition, a security plugin or a hosting panel can guard certain paths, such as an admin or API path, with an extra password. Somebody usually switches these on deliberately, but after a few months everyone forgets.

In short, a 401 is rarely a malfunction. Most of the time it shows that a rule works. The real question is whether that rule belongs there.

In which order should you diagnose a 401 error?

Instead of changing settings at random, follow a fixed order. Each step rules out one possibility.

1. Open the address in a private window. If an old session or saved password caused it, the error disappears.
2. Send a request from the command line so you can see the headers.
3. Read the WWW-Authenticate value and note the scheme.
4. Try the same address from another network, since a rule may target certain IP addresses.
5. Read the server error log and find the authentication line.
6. Think about the latest change: did a new plugin, panel setting or deployment go live?

To see the headers, you can run this command:

curl -I https://example.com/protected-page/

If the first line shows 401 and a WWW-Authenticate header follows, the problem sits in an authentication rule. If the header is missing, a proxy or the application layer probably rewrites the response.

If you cannot reach the server logs, leave this step to your provider. A log line usually shows which rule produced the error, so you only need to request the relevant time window.

What should a site visitor do about a 401 Unauthorized error?

As a visitor you can do only a little, but it is often enough. First, make sure you typed the address correctly, because a wrong subfolder sometimes leads into an admin area.

• If the page is a private area, enter your username and password again.
• Delete the saved password and the site data in your browser, then retry.
• Try another browser or a private window.
• Ask the site owner for the password; do not try to guess it.

If you see this error on a page that should be public, the problem is not on your side. In that case, send the site owner the page address and the time of the error, so the diagnosis stays short.

Also, a 401 on a public page signals a misconfigured site. Visitors leave when they hit it, and search engines cannot read the page either.

How do Basic Auth and .htpasswd work?

Basic Auth is the simplest authentication scheme in HTTP. The client joins the username and password, encodes them with base64 and sends them in the Authorization header. Base64 is not encryption; it is only an encoding.

For that reason the Apache documentation warns that Basic authentication sends the password unencrypted and recommends mod_ssl for sensitive data. In other words, Basic Auth needs HTTPS. For the certificate side, see our SSL certificate guide.

An .htpasswd file is a plain text file with one line per user: the username and a hash of that user's password. The file holds the hash, not the password itself. Apache recommends keeping it in a directory that visitors cannot reach through the web.

A practical consequence: if you drop the file into public_html, a small misconfiguration lets anyone download it. So keep it in your home directory, outside the web root.

How do you password protect a directory with .htpasswd on Apache?

First, create the password file outside the web root. The command asks you for the password, so you never have to type it into the command line.

htpasswd -c /home/username/.htpasswd example_user

When you add a second user, leave out the -c flag; otherwise you reset the file. Next, add these lines to the .htaccess file of the directory you want to protect:

AuthType Basic
AuthName "Staging"
AuthUserFile "/home/username/.htpasswd"
Require valid-user

These four lines are a trimmed version of the example in the Apache 2.4 documentation. For them to work, the server configuration must allow AllowOverride AuthConfig. You will find the details in the Apache authentication howto.

Write the file path in absolute form. For a strong password you can use our password generator.

If you worry about breaking the configuration, take a backup first. After the change, test one unprotected address and one protected address, so you see that the rule affects only the directory you targeted.

How do you turn on Basic Auth in Nginx?

In Nginx, the directives auth_basic and auth_basic_user_file do the same job. According to the Nginx documentation, auth_basic turns on HTTP Basic authentication and uses your text as the realm. auth_basic_user_file points to the file that holds usernames and password hashes.

location /staging/ {
    auth_basic           "Staging";
    auth_basic_user_file /home/username/.htpasswd;
}

The file format matches Apache. The documentation says hashes from htpasswd or openssl passwd work. It also calls the plain SHA-1 format weak, so choose a modern hash.

However, never reload Nginx without testing the configuration first. A single typo can take the whole site down.

If you do this on a live server and feel unsure, test on a staging copy or leave it to your hosting provider. A faulty rule can lock your entire site behind a 401 or even a 500.

How do you password protect a folder with cPanel Directory Privacy?

If you use cPanel, you can set up the same protection without editing files. According to the cPanel documentation, the Directory Privacy interface changes the .htaccess and .htpasswd files for the chosen folder on your behalf.

1. Open the Directory Privacy tool in cPanel.
2. Browse to the folder you want to protect.
3. Tick the option to password protect this directory and enter a label.
4. Add the authorized user and password, then save.

The label only appears as a name inside .htaccess; it does not rename the folder. Subdirectories inherit the protection of their parent.

One limit matters: the cPanel documentation states plainly that this protection does not cover directories reached through FTP, SFTP or Web Disk. So it locks web access only.

Therefore never keep secret data in a folder protected only this way. Moving sensitive files outside the web root is safer.

Why does the Basic Auth prompt keep coming back?

If the dialog returns although you typed the right password, the server does not accept your input. A few typical causes exist, and you can rule them out in minutes.

• The hash in the password file does not match the password you type.
• The AuthUserFile path is wrong, or the server cannot read the file.
• A reverse proxy or CDN drops the Authorization header before it reaches the origin.
• The address redirects between www and non-www, or between http and https.

The last point surprises many people. A browser usually remembers credentials for a specific origin and realm. If a redirect changes the origin, the browser asks again. So a single canonical address helps both SEO and user experience.

Also, a password with accented letters or special symbols can trigger an encoding mismatch. For diagnosis, try a simple password first, then switch to a strong one.

In the error log, the messages "user not found" and "password mismatch" appear as separate lines. Which one you see tells you whether the problem sits in the file or in the password.

Why do you get a 401 Unauthorized error on WordPress?

On WordPress, a 401 usually comes not from the core but from the layers around it. Three sources appear most often: server-level Basic Auth, REST API authentication, and security or caching plugins.

If you protected a staging site with .htpasswd, WordPress requests to itself can hit that wall too. Scheduled tasks and site health checks belong to those requests. So a warning in the site health screen of a protected staging site should not surprise you.

For the REST API, the WordPress developer documentation lists three routes: cookie authentication with a nonce, Application Passwords and plugins. Without a nonce, the request counts as unauthenticated even if you are logged in. Application Passwords exist since WordPress 5.6 and use Basic Auth over HTTPS.

For example, if a mobile app or an automation tool cannot publish content, check first whether the Application Password belongs to the right user. Then check whether the proxy forwards the Authorization header.

For plugin problems, switching plugins off one by one helps. Before you try this on a live site, prepare your backup strategy.

How do you solve a 401 Unauthorized error in an API or token flow?

In APIs, a 401 almost always means "invalid token". Developers meet these situations most often:

• The token expired and the refresh flow did not run.
• The Authorization header has the wrong format, for example the word Bearer is missing.
• The request hit the wrong environment, such as a test key sent to the live endpoint.
• A clock difference made a signed token invalid.
• An intermediate layer stripped the header.

In that case, read the WWW-Authenticate header of the response. Many APIs name the reason there in a short code. The header points you in the right direction and cuts guesswork.

That said, do not mix up 401 and 403. If the token is valid but lacks rights for the resource, 403 is the right answer. When you build your own API, keeping the two apart makes life much easier for client developers.

Never write keys into code or into a public repository. Use environment variables or a secrets manager instead. For general security risks, read our OWASP Top 10 guide.

How should you choose between 401, 403 and 404 in your own application?

Picking the right code in your own application helps client developers and search engines understand you. The basic rule is to separate missing identity from missing permission.

• If the request sends no credentials or invalid credentials, answer 401 and add WWW-Authenticate.
• When the identity is valid but the rights fall short, answer 403.
• To hide even the existence of a resource, you can answer 404.

The third option is an approach that RFC 9110 describes. For the distinction between these codes, RFC 9110 is the primary source. However, using 404 makes debugging harder, so choose it only when you really need secrecy.

One trap remains: returning a login page with a 200 status and the text "access denied" sends the wrong signal to search engines. For that kind of mistake, see our soft 404 guide.

Do not write passwords, tokens or internal paths into the response body. Keep the error message short and neutral.

Does password protecting a staging site hurt SEO?

Putting a password on a staging site is the most reliable way to hide it from search engines. Google cannot read the content of a page that answers 401. According to Search Central, Google treats all 4xx errors except 429 the same way and tells the next system that the content does not exist.

That logic differs from a noindex tag. For Google to see a noindex rule, the page must be crawlable; if you block it with robots.txt or Google cannot reach it, Google never reads the rule. For the difference, see our noindex and robots.txt comparison.

In practice, the most solid setup for staging is this: add a password or an IP restriction, do not publish the sitemap, and put "remove protection" on your launch checklist. A forgotten password locks your live site against Googlebot.

The reverse also holds. A noindex tag or a robots.txt rule that travels to production can remove your pages from search results. So after every release, check the status code and tags of the home page. For a technical SEO review, see our SEO consulting service.

Which is better for staging: Basic Auth, an IP restriction or a VPN?

The right method depends on your team size and your test flow. None is perfect alone, so a short comparison makes the choice easier.

For a small team, Basic Auth plus HTTPS is usually enough. However, if you share a design for client approval, send the password through a separate channel instead of the same email.

Do not add the password file or access details to a code repository. Copying real customer data to a test site is another risk; work with sample data whenever possible.

What does a 401 page warning in Search Console mean?

Search Console shows in the page indexing report that Googlebot ran into an authorization request on a page. According to the Google help page, the warning "Submitted URL returns unauthorized request (401)" means the page was blocked to Googlebot by a request for authorization.

The fix depends on the purpose of the page:

• If the page should be public, remove the authentication.
• If the page is truly private, remove it from the sitemap and do not submit it.
• If you want Googlebot inside, grant access after verifying its identity.

After the fix, run the live test in the URL Inspection tool and request validation. If you do not know how to read the report, our Search Console guide and our article on unindexed pages help.

Do not skip one point: if a page shows up in the list only because it is private, there is no problem. The real danger is when pages you want indexed appear in that list.

What happens if robots.txt returns a 401?

You may face a surprising result. According to Google documentation, Google crawlers treat all 4xx errors except 429 as if a valid robots.txt file did not exist. So if your robots.txt answers 401, Google assumes there are no crawl restrictions.

That makes "hiding" protected areas through robots.txt dangerous. A crawler that cannot read the file ignores every rule. For that reason, leave privacy to real access control, not to robots.txt.

The opposite case also confuses people: if robots.txt returns a 5xx error, Google pauses crawling for the first 12 hours and then uses the last good version. The two cases differ, so verify that the file always opens with a 200.

To prepare the file safely, use our robots.txt generator. For common mistakes, read our article on robots.txt mistakes.

How do 401 pages affect monitoring and broken link tools?

A protected address looks like an error to automated tools. Uptime monitors usually count every answer other than 200 as an outage. As a result, you may get a "site down" alert every night even though the server works exactly as designed.

The same happens with broken link scans. A crawler tool can flag a link that answers 401 as broken. So when you read the results, first ask whether the page is protected on purpose. Our broken link checker lists such addresses too.

If your site seems down, first check whether a real outage exists. For that, you can use the is it down tool, which shows how an address responds from the outside.

The fix is simple: add credentials to the monitoring tool or leave the protected area out of monitoring. This decision spares your team from alert fatigue.

Is it safe to let Googlebot past authentication?

Sometimes protected pages still need crawling. In that case you can give Googlebot special access, but you must be careful. Do not trust the user agent text, because anyone can fake the same text.

Google documentation offers two ways to verify: confirm the domain with a reverse DNS lookup, or match the address against the IP ranges Google publishes. The page does not decide for you whether to let Googlebot past authentication. It only explains how to tell that a request really comes from Google.

Moreover, for most businesses this is unnecessary. Content behind authentication should not appear in search results anyway. If you want the content searchable, the cleanest solution is to move it to a public page.

Special access rules can lock your site or open it to the wrong people when you write them badly. Therefore, if you feel unsure, do not make this change yourself.

What should you collect when your team or client reports a 401?

The message "I cannot get into the site" alone does not suffice for a diagnosis. A few lines of the right information prevent hours of back and forth. So add the following fields to your report form or support template.

• Full address: It shows on which page or subdomain the error appears.
• Date and time: It helps you find the matching server log line.
• Screenshot: It shows whether the dialog comes from your site or from the browser.
• Network type: It tells you whether the visitor used an office, home or mobile connection.
• Latest change: It shows whether a new plugin, panel setting or deployment went live.

If you work with a technical person, ask for the command line output too. The first lines of the curl command above give the status code and the headers in one go.

That way the support process works from evidence instead of trial and error. The habit saves time inside your team and when you write to your hosting provider.

When should you leave the 401 problem to your hosting provider?

You do not have to solve every 401 yourself. In some situations the right decision is to open a support ticket.

• You use shared hosting and cannot reach the server configuration.
• The problem started across the whole site and you do not know the latest change.
• A WAF, CDN or load balancer enforces the rule.
• You feel unsure about editing an Apache or Nginx file on a live server.
• You suspect an attack or unauthorized access.

In the ticket, share the address, the time of the error, the status code and the WWW-Authenticate header. That way the provider diagnoses the issue without reproducing it. To judge support quality when you pick a host, use our hosting selection guide.

Breaking a server setting costs more than the error itself. So do not try a command on the live server if you do not know what it does.

What is a checklist to prevent a 401 Unauthorized error?

The list below takes five minutes before each release and prevents most surprise 401 errors.

1. Confirm that nobody copied the staging protection to the live environment.
2. Test that the home page, robots.txt and sitemap addresses answer 200.
3. List every path that uses Basic Auth in one place.
4. Keep password files outside the web root and use HTTPS only.
5. Document token lifetimes and refresh flows for your APIs.
6. Review the Search Console report every week.

Also, check topics such as speed and accessibility in the same release flow. For example, you can test your certificate quickly with our SSL checker.

If you want to build the technical foundation of your site as a whole, look at our web design service. We do not run hosting; however, we can help you make the right infrastructure decision.