Skip to content
Rescue 404
Rescue

Server Errors

401 Unauthorized

Intermediate Risk: medium

Last reviewed

Hosting access often needed Database access usually not needed

Direct answer

401

A 401 Unauthorized means the server requires valid credentials to access this resource and either none were sent or the ones sent were rejected — it is a login/authentication failure, not a permissions block like 403 or a missing page like 404. Fix the credentials, the authentication method, or the rule demanding them, depending on where the request is failing.

HTTP 401 tells the client it must authenticate before it can get the resource. On WordPress sites this shows up as REST API and admin-ajax failures, staging sites protected by HTTP basic auth, broken API keys on integrations, or security plugins demanding credentials the visitor’s request never supplied. This guide separates real login problems from misconfigured auth rules so you fix the right layer.

Intermediate

Key facts

Verifiable numbers and definitions — each claim links to its source.

  • HTTP 401 Unauthorized means the request lacked valid authentication credentials for the requested resource. (401 Unauthorized)
  • A 401 response includes a WWW-Authenticate header that names the authentication scheme the client should use. (WWW-Authenticate header)
  • MDN distinguishes 401 from 403: 403 is returned when credentials are valid but the client still lacks permission. (401 Unauthorized)

What the error means

HTTP 401 specifically means “you need to authenticate, and either you haven’t or your credentials were rejected.” The server response should include a `WWW-Authenticate` header naming the expected authentication scheme (Basic, Bearer, Digest, etc.), which is what tells the browser to pop up a login prompt for HTTP basic auth, or tells an API client which token format is expected. This differs from 403 Forbidden, where the server recognizes who you are (or doesn’t need to) but denies access regardless, and from 404, where the resource itself is reported as not found. On WordPress, 401 most often appears on staging/dev environments with HTTP basic auth enabled, on the REST API or admin-ajax when an application password or API key is missing or revoked, or when a security plugin or reverse proxy is enforcing its own authentication layer in front of the site.

Common symptoms

  • Browser shows a native login prompt (username/password dialog) before the page loads
  • Visiting the page directly returns “401 Unauthorized” with no themed WordPress error page
  • REST API requests (`/wp-json/...`) or admin-ajax calls fail with 401 while the rest of the site loads normally
  • A third-party integration (mobile app, headless frontend, webhook) suddenly stops authenticating
  • The problem appeared right after rotating an API key, application password, or changing a plugin’s auth settings
  • Staging or development URLs are affected but the production domain is not (or vice versa)
  • DevTools Network tab confirms status 401 (not 403 or 404) on the failing request

Most likely causes

  1. 01 HTTP basic authentication enabled at the server or hosting-panel level (common on staging sites) with no or wrong credentials supplied
  2. 02 An expired, revoked, or mistyped WordPress application password used for REST API or XML-RPC access
  3. 03 An API key, bearer token, or OAuth credential that expired, was rotated, or was never sent by the client
  4. 04 A security plugin or firewall enforcing login-wall rules on specific paths (REST routes, admin-ajax, uploads)
  5. 05 A reverse proxy, load balancer, or CDN edge rule requiring authentication headers the origin does not expect (or vice versa)
  6. 06 .htaccess or nginx `auth_basic` configuration left over from a staging setup that migrated to production
  7. 07 Session or cookie authentication expiring mid-request for a logged-in area that expects a fresh token

What changed before the problem started

  • HTTP basic auth was enabled (often automatically) when a staging site was created or cloned
  • An API key, application password, or OAuth token was rotated, revoked, or expired
  • A security plugin was installed or its REST API / XML-RPC restriction settings were tightened
  • A migration copied staging `.htaccess` or server auth rules into the production environment
  • A third-party integration’s credentials changed on their end without updating your site’s configuration
  • A CDN, proxy, or firewall rule requiring authentication headers was added in front of the origin

Troubleshooting steps

  1. 01

    Confirm 401 and identify exactly which request fails

    In DevTools → Network, confirm the status is really 401 and note the specific URL — the whole site, just `/wp-json/`, just `admin-ajax.php`, or a single third-party endpoint. Scope tells you immediately whether this is a sitewide auth wall or a narrow API/integration issue.

  2. 02

    Check for HTTP basic authentication on staging or dev sites

    If a login dialog pops up in the browser (not a WordPress-styled page), basic auth is enabled at the server level — common on staging environments created by hosts or migration tools. Find the credentials in your host’s staging panel, or remove the basic-auth rule if the site is meant to be public now.

  3. 03

    Regenerate the application password or API key

    If a REST API integration, mobile app, or headless frontend fails, go to Users → Profile → Application Passwords in wp-admin and generate a fresh one, then update it wherever it is stored (environment variables, integration settings). Revoked or expired credentials are one of the most common 401 causes on active WordPress sites.

  4. 04

    Disable security-plugin REST/XML-RPC restrictions temporarily

    If a security or firewall plugin is blocking REST routes or `admin-ajax.php` for unauthenticated or third-party requests, temporarily disable that specific restriction (not the whole plugin) and retest. Re-enable it with an allowlist for the legitimate integration once confirmed.

  5. 05

    Review `.htaccess` or nginx config for leftover auth rules

    Search for `AuthType`, `AuthUserFile`, or `auth_basic` directives in `.htaccess` or the server block. A rule copied from staging during a migration can silently lock a production path. Remove or scope it correctly, then reload/restart the web server if needed.

  6. 06

    Verify the credentials or token being sent are actually correct

    For API integrations, double-check the exact header format expected (`Authorization: Basic ...` vs `Bearer ...`), and confirm there is no extra whitespace, wrong encoding, or stale cached credential in the client making the request.

When to stop troubleshooting

Escalate if you cannot find where authentication is being enforced (host-level, CDN, plugin, or application code), a production integration handling payments or customer data is failing and you cannot safely rotate credentials yourself, or removing an auth rule risks exposing a staging environment that should stay private. Do not disable authentication entirely on a site that depends on it just to make the error disappear.

Information to collect before requesting help

  • 01 Exact URL or endpoint returning 401 and whether it affects the whole site or one integration
  • 02 Status code and response headers from DevTools (confirm `WWW-Authenticate` presence/value)
  • 03 Whether a browser login prompt appears (basic auth) or the failure is API-only
  • 04 Recent API key, application password, or OAuth token changes
  • 05 Recent security plugin, `.htaccess`, or CDN/proxy configuration changes
  • 06 Whether the issue is isolated to staging, production, or both
  • 07 Which third-party service or client is making the failing request, if applicable

How a professional repairs the problem

A technician confirms the exact layer issuing the 401 (server, CDN, plugin, or application), verifies whether it is a legitimate credential problem or a misapplied auth rule, rotates and re-distributes credentials safely across all consumers, removes or properly scopes leftover staging-style auth rules, and confirms both browser and API access work as expected afterward.

Frequently asked questions

Is 401 the same as 403 Forbidden? +
No. 401 means you need to authenticate — no valid credentials were provided. 403 means the server already knows who you are (or doesn’t care) and denies access regardless of credentials. A 401 response should also include a `WWW-Authenticate` header telling the client how to authenticate.
Why does a login popup appear in my browser instead of a WordPress page? +
That native browser dialog means HTTP basic authentication is enforced at the server level, before WordPress ever runs. It is common on staging sites. Find the credentials in your hosting panel, or remove the rule if the site should be public.
Will regenerating an application password break other integrations? +
Only the integrations still using the old, revoked password will fail — each application password is independent. Update the specific integration with the new credential and others are unaffected.
Can a security plugin cause 401 on the REST API? +
Yes. Plugins that lock down `/wp-json/` or `admin-ajax.php` for unauthenticated requests can return 401 to legitimate third-party integrations, mobile apps, or headless frontends. Check the plugin’s API restriction settings and allowlist the specific consumer.
Why did my API integration suddenly get a 401 with no code changes on my end? +
The credential may have expired or been rotated on the third-party service’s side, or a token’s validity window simply ran out. Confirm the current key or token is still valid directly with the provider before assuming your site’s code is at fault.
How is 401 different from a WordPress login redirect loop? +
A redirect loop keeps sending you back to `wp-login.php` without an explicit error status — usually a cookie or URL mismatch. A 401 is a distinct HTTP status returned by the server or an API endpoint, typically outside the normal wp-admin login flow.

Repair dispatch

Still Need Help Fixing Your Website?

If you are not comfortable editing website files, changing server settings, repairing a database, or troubleshooting a live website, professional help may prevent additional damage or downtime. We will review the problem before accepting the repair.

  • You will receive a clear explanation of the likely cause.
  • We will tell you if the issue falls outside our repair scope.
  • No additional work will be performed without approval.
  • A backup should be created whenever access and website condition allow it.
Emergency repair Request diagnosis

Do not share passwords through an unencrypted contact form — use Password Pusher (self-destructing link). Prefer a dedicated Rescue 404 admin account, not your personal owner login; if you cannot create one yet, we will add ours after repair.

Written by Josh

Last reviewed

Platform note: Full rescue available for WordPress and self-hosted sites. Wix, Squarespace, Webflow, Weebly, and similar closed builders have very limited backend access — fixes may not be possible. I will tell you honestly before we start.