Blocked Due to Unauthorized Request (401): What It Means + How to Fix It

A 401 means your server asked Googlebot to prove who it is, and Googlebot — which never carries credentials of any kind — couldn't answer. The server isn't refusing outright the way a 403 does; it's gating the page behind a login it expects a legitimate visitor to pass through. Google simply can't pass through it, ever, no matter how many times it tries.

That makes the diagnosis simple: this status only ever means one of two things. Either the page is supposed to require login and this is completely expected, or an auth requirement got left on (or misconfigured) somewhere it shouldn't be.

First, confirm what's actually gating it

Open Pages → Why pages aren't indexed, click into "Blocked due to unauthorized request (401)," and pull an affected URL. Visit it yourself in an incognito window, fully logged out, with no saved credentials.

If you see a login form, a browser-native Basic Auth prompt, or a "password protected" message, that confirms the page really is gated — you're just deciding next whether that's intentional. Run URL Inspection → Test live URL to confirm what Google is currently getting, since auth settings (especially staging-site protection) get toggled on and off outside of any deliberate SEO decision.

Find your cause

1. The page is intentionally private

Account pages, internal dashboards, staff tools, or anything meant only for logged-in users. This is working exactly as intended.

Tell: the page requires login for real users too, and you'd never want it showing up in a Google search result anyway.

2. Staging-site protection got left on after launch

A very common one. Sites in development are often password-protected site-wide so the public and search engines can't see unfinished work. When the site goes live, that protection sometimes doesn't get removed.

Tell: it's not one page — it's the entire site, or a large swath of it, all 401ing. Check your host, CMS, or CDN for a site-wide "password protect" or "coming soon" toggle.

3. .htaccess Basic Auth added for testing, never removed

Someone added server-level password protection to test a feature or restrict access temporarily, and the directive is still sitting in the server config.

Tell: the browser shows a native (unstyled) username/password prompt, and the page is one that logically should be public.

4. A CDN, cache, or reverse-proxy layer is forwarding a bad auth header

Less common, but real: a caching layer or proxy in front of your app is adding or mishandling an Authorization header in a way that triggers a 401 that your actual application never intended.

Tell: the auth requirement doesn't show up anywhere in your application or CMS settings, only at the infrastructure layer — check CDN/proxy config, not just the CMS.

The fix

1. Decide first: should this page require login?

   If yes (cause 1), stop here — this status is correct and expected, nothing to fix. If no, work through the causes below to find where the auth requirement is actually being applied.

2. Turn off site-wide staging protection

   For leftover staging protection (cause 2): find the toggle in your host's dashboard, CMS settings, or CDN config and disable it for the production environment. Double-check it's specifically off for production — some platforms let you keep protection on for a staging subdomain while your live domain is public, which is the setup you want going forward.

3. Remove the stale Basic Auth rule

   For leftover .htaccess/server-level auth (cause 3): locate the AuthType/AuthUserFile directive (or equivalent in your hosting panel or nginx config) scoped to the affected path and remove it. Confirm you're not accidentally removing protection from something that should stay gated in the same file.

4. Fix the proxy or CDN layer

   For a misconfigured header at the CDN/proxy level (cause 4): check your CDN or reverse-proxy rules for anything adding or forwarding an Authorization header to paths that shouldn't have it, and scope the rule correctly.

5. Re-test before requesting indexing

   After removing the auth requirement, re-run URL Inspection → Test live URL and confirm a clean 200 with no credential prompt. Then click Request indexing.

Platform notes

• WordPress — check both Settings → Reading (a site-wide "discourage search engines" toggle is a different problem, but often set alongside auth during staging) and your host's staging/production environment settings — many managed WordPress hosts (WP Engine, Kinsta, Flywheel) auto-password-protect staging environments and require an explicit action to disable it on go-live.
• Shopify — check Online Store → Preferences for "Restrict access to visitors" (password protection), commonly left on from pre-launch. This is the single most common Shopify cause of a whole-storefront 401/403.
• Next.js (React) — check middleware (middleware.ts) for Basic Auth logic sometimes added to protect preview deployments, and confirm it's scoped to preview/staging environments only, not production. Also check your hosting platform's own password-protection feature for preview URLs (common on Vercel) isn't accidentally applied to the production domain.
• Webflow — Project Settings → Site access has a password-protection toggle used for pre-launch sites; confirm it's switched off for the live domain. Note it can be set independently for the staging .webflow.io domain versus a connected custom domain — check the one that's actually live.

How to verify it's fixed

1. Incognito browser check — load the URL logged out, no saved credentials. You want the actual content, no prompt.
2. URL Inspection → Test live URL — confirms what Googlebot itself receives right now.
3. Pages report — after requesting indexing, watch for the URL to clear from this status. Reprocessing takes time — days to a few weeks is typical, and Google doesn't guarantee a fixed timeline — so a clean live test is your best near-term signal that the fix worked.

When to ignore it

Any page that should genuinely require login — account settings, member dashboards, internal tools — belongs behind auth, and this status is simply confirming that's working. There's nothing to chase here; move on.