How do you fix “Blocked due to unauthorized request (401)” in Search Console?

What the error means

A 401 response means the server requires authentication for the requested URL. Googlebot does not sign in to ordinary site accounts, so it cannot crawl a page that is protected by a login or credentials. This differs from a 403 response, which means access is refused even if the requester is identified.

Why Google rejects it

The affected URL may be behind a site-wide password, staging protection, a server-level authentication rule, or a plugin or app that now requires a session. Sometimes only one route or asset is protected because of a changed hosting or security setting.

How to fix it

1. Open the exact URL in a private window where you are not logged in. Confirm whether it asks for a password or returns 401, and check whether the issue affects one URL or the whole site.
2. If the page is meant to appear in Search, remove the unintended authentication requirement for that public route. Review recent hosting, firewall, maintenance, and access-control changes.
3. If the page is intentionally private, keep it protected and remove it from public navigation and the sitemap. Do not expose private content just to clear a Search Console status.
4. Check that the fix applies to Googlebot’s requested hostname and URL path, including redirects and any required page resources. Do not rely on a browser session that has already authenticated.
5. Run URL Inspection’s live test after the change. If it can fetch the page, request indexing for important URLs and monitor the Page indexing report as Google recrawls.

Common causes

The public site is behind staging authentication

A hosting control panel or deployment setup may add HTTP Basic Authentication to an entire site or directory. Owners with saved credentials do not see the restriction, but Googlebot and anonymous shoppers receive 401. Check recent staging or launch changes if multiple unrelated URLs fail together.

A page is deliberately limited to signed-in customers

Membership, wholesale, or B2B settings can require a customer account for a product or page. That is suitable for private material, but it means Google cannot fetch the protected content. Decide whether the page is intended to be public before changing the access rule.

An authentication rule covers a broader path than intended

A server directive, reverse proxy, or application middleware may protect a shared path such as /products/ or /blog/ by mistake. The 401 pattern often follows one directory or URL prefix. Compare working and failing paths and inspect the configuration scope.

A security plugin or app requires a session

A plugin can redirect anonymous visitors into an account flow or return an authentication challenge for a route that should be public. The rule may affect a page template, API-backed product content, or the entire storefront. Test in a fresh private session, not an already authenticated browser.

A password page or maintenance mode is still active

Some launch modes replace the public site with a password gate or access prompt. A crawler that does not have a customer password receives an authentication response and cannot inspect the page. Confirm whether the whole host or only the route is restricted before changing it.

Fix it on your platform

On Shopify

1. If the entire storefront is returning a password page, check the store's public/private access mode under Online Store; Shopify's help documents the access setting and private mode preferences under Online Store > Preferences.
2. For a specific product, check that its page is meant to be public and that no membership, wholesale, or password app requires a customer session to render it.
3. Open the page on the primary domain in a private browser and confirm the actual response, not only the password page's customized message.
4. If the product should remain private, keep the restriction and remove it from public links and any sitemap/feed that is meant for public pages.

On WooCommerce

1. Check the product's Publish panel for Public, Password protected, or Private visibility; WooCommerce documents these as distinct visibility states.
2. Review membership, wholesale, maintenance, and security plugins for guest restrictions on the affected route. If a product is public, remove only the unintended access rule rather than disabling site security wholesale.
3. If HTTP Basic Authentication is configured by the host, web server, or staging plugin, verify whether it applies to the production hostname and remove it only from routes that should be public.
4. Test the URL after clearing caches and without a WordPress login cookie.

On other platforms

1. Wix: check whether the page or site is restricted to members or password holders; publish public content with the intended audience setting.
2. Squarespace: review page or site password protection and member-area settings for URLs expected to be crawlable.
3. BigCommerce or custom hosting: inspect storefront visibility, customer-group rules, reverse-proxy authentication, and any staging-level password protection for the exact route.
4. For any platform, keep access controls on content that is genuinely private; do not make customer-only information public to clear an indexing report.

How to confirm it is fixed

1. Request the affected URL in a fresh private browser session and confirm it no longer prompts for credentials if the page is intended to be public.
2. Run Shipwork's bulk status check to inspect the public HTTP status for affected URLs without your browser login.
3. Use Search Console URL Inspection's live test and confirm Page fetch is successful. If access is intentionally restricted, leave the restriction in place and exclude the URL from public sitemaps and links.
4. Check neighboring URLs in the same directory to make sure a broad rule did not expose private paths or continue blocking public pages.

A worked example

Hypothetical case: a small furniture brand launches a redesigned WooCommerce store on a host that previously used Basic Authentication for staging. The owner can open every product because the browser has cached the credentials. Search Console shows Blocked due to unauthorized request (401) for product URLs, and an external request receives an authentication challenge before WordPress loads. The host removes the staging rule from the production virtual host, while leaving the staging hostname protected. The owner tests a product in a private browser and with URL Inspection's live test; both can now fetch the public page. Private admin and staging access remain protected.

Other errors like this