Why your server answers Googlebot with 403 Forbidden while the page loads for you

What the error means

When Google requested the page, your server or a security layer in front of it returned HTTP 403 Forbidden. Google could not read the page, so it was not indexed.

Why Google rejects it

A 403 tells a crawler it is not allowed in. Firewalls, bot protection, country blocks, hotlink rules and security plugins issue it to visitors they distrust. Your browser passes those checks; Googlebot, coming from a data centre without cookies, often does not.

How to fix it

1. Test the URL from outside your network and with URL Inspection's live test to confirm Google receives a 403 now, not only in the past.
2. Check your CDN or firewall logs for blocked requests with Googlebot in the user agent around the reported dates.
3. Allow verified search engine crawlers in bot protection and WAF settings, and remove country blocks that include the United States if you want Google to crawl.
4. Review security plugins and server rules (.htaccess, nginx) for user-agent or IP blocks.
5. If the pages are meant to be private, keep the 403 and remove them from your sitemap and internal links.

Common causes

Firewall or CDN refuses Googlebot

A WAF can return 403 when a request matches a security rule, rate limit, bot challenge, or geographic restriction. Your own browser may be allowed because it has a trusted session or comes from another network. Check edge logs for the requested URL and status at Google's crawl time.

Site requires a session or password

A staging gate, membership requirement, or password page may return forbidden access to unauthenticated crawlers. Confirm that the page is intended to be public before removing the restriction. Private content should remain protected and should not be submitted as an indexable URL.

Host or bot rule blocks data-center traffic

Some hosting configurations block IP ranges or automated request patterns broadly. A user-agent string alone is not reliable proof of Google's identity. Review provider logs and use Google's published verification guidance before creating an allowlist.

Application denies a path or method

A plugin or route handler can return 403 for specific product templates, query strings, or HTTP requests. If only a subset of URLs fails, compare their path patterns and application logs rather than changing the whole site's security posture.

Fix it on your platform

On Shopify

1. Test the exact public URL while logged out and check whether the store is in password mode or a product is unavailable on the Online Store sales channel.
2. If a third-party CDN, proxy, or bot app is in front of Shopify, inspect its firewall events and challenge rules for Googlebot requests. Shopify storefront access itself may be fine while the extra layer blocks crawlers.
3. Review app-level country restrictions and product visibility. Keep genuine private routes protected; make intended public product pages accessible to the target countries.
4. Use verified crawler guidance when adjusting firewall rules; do not allow traffic solely because a request claims a Googlebot user agent.

On WooCommerce

1. Check security plugins, host firewalls, and CDN logs for 403 responses on the affected route. Compare the timestamp with Search Console's last crawl.
2. Open the URL as a logged-out visitor and check maintenance, membership, or country restriction settings that may hide the page from crawlers.
3. Review server access-control rules and plugin logs if only certain product URLs or query parameters are affected.
4. Use Google's published Googlebot verification method before adding IP-based exceptions; a spoofed user-agent can be sent by any client.

On other platforms

1. Ask the hosting or platform provider to identify the layer generating 403: edge firewall, origin, application, or authentication requirement.
2. If content should be public, adjust the relevant allow/challenge rule narrowly and test the exact URL from outside your network.
3. For private or staging pages, keep access protection in place and remove those URLs from public sitemap and navigation.
4. Check firewall events and verified crawler IP documentation before allowing crawler requests.

How to confirm it is fixed

1. Use URL Inspection's live test to see Google's current fetch result and compare it with the indexed crawl date.
2. Request the URL externally without cookies and review CDN, server, or app logs for the 403 decision and matching rule.
3. Run the product page check on intended public URLs and confirm they return a usable response outside your session.
4. After the access rule is corrected, request indexing for a few important pages and monitor the Page indexing report after recrawl.

A worked example

Hypothetical case: a WooCommerce store adds a security plugin rule to block suspicious data-center traffic. Search Console then reports Blocked due to access forbidden (403) for product pages, while the owner sees them normally at home. The host log shows the plugin returning 403 to anonymous requests that match a rate pattern. The owner adjusts the rule to challenge suspicious traffic without denying normal page requests, checks the host's verified Googlebot guidance, and tests product URLs from an external network. They confirm the access response is fixed before requesting a recrawl; they do not disable the firewall sitewide.

Other errors like this