Blocked due to unauthorized request (401) is the Page indexing status that means Googlebot knocked and was asked for credentials it does not have. The server answered with HTTP 401, a demand for authentication, and Google does not log in to websites. No fetch, no content, no indexing.
Yesterday I wrote about the 403 version of this status, and the two are siblings with one meaningful difference. A 403 says “I know who you are and you may not enter”. A 401 says “tell me who you are first”. In practice both end the same way for indexing, but the 401 points you at a much shorter list of suspects, because something on your site is actively running an authentication challenge.
What Google says to do about it
The help entry for the Page indexing report gives two options: remove the authorization requirement for the page, or allow Googlebot to access the page by verifying its identity. It also offers the simplest diagnostic in the whole report: visit the page in an incognito window. Logged out of everything, you are in the same position as Googlebot, and if the browser greets you with a password prompt or a login redirect, the mystery is solved.
That second option, letting verified Googlebot through a wall your visitors still hit, deserves a caution the help entry does not spell out. Serving the crawler content that users cannot see is the definition of cloaking, and the safe version of “verify Googlebot’s identity” is for firewall allowlisting, not for publishing members-only content to the index. If a page is worth indexing, make it public; the middle path is a policy risk I do not put clients on.
The one thing never to do with a 401
Google’s robots.txt specification carries a line that belongs in this post because it names a real practice: do not use 401 and 403 status codes for limiting the crawl rate. All 4xx codes except 429 have no effect on crawl rate at all, so the wall does not even slow Googlebot down; it just converts every crawl into a blocked fetch. And if the 401 lands on the robots.txt file itself, the spec says 4xx responses there are treated as if no robots.txt existed, meaning the auth wall on one file silently removes every crawl restriction you thought you had.
What I actually find behind a 401
The suspect list, in the order I check it on client sites:
- A staging site that made it into a property. HTTP basic auth on a staging subdomain is good practice, and a staging subdomain in your Search Console property, your sitemap, or your internal links is how good practice becomes a report full of 401s. The fix is not to remove the auth; it is to stop advertising staging URLs to Google anywhere.
- A members area doing its job. Account pages, order histories, saved lists. These belong behind the wall, and their 401s are the system working. This status is only a to-do list for URLs that should be public.
- Security plugins and hosts protecting wp-admin aggressively. Some WordPress hardening setups challenge anything that touches admin paths, including paths that templates leak into public pages. The 401 is fine; the internal links pointing at protected URLs are the bug.
- A CDN or WAF rule challenging bots. Managed challenges that fire on crawler traffic sometimes answer with 401 rather than 403. Same diagnosis as the 403 case: the page works in your browser and fails for the one visitor the report measures. Verify real Googlebot traffic in the logs before allowlisting anything, since the user agent string is trivially fakeable.
The incognito test sorts cases one and two immediately. Cases three and four need the URL Inspection live test, because the challenge only fires on traffic that looks automated, and your incognito window does not.
When to worry
Count and contents, same as every status in this family. A stable set of 401s on genuinely private URLs is correct behaviour and needs nothing. Two patterns are worth a real look: a sudden jump in the count after a security plugin update or a WAF rule change, because something new is challenging traffic it should not; and any URL in this status that you expected to earn traffic, because it is earning none and will not until the wall comes down. If a previously public page has been sitting on a 401 for weeks, remember that its indexed copy does not last forever; the removal mechanics I covered in pages dropped out of the Google index apply here too. The full family tree of these statuses lives in every Search Console indexing status.
Sources
- Google Search Console Help, Page indexing report, the Blocked due to unauthorized request (401) status and its incognito-mode check, checked 2 September 2026
- Google Search Central, how Google interprets the robots.txt specification, for the instruction not to use 401 and 403 for crawl-rate limiting and the 4xx handling of robots.txt itself, checked 2 September 2026
- Google crawling infrastructure documentation, how HTTP status codes affect Google’s crawlers, for 429 being the one 4xx treated as a server error
- Google Search Central, verifying Googlebot, for confirming crawler identity before firewall changes