Blocked Due to Unauthorized Request (401): Fix It

Blocked due to unauthorized request (401): pages Googlebot cannot log in to

A 401 response means "authenticate first". Googlebot never logs in, so every URL that answers 401 stays out of the index. If the page should be public, remove the password layer in front of it. If it should be private, the status is correct and the job is to stop linking to it.

Search Console lists these under "Why pages aren't indexed". The number matters less than which URLs are in it, so open the row and read the examples before deciding anything.

Updated September 30, 2026By the Hydrogen SEO team

Where 401s come from on a WordPress site

WordPress itself rarely returns 401 for pages. A password-protected post answers 200 and shows a password form, and a private post answers 404 to logged-out visitors. So a 401 on a normal page usually comes from a layer outside the content:

HTTP basic authentication on the server. A .htpasswd rule on Apache or auth_basic on nginx, often added to protect a site before launch and never removed, or applied to a directory that later gained public content.
Host-level "password protection" or "site lock" toggles in a hosting control panel, which do the same thing.
A staging rule copied to production. Configuration synced from staging along with the files.
REST API endpoints. WordPress answers 401 with the error code rest_not_logged_in for endpoints that need a user, such as /wp-json/wp/v2/users/me. These URLs are discoverable from page source, so crawlers request them.
Membership and LMS plugins configured to send a 401 for restricted lessons instead of redirecting to a login page.

Confirm what the server sends

code

curl -sI https://example.com/members/handbook/ | head -n 5

A basic-auth 401 includes a WWW-Authenticate: Basic realm="..." header, which identifies the server layer as the source. A 401 with a JSON body and rest_not_logged_in is the REST API. A 401 that appears only with a Googlebot user agent, and not in your browser, is a security rule; treat it like a 403 block.

In Search Console, URL Inspection's live test shows the same status under Page fetch.

If the page should be public

Remove the authentication rule from .htaccess, the nginx server block or the hosting panel. Check parent directories too, because Apache applies rules from every level above the file.
Reload the URL in a private window. You should get the page with no browser login prompt.
Purge any CDN cache, then request indexing for the URL.

If only part of the site should be protected, scope the rule to that path and make sure public assets the pages need, such as stylesheets and images, are not behind it.

If the page should stay private

Leave the 401 in place. It is an accurate answer and it keeps the content out of search. What you can tidy is how crawlers found the URL:

Remove it from the XML sitemap. Hydrogen SEO leaves password-protected and non-public content out of its sitemap automatically; a hand-built or third-party sitemap may not.
Remove or restrict internal links that anonymous visitors cannot use anyway.
For REST API URLs, nothing needs fixing. They are endpoints, not pages. If you would like fewer of them discovered, Hydrogen SEO's Crawl cleanup has a Remove REST API links switch that takes the API link out of the head and the Link header while leaving the API working; see crawl cleanup.

Do not serve Googlebot the full content while showing everyone else a login wall unless you implement paywalled-content structured data properly; showing crawlers something users cannot get is cloaking.

Verifying

For pages you opened up, the live test in URL Inspection should return a successful fetch, and Validate fix on the report row will clear them as they are recrawled. For pages you kept private, success is the URL count shrinking over time as Google stops finding links to them. A stable, small number of private URLs in this row is not a problem to solve.

Common questions

Does a 401 count against my site?

No. It prevents those specific URLs being indexed and nothing more. It becomes a problem only when the URLs were supposed to be public.

Can I let Googlebot through the password?

You can exempt verified Googlebot addresses at the server, but then Google indexes content searchers cannot open, which leads to poor results and may be treated as cloaking. Publish a public summary page instead.

Why are wp-json URLs in this report?

WordPress advertises its REST API in the page head, and some endpoints require a logged-in user. Googlebot requests them and gets 401. It is expected behaviour.

Is 401 better than noindex for private pages?

For genuinely private content, yes. A 401 stops crawlers and people. Noindex only keeps a publicly readable page out of results.