Blocked due to unauthorized request (401): pages behind a login
Last updated: 2026-10-30
This status means the server answered Googlebot with 401 Unauthorized, asking for credentials Googlebot does not have. If the page is private, that is correct and the page stays out of Google. If it should be public, remove the authorization requirement or, if you must keep it, let verified Googlebot requests through.
Exact label in Search Console: Blocked due to unauthorized request (401)
What it means
Google's Page indexing help says the page was blocked to Googlebot by a request for authorization (a 401 response). If you want Googlebot to index the page, either remove the authorization requirement for it or allow Googlebot to access it by verifying its identity. Google suggests checking the page in an incognito window to see what a signed-out visitor gets.
Google does not use the content of URLs that return 4xx codes and does not index them, and pages that were indexed and start returning 401 are removed over time. Google also says not to use 401 or 403 to limit crawling, because these codes have no effect on crawl rate.
Is it a problem?
Not for private areas such as account pages, admin screens, intranets or staging sites behind HTTP authentication; keeping them out of Google is the point. It is a problem when public pages return 401, for example when password protection from staging stays on after launch, or when a whole section ends up behind a login by mistake.
Common causes
Private pages linked publicly
Account, admin or member URLs that Google discovered through links. Expected.
Staging protection left on
HTTP basic authentication or a hosting password still active after the site went live.
Section-wide auth rules
A server or CDN rule that requires a login for a path pattern that also covers public pages.
Pages backed by an authenticated API
Pages that return 401 to signed-out requests instead of showing a public version.
How to fix it
- Check what a signed-out visitor gets. Open the URL in an incognito window, as Google suggests. If you are asked to log in, Googlebot is too.
- Remove authentication from public pages. Turn off password protection for the live site, or narrow the auth rule so it only covers private paths.
- Allow verified Googlebot only if you must. If content has to stay gated for people but visible to Google, verify Googlebot by reverse DNS or Google's published IP ranges before letting it in, and read Google's spam policy on cloaking and paywalls first.
- Keep private pages private. For URLs that should never be in Google, a 401 is fine. Remove links to them from public pages and from your sitemap so they stop showing up.
- Test, request indexing and validate. Run Test live URL on pages you opened up, request indexing for the most important ones and click Validate fix for the group.
Check it with GSC Magic
gsc_inspect_urls_batch shows the page fetch state Google recorded for each URL, so your assistant can list every URL blocked with a 401 and separate private paths from public ones by directory. report_index_health flags any 401 inside your sitemap, which should list only public pages.
Prompts to copy
Inspect these URLs and list every one blocked due to an unauthorized request (401), grouped by directory.
Run an index health check on my sitemap and tell me whether any listed URL returns 401 or 403 to Google.
We just removed the login from these pages. Inspect them and tell me which ones Google still reports as blocked by 401.
Guides on the blog
- Google Search Console not indexed: causes and fixes
- Sitemap Submitted but Pages Not Indexed? Here's What to Check
Related statuses
Blocked due to access forbidden (403) This status means your server returned 403 Forbidden to Googlebot. Google points out that Googlebot never sends credentials, so a 403 to Googlebot is usually returned incorrectly. If the page should be in Google, find the firewall, CDN or server rule that blocks it and allow verified Googlebot.
Blocked due to other 4xx issue This status means Googlebot received a 4xx client error that is not one of the codes with their own row, such as 401, 403 or 404. Google gives no further detail, so the first step is to find the exact code your server returned. Then fix how your server handles the request for pages that should be public.
Excluded by 'noindex' tag This status means Google crawled the page, found a noindex rule in a robots meta tag or an X-Robots-Tag HTTP header, and therefore did not index it. If you do not want the page in Google, this is working. If you do, remove the noindex at its source, confirm with Test live URL and request indexing.
Frequently asked questions
Is a 401 a good way to keep pages out of Google?
For private content, yes. Google's removal guidance lists password protection as one way to keep a page out of search results permanently.
Can I give Googlebot a username and password?
No. Googlebot does not log in. Google's guidance is to remove the authorization requirement or allow verified Googlebot requests.
What is the difference between 401 and 403 here?
A 401 asks for credentials. Google says a 403 means credentials were provided but access was denied, and since Googlebot never sends credentials, a 403 to Googlebot is usually returned incorrectly.
Sources
- support.google.com https://support.google.com/webmasters/answer/7440203
- developers.google.com https://developers.google.com/crawling/docs/troubleshooting/http-status-codes
- developers.google.com https://developers.google.com/crawling/docs/crawlers-fetchers/verify-google-requests
- developers.google.com https://developers.google.com/search/docs/crawling-indexing/remove-information
- developers.google.com https://developers.google.com/search/docs/essentials/spam-policies