"Blocked due to access forbidden (403)" on Shopify: who is actually refusing Googlebot?

Short answer. Googlebot asked for the URL and something answered 403 instead of the page. Google documents this as a server misconfiguration, because Googlebot never sends credentials in the first place. On Shopify you do not run the server, so the useful question is not "how do I edit my firewall" but which URLs are listed — and what sits between Google and Shopify on your domain.

The row appears in Search Console's Page indexing report, under the pages that were not indexed. What makes it unusual is that Google's definition does not merely describe the response — it calls the response incorrect. Its practical effect is stated in the same breath: the page will not be indexed.

The guides ranking for this error when I checked on 2 September 2026 are written for the general web, and they assume you own the machine: read your access logs, edit your .htaccess, adjust your firewall rules, ask your host to allowlist Googlebot. On a hosted platform none of those are things you have. That gap — between the standard advice and what a Shopify merchant can actually do — is what this page is about.

What Google actually means by this status

The definition in the Page indexing report documentation is worth reading closely, because it is more opinionated than most:

"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 from that. First, Google is not describing a situation where you legitimately protected a page — it is saying the response itself is wrong for the request that was made. A 403 is the answer you give a client that authenticated and still lacks permission; Googlebot never authenticates, so it should be getting a 200 or a 404, not a 403.

Second, this is a different failure from the neighbouring statuses in the same report, and the difference decides the fix. 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. Blocked due to access forbidden (403) is a request that was actually made, actually received, and actively refused. Something processed Googlebot's connection and decided against it. That is a much narrower set of suspects.

Why this status reads differently on a hosted platform

Google's own remedy, on the Shopping side of the house, makes the mismatch obvious. The Merchant Center product crawl issues page lists the causes as "Your website may be behind a firewall, have geo-restrictions, or use a private IP that blocks our crawlers", and its instruction is to "Ask your webmaster or hosting provider to update your firewall and server settings to allow the AdsBot-Google user agent."

On Shopify, you are the webmaster and Shopify is the hosting provider, and Shopify does not expose firewall or server settings to change. The advice is not wrong, but following it literally leads a merchant into a settings screen that does not exist. The Shopify Community thread cited further down ends without a resolution for exactly that reason.

It is worth being concrete about what Shopify's own infrastructure does return. Checking a handful of platform endpoints on two unrelated live Shopify storefronts on 2 September 2026, with a Googlebot user agent, the responses were 200 on /cart.js, 302 on /account, and 404 or 405 on the internal /.well-known/shopify/monorail/unstable/produce_batch telemetry path — not 403. That is a small sample of paths on two stores rather than a guarantee about the platform, so treat it as a working assumption rather than a law. But it is enough to justify the diagnostic posture that makes this page useful: start from the hypothesis that the 403 is coming from something other than Shopify, and work out what.

Which URLs are an emergency, and which are not

Before diagnosing anything, read the URL list attached to the status. This report mixes together things that mean completely different amounts of trouble, and the list is the only place that distinction is visible.

• A product, collection or page URL you sell from. This is the emergency. Google is being refused a page you depend on, and the documentation says plainly it will not be indexed.
• An app proxy path — anything under /apps/, /a/, /community/ or /tools/. These are not served by Shopify at all; see the causes below. Usually not an emergency, and usually not yours to fix.
• Paths you have never heard of. A storefront accumulates URLs from apps, past themes and old integrations. A 403 on one of these is worth understanding but rarely worth an incident.

A report showing forty 403s is not automatically forty times worse than a report showing one. Forty refusals on paths nobody buys from is housekeeping; a single refusal on your best-selling product is the thing to fix today. Sorting the list first is what stops a merchant either panicking at noise or missing the one line that matters.

How to confirm it yourself in five minutes

1. Open the 403 row and export the URLs, then split them into the three groups above. This takes a minute and changes what you do next.
2. Run a live test on one affected product URL. In Search Console's URL Inspection tool, use Test live URL. Google describes it as "a live test: the tool fetches and examines the URL in real time", which is exactly what you need here — the report tells you what happened at the last crawl, the live test tells you whether it is still happening now.
3. Check where your domain 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. If your records point at anything else, something other than Shopify is answering requests on your domain.
4. Open your store in a private window from a normal connection. If the page loads for you but Google is refused, you are looking at something that treats automated clients differently from browsers — which narrows it to the causes below.
5. Check the Shopping side separately. The same Merchant Center crawl issues page notes that "Google uses AdsBot-Google for ads and Googlebot for organic search." Two crawlers, two consoles: a healthy Search Console does not prove Merchant Center is fine.

Want to know what else is silently wrong across your catalogue? We check every product page in your public catalogue for the Google visibility failures that never show up in Shopify admin — read-only, no admin access, about 2 minutes. → free scan

What can refuse Googlebot on a Shopify domain

Four mechanisms are documented well enough to name. They are not equally common, and we have no measurement of their relative frequency, so they are listed by how quickly you can rule each one out.

1. A proxy sitting in front of the domain

This is the first thing to check, because Shopify documents it and documents it strongly. Shopify's domain troubleshooting page states that "Shopify doesn't support the setup of services such as Cloudflare DNS and Orange-to-Orange (O2O)", and that "Cloudflare proxy setups, including O2O, aren't supported by Shopify. Although your store might appear to function correctly, this setup could break at any time because of changes on either the Cloudflare or Shopify side."

Among the specific problems it lists is "Reduced bot detection accuracy", because request attributes are altered before they reach Shopify. A proxy in this position is exactly the kind of layer that can classify a crawler as unwanted traffic and answer it with a 403 — and it does so before Shopify ever sees the request, which is why nothing in Shopify admin reports it.

2. Region restrictions that exclude where Google crawls from

Merchant Center's product crawl issues page is explicit: "If you restrict specific regions, you must allow crawling from the US because Google often operates from there." A merchant who blocks traffic from outside their selling country — through a country-blocking app, a proxy rule, or a fraud-prevention configuration — can be refusing Google without ever intending to touch a crawler. The store works perfectly for every customer the merchant has, which is precisely why the problem survives.

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 to a path under apps, a, community or tools on your storefront is forwarded to the app developer's own server, which produces the response.

So a 403 on yourstore.com/apps/something is your domain in Search Console, but it is not your server and not Shopify's. The refusal is coming from a third party's infrastructure. You cannot fix it from Shopify admin, and the only useful action is to send the exact URL to the app vendor.

4. A domain that is not actually pointed at Shopify

If a domain is parked or redirected at a third-party host rather than connected to Shopify, that host answers Googlebot — and its defaults, not Shopify's, decide what Googlebot receives. A merchant described exactly this shape in a Shopify Community thread dated 16 January 2024, reporting a domain that "is re-directed to my shopify site" while Search Console showed "Blocked Due to Access Forbidden (403)". Step 3 of the confirm procedure above is what rules this in or out.

The fix, cause by cause

• Proxy in front of the domain: take it out of the path so requests reach Shopify directly. The same Shopify troubleshooting page calls this setup "outside the scope of Shopify Support" and advises contacting the third-party domain host to review proxy settings, so expect the fix to happen at the DNS provider rather than in Shopify admin.
• Region restrictions: allow the regions Google crawls from, US included, in whatever app or rule is enforcing the restriction. If the tool works on user agents rather than 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, the alternative is removing the app or the feature that mounts it.
• Domain not pointed at Shopify: connect it using the records Shopify documents, so Shopify answers requests on that hostname.

One caution on allowlisting by user agent: anything can claim to be Googlebot. Google publishes its crawler IP ranges as JSON files and states that "You can identify Googlebot by IP address by matching the crawler's IP address to the lists of Google crawlers' and fetchers' IP ranges." If whatever is doing the blocking supports IP-based rules, that is the accurate way to express "let Google through".

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

Why this one comes back

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 or a plan changes — and Shopify's own wording is that such a setup "could break at any time because of changes on either the Cloudflare or Shopify side", which is a direct statement that this is not a one-time fix. A country-blocking rule gets tightened after a fraud incident. An app vendor redeploys and their server starts refusing crawlers on a path mounted on your domain.

None of those events produce a notification. Shopify admin will show the product as active, priced and published throughout, because from Shopify's point of view nothing is wrong: the request never reached it. Search Console will tell you eventually, on its own crawl schedule. The gap between the refusal starting and the merchant finding out is however long it takes someone to go looking.

To be straightforward about our own boundary here: StoreCanary does not report what Google's crawler receives. We fetch your storefront as ourselves, and when a store refuses our scanner we record the scan as blocked rather than inferring anything about Googlebot. What we do check, on every product page in your public catalogue, is the layer underneath — the markup, prices, availability and indexing directives that decide whether a page that is reachable can actually be shown. Search Console remains the instrument for crawler access, and this report is the row to watch.