Debugging the Shopify 403 error that blocks Googlebot

TL;DR

• "Blocked due to access forbidden (403)" in Search Console means something answered Googlebot with a 403 instead of the page. Google documents this as a misconfiguration, since Googlebot never sends credentials in the first place.
• On Shopify, the merchant (and you, as the developer) don't run the server, so the 403 is coming from something sitting between Google and Shopify: an unsupported proxy, a geo-restriction rule, or a third-party app answering an app-proxy path.
• The fix depends entirely on which of those it is. Sorting the affected URLs and running a live test in Search Console is the first step, not editing a firewall that doesn't exist.

If you build or maintain Shopify storefronts for clients, sooner or later you'll open Search Console and find a row you can't immediately explain: "Blocked due to access forbidden (403)" under Page indexing. Google's definition is unusually blunt about it: the response itself is wrong, not just restrictive. The problem is that the standard playbook for a 403 (check .htaccess, check firewall rules, check server logs) assumes you run the server. On Shopify you don't. The client's storefront runs on infrastructure neither of you can touch, so a 403 has to originate from something between Googlebot and Shopify: a proxy, a geo-restriction app, a third-party app's backend answering an app-proxy path, or a domain that isn't actually pointed at Shopify anymore. Here's how to figure out which one, and fix it.

What does "blocked due to access forbidden (403)" actually mean?

Google's Page indexing report documentation is more opinionated than most status descriptions:

"HTTP 403 means that the user agent provided credentials, but was not granted access. However, Googlebot never provides credentials, so your server is returning this error incorrectly. The page will not be indexed."

Two things follow. First, Google isn't describing a legitimately protected page; it's saying the response is wrong for the request that was made. A 403 is what you send a client that authenticated and still lacks permission. Googlebot never authenticates, so it should get a 200 or a 404, not a 403.

Second, this is a different failure from its neighbors in the same report. Blocked by robots.txt is a rule Googlebot reads and voluntarily obeys; it never makes the request. Blocked due to unauthorized request (401) is a server asking for credentials. 403 is a request that was actually made, received, and actively refused. Something processed the connection and decided against it, which narrows the suspects considerably.

Why doesn't the standard 403 advice apply on Shopify?

Google's own remedy on the Shopping side makes the mismatch obvious. Merchant Center's product crawl issues page lists the causes as being "behind a firewall, geo-restrictions, or a private IP that blocks our crawlers," and instructs you to "ask your webmaster or hosting provider to update your firewall and server settings."

On Shopify, your client is nominally the webmaster and Shopify is the host, but Shopify doesn't expose firewall or server settings to change. Checking a handful of platform endpoints on two live Shopify storefronts with a Googlebot user agent returned 200 on /cart.js, 302 on /account, and 404/405 on Shopify's internal telemetry path, never 403. That's a small sample, not a guarantee about the platform, but it's enough to justify the working assumption: the 403 is coming from something other than Shopify itself, and the job is to find out what.

Which of the affected URLs actually need fixing?

Before diagnosing anything, pull the URL list attached to the status. It mixes together things that mean very different amounts of urgency:

• Product, collection or page URLs the client sells from. This is the emergency; Google says plainly it won't index these.
• App proxy paths, anything under /apps/, /a/, /community/ or /tools/. Not served by Shopify at all (see below), usually not urgent, and usually not fixable from the storefront's side.
• Paths neither of you recognize. Stores accumulate URLs from old apps, retired themes and dead integrations. Worth understanding, rarely worth an incident.

Forty 403s on paths nobody buys from is cleanup. One 403 on the client's best-selling product is a same-day fix. Sort the list before deciding how urgent this is.

How do you confirm the block is still happening?

1. Export the URLs from the 403 row and split them into the three groups above.
2. Run a live test on one affected product URL. In Search Console's URL Inspection tool, use Test live URL. The report shows what happened at the last crawl; the live test shows whether it's still happening now.
3. Check where the domain actually resolves. Shopify's manual domain connection guide documents an A record pointing to 23.227.38.65 and a www CNAME pointing to shops.myshopify.com. Anything else means something other than Shopify is answering on that domain.
4. Load the store yourself from a normal connection. If it loads fine for you but Google is refused, you're looking at something that treats automated clients differently from browsers.
5. Check Merchant Center separately. The same crawl issues page notes "Google uses AdsBot-Google for ads and Googlebot for organic search." Two crawlers, two consoles: a clean Search Console doesn't mean Merchant Center is clean.

What can actually return a 403 to Googlebot on a Shopify domain?

Four mechanisms are documented well enough to name, ordered by how fast you can rule each one out.

1. A proxy in front of the domain

Shopify's domain troubleshooting page states plainly that "Shopify doesn't support the setup of services such as Cloudflare DNS and Orange-to-Orange (O2O)" and that such a setup "could break at any time because of changes on either the Cloudflare or Shopify side." One listed problem is "reduced bot detection accuracy," because request attributes get altered before they reach Shopify. A proxy in this position can classify a crawler as unwanted traffic and answer with a 403, and it does so before Shopify ever sees the request, so nothing in Shopify admin will show it.

2. Region restrictions that exclude where Google crawls from

Merchant Center is explicit: "If you restrict specific regions, you must allow crawling from the US because Google often operates from there." A country-blocking app, a fraud-prevention rule, or a proxy geo-filter can refuse Google without anyone intending to touch a crawler. The store works perfectly for every real customer, which is exactly why the problem goes unnoticed.

3. An app proxy path answered by someone else's server

Shopify's app proxy documentation explains that app proxies "take requests to Shopify URLs, and proxy them to your app." A request under apps, a, community or tools on the storefront domain gets forwarded to the app developer's own server, which produces the response. A 403 there is the client's domain in Search Console, but it's neither the client's server nor Shopify's; you can't fix it from Shopify admin, and the only useful move is reporting the exact URL to the app vendor.

4. A domain that isn't actually pointed at Shopify

If a domain is parked or redirected through a third-party host instead of connected directly to Shopify, that host answers Googlebot, and its defaults decide what Googlebot receives. A merchant described exactly this shape in a Shopify Community thread: a domain "redirected to my shopify site" while Search Console showed the 403 status. Step 3 above rules this in or out.

How do you fix each cause?

• Proxy in front of the domain: remove it so requests reach Shopify directly. Shopify calls this setup "outside the scope of Shopify Support" and points to the third-party domain host for proxy settings, so expect the fix to happen at the DNS provider, not in Shopify admin.
• Region restrictions: allow the regions Google crawls from, US included, in whatever app or rule enforces the restriction. If the tool filters by user agent instead of geography, allow Googlebot and AdsBot-Google explicitly.
• App proxy path: report the URL to the app vendor. If the path serves nothing a shopper needs, removing the app or feature is the alternative.
• Domain not pointed at Shopify: reconnect it using the DNS records Shopify documents.

One caution on allowlisting by user agent: anything can claim to be Googlebot. Google publishes its crawler IP ranges as JSON, and matching against those ranges is the accurate way to implement "let Google through" if the blocking layer supports IP-based rules.

After the fix, re-run the live test on the same URL. The report keeps showing the old status until Google recrawls, so the live test is how you confirm the fix worked before the console catches up.

Why does this keep coming back on client stores?

Every mechanism above lives outside Shopify admin, and three of the four are owned by somebody else. A proxy configuration changes when a DNS provider updates a default. A geo-restriction rule gets tightened after a fraud incident. An app vendor redeploys and their server starts refusing crawlers on a path mounted on the client's domain.

None of those events trigger a notification. Shopify admin shows the product as active, priced and published the whole time, because from Shopify's point of view nothing is wrong; the request never reached it. Search Console reports it eventually, on its own crawl schedule. For an agency managing several client stores, that gap between the refusal starting and someone actually finding it is worth closing with a recurring check rather than waiting for a client to notice a sales drop.

Have you run into a 403 that turned out to be a third-party app or proxy on a client's store? What was it?

The full version of this article, with screenshots and ongoing updates, lives on the StoreCanary blog.