Search Console Page indexing: Why pages aren't indexed

Blocked due to unauthorized request (401): the fix

Your server asked Googlebot to log in. When that is the right outcome, when it is not, and how to let Google reach a page that should be public.

Your server answered Googlebot with 401 Unauthorized, asking for a login, so Google could not index the page. If the URL is private or a staging site, that is the correct outcome. If it should be public, remove the authentication requirement for that URL or allow verified Googlebot, then validate the fix.

What "Blocked due to unauthorized request (401)" means

Google: "The page was blocked to Googlebot by a request for authorization (401 response)." Googlebot does not log in, so any page behind HTTP authentication or a login that answers 401 is unreadable to it. Google treats a 401 like other 4xx codes: it does not index the URL, and removes it from the index if it was indexed before.

Is it a problem?

Depends on the URL

Usually not, if the URLs are private: account pages, admin screens, a password-protected staging site. Requiring a login is one of the two ways Google suggests for keeping a page out of Search. It is a problem when public pages are on the list, or when the list suddenly grows.

Causes, most likely first

A password-protected staging or preview site that Google found through a link. That is the protection working.
HTTP authentication left on a directory or a host after launch.
A membership or paywall plugin answering 401 to everyone who is not signed in, including on pages meant to be public.
Public pages linking to account, cart or admin URLs that require a login.

How to confirm it

Open the URL in a private window, as Google suggests. If you are asked to log in, Googlebot is too.
Run the indexability checker to see the 401, and the crawler versus browser checker to see whether Googlebot and a browser get the same answer.
Run a live test in URL Inspection to see the status Google gets now.

Indexability checker Crawler versus browser checker

How to fix it

If the URL is private, leave it. Take it out of your sitemap and, where it makes sense, stop linking to it from public pages.
If the URL should be public, remove the authentication requirement for that path in the server, hosting or plugin settings.
If the content must stay behind a login for people but be indexed, Google's documented route is to let Googlebot through after verifying it by reverse DNS or against Google's published IP ranges. The user agent alone can be faked.
Re-run the checker until the URL returns 200 without credentials, then click Validate fix.

How long recovery takes

Google stops using a URL that keeps returning a 4xx and crawls it less and less often. Once the page returns 200 again it has to be recrawled, which Google says can take "anywhere from a few days to a few weeks". Request indexing in URL Inspection asks for one URL sooner but does not guarantee it.

After a fix, Validate fix on the issue asks Google to recheck the affected URLs. Google says validation "typically takes up to about two weeks, but in some cases can take much longer". Without it, the count still updates as Google recrawls, and an issue leaves the table once 90 days pass with no instance.

Would monitoring have caught it?

A monitored URL that starts returning 401 after returning 2xx or 3xx is a critical change, re-checked after 60 seconds before it alerts. That catches authentication switched on across a host by a deploy. It sees what our crawler is served, not what Googlebot is served.

stillindexed checks each monitored URL every 30 minutes on Starter and every 15 minutes on Agency, so the change is found on the next check and confirmed before it alerts, rather than waiting for this report to update.

See what monitoring covers

A staging or preview site indexed by Google, platform by platform

Sources

Every claim above about how Google behaves is from Google's own documentation, read on 2026-10-06. If Google has changed a page since, Google's page wins and we would like to know.