"Product page unavailable" in Merchant Center: why the check fails on a Shopify page that works

Short answer. "Product page unavailable" describes one request Google made, not the state of your page. Google's own list of causes is almost entirely about the request rather than the product: a redirect chain, an unreachable robots.txt, a hostname that would not resolve, a server that did not answer. On Shopify the link is generated for you, so start by checking whether one product is affected or the whole catalogue — that answer decides where to look.

Merchant Center flags your products as Product page unavailable. You click the URL, and the page opens. You try it on your phone, and it opens there too. Nothing in Shopify admin suggests a problem: the product is active, priced, published to the right sales channel. Then you request a review, the flags clear, and a few days later they start coming back.

That last part is the one worth taking seriously, because a fault that clears and returns on its own is not the fault the standard advice is written for. A merchant describing exactly this shape in a Shopify Community thread on 25 March 2026 writes that "products gradually get flagged as unavailable" and that after a manual recrawl "the issue clears almost immediately", before slowly returning. They had already checked the obvious: status codes, redirects, structured data, variant URLs, apps and theme. Everything answered normally, from where they were asking.

What Merchant Center is actually reporting

Google's own page for this issue is precise about its scope. It states that "For one or more of your products, you submitted a landing page via the link, link template, or mobile link attribute, that can't be accessed by Google and may also not be accessible to Google users." The subject of that sentence is the landing page you submitted, and the verb is about access — not about the page's contents, its markup, its price or its stock.

The same page lists the crawl errors behind the label, and they are all failures of a request rather than faults in a document: the landing page "was not found on the server"; "Your landing page redirects too many times"; "When we tried to access the landing page, the server couldn't process the request"; "The product page was unavailable for Google to check because your online store's robots.txt file couldn't be reached"; and "We weren't able to resolve the hostname".

Read that list against a Shopify store and the shape of it changes. Four of the five describe infrastructure — DNS, redirects, server responses, a file that has to be fetchable — and only the 404 is about the product itself. That matters because of who writes the URL. On a platform where you compose your own links, "you submitted a landing page that can't be accessed" invites you to go and look at the link you composed. On Shopify you did not compose it: it is generated from the product handle, and the same generated handle is what the sitemap and the theme use. So the link is the fastest thing to rule out, not the most promising thing to investigate — and the fix instructions, which are about correcting a link, address a question a Shopify merchant can settle in one glance.

Two checks, two crawlers, two verdicts

The most confusing property of this error is that Search Console can be entirely green while Merchant Center is red about the same URL. That is not a contradiction, because they are not the same check and not necessarily the same crawler.

Google's Search Central documentation lists Google StoreBot, user agent token Storebot-Google, as the crawler for "all surfaces of Google Shopping (for example, the Shopping tab in Google Search and Google Shopping)", separately from Googlebot, which serves Search. StoreBot's own Merchant Center page says it "crawls through certain types of pages, including, but not limited to, product details pages, cart pages, and checkout pages". Merchant Center's product crawl issues page, meanwhile, tells merchants to make sure robots.txt allows "Googlebot" (used for landing pages) and "Googlebot-image" (used for images).

You do not need to resolve which of those is doing the fetch on any given day to take the useful lesson from it, and the pattern is not confined to this error: a recurring shape in the ways a Shopify store loses Google visibility is two systems holding different views of the same page. At least two distinct Google crawler identities operate in this area, and the rule that governs one does not automatically govern another. Google states the matching rule plainly: "Some crawlers have more than one user agent token; you need to match only one crawler token for a rule to apply." A group written for one name is the group that name reads, and the global group stops applying to it.

That rule has a sharp edge in the ads crawler. Google documents that for AdsBot-Google, "The global user agent (*) is ignored." So a store can hold three different crawl policies at once without anyone having written three: one that the ads crawler reads from its own group, one that Shopping's crawler reads from the global group, and one that Googlebot reads from wherever a named group puts it.

This is not hypothetical on Shopify, because Shopify's default file already uses named groups. Fetching the public robots.txt of seven live Shopify storefronts on 19 September 2026, six returned a readable file, and every one of those six had a global User-agent: * group followed by a named group for adsbot-google; three of the six went further with named groups for crawlers like Nutch, AhrefsBot, MJ12bot and Pinterest. None of the six named Storebot-Google anywhere. That is the correct outcome and worth stating positively: on a stock Shopify store, Shopping's crawler falls under the global group, which allows product URLs. It also means robots.txt is the wrong place to look first — unless someone has edited it.

Want to see what your storefront returns to a crawler that isn't you? Our scan reads your public storefront the way a crawler does — product by product, read-only, no admin access, about 2 minutes. When a store refuses the scan outright, we record it as blocked rather than guessing what Google received. → free scan

Why "it works when I check it" is not the test

Underneath the troubleshooting sits one assumption, and it is the assumption the merchant in the thread above was working from: that a URL either works or it does not. Open it, watch it load, conclude the report is wrong.

Reachability is not a property of a URL. It is a property of a request — this address, this moment, this caller — and modern edge protection is built precisely to answer different callers differently. Google says so in its own words on the product crawl issues page: "Firewalls, geo-restrictions, or private IP: Your website may be behind a firewall, have geo-restrictions, or use a private IP that blocks our crawlers." It follows that up with the advice to "allow crawling from the US because Google often operates from there", and to ask whoever runs the hosting to "update your firewall and server settings to allow the Googlebot user agent". Those are instructions about where a request comes from and who it claims to be, not about your product.

Our own probe on 19 September 2026 shows both halves of this. Of the seven live Shopify storefronts we requested, four served a product page from their public sitemap, and all four answered a Storebot-Google user agent exactly as they answered Googlebot: the same 200, and a response body identical or within about a kilobyte. So the platform itself was not discriminating between crawler names — which is what you would hope, and it means a crawler-name theory should not be your first one.

The fifth storefront never got that far. Every request we made to it — the homepage, /robots.txt and /sitemap.xml, under a browser user agent, under Googlebot's and under Storebot-Google's — came back HTTP 403 from an edge provider, carrying an interstitial page whose own markup declares noindex,nofollow. The store itself is fine. Anyone shopping from a residential connection would see it load normally.

We are deliberately not claiming that store is blocking Google, and the reason is the whole point. Our requests came from a datacentre address, which is exactly the kind of caller these systems are tuned to challenge, while Google crawls from ranges it publishes itself — Search Central lists JSON files of the IP ranges for "Common crawlers like Googlebot" and "Special crawlers like AdsBot" — which a provider may well treat quite differently. What the probe demonstrates is the asymmetry itself: the same URL, at the same minute, returned 200 to some callers and 403 to another, and the difference was the address asking, not the page. If a storefront can answer two callers differently, then your browser's verdict on it is a sample of one, taken from the one network Google will never use.

Two consequences follow, and they are the practical value of the distinction. Testing with a crawler's user agent string from your own machine tells you almost nothing, because you changed the part that is cheap to change and not the part being judged. And a failure of this kind is intermittent by construction, because reputation scores and rate thresholds move on their own.

How to confirm it yourself in five minutes

In this order, because each step rules out more than the one after it and costs less.

1. Count the affected products first. One product points at that product's link. The whole catalogue points at something in front of the domain, and per-product editing will never touch it. Do this before you change anything, because it decides which half of this article you are in.
2. Compare the submitted link with what your store serves. Take the URL exactly as Merchant Center shows it. Does it answer directly, or redirect? Does the host match your primary domain? An apex address on a store that serves www, or an old secondary domain, adds a hop to every check — and "Your landing page redirects too many times" is a documented cause here.
3. Test from outside your own network. Ask someone on a different connection, or use any service that fetches the URL from a server rather than from a browser, and compare the status code with the one you get. This is the only step in the list that can surface a refusal aimed at a caller other than you.
4. List every User-agent line in your own robots.txt. Confirm it returns 200 — an unreachable robots.txt is a documented cause of this issue by itself — then read which groups exist. If someone added a named group, work out which crawlers now read it instead of the global one.
5. Establish what sits between your domain and Shopify. Look at your storefront's response headers for a server or proxy that is not Shopify, and at your DNS for a provider that proxies traffic rather than only resolving it. A layer there answers before Shopify ever sees the request.
6. Request a website check, and write down when. Google says "Google may take up to 12 hours to review your website". If the flags clear with no change from you, the page was never broken, and the real question is what made the earlier request fail.

The causes, and which ones are yours

A link that does not match the domain you serve. The cheapest cause to rule out, and one of the two on Google's list that a different URL would actually fix. If the feed carries an apex URL and the store redirects to www, or carries a domain you have since replaced, every check pays a redirect. One of the seven storefronts we requested on 19 September 2026 redirected its apex to www — a normal, healthy configuration that becomes a cost only when something upstream submits the wrong half of it. A redirect that lands somewhere other than the product is a different and more expensive problem, and we have covered the version where the product page redirects to the homepage.

An unreachable robots.txt. Google names this one explicitly, and it is worth understanding why it is disqualifying rather than merely unhelpful. A crawler that cannot read your rules does not assume permission; it stops. So the file returning a 403, a timeout or a challenge page takes your product pages down with it, even though none of those pages was ever asked for. That was the shape of the fifth storefront above: its robots.txt was refused along with everything else. It is the same class of failure as a sitemap Google reports it couldn't fetch — a file whose job is to be read, answering something other than its contents.

An edited robots.txt.liquid. Shopify's documentation is clear that "all Shopify stores have a default robots.txt file that's optimal for Search Engine Optimization (SEO)", and equally clear about the risk of changing it: the customization allows a merchant to "Block certain crawlers" and to "Add crawl-delay rules for certain crawlers", and Shopify states that "Incorrect use of the feature can result in loss of all traffic." A crawl-delay added to calm an aggressive scraper, or a named group copied from a forum answer, keeps applying long after the reason for it is gone — and it lives in a theme file rather than anywhere in the admin, so it survives the people who added it. If nobody has ever opened that file, this cause is not yours; if an agency, a developer or an app has, it is worth a minute. We have written separately about what an edited robots.txt costs on a Shopify store, and about what it looks like from the Search Console side.

Something in front of the domain refusing the caller. The category that fits the recurring version of this error, because it is the one that can answer the same URL differently at two different moments. It is the same cast of mechanisms that produces a "Blocked due to access forbidden (403)" status in Search Console — a proxy, a region restriction, a third party answering on a path mounted on your domain — and we have gone through each of them there rather than repeating them here. What differs on the Merchant Center side is the unit and the consequence. Search Console reports at the level of a URL's indexing status, when its own crawl next happens. Merchant Center reports per product, against the offer you are currently advertising, and an item carrying this issue is not shown while it carries it. Same refusal, read by two systems that do different things about it — which is also why the two reports disagree so often.

An allowlist written against a name instead of an address. Worth separating from the cause above, because the usual remedy makes it worse. Merchant Center's advice is to allow "the Googlebot user agent", and a user agent is a string any caller can send — so a protection layer that trusts it has a reason not to, and one that ignores it will keep refusing you no matter what you add. The durable version is to allow the ranges Google publishes for its crawlers rather than the name they present, and to confirm afterwards that a request from outside your network still gets a 200. Whoever runs the layer has to make that change; it is not reachable from Shopify admin.

A server that answered slowly rather than wrongly. Worth naming because it is invisible afterwards. Google's list includes the case where "the server couldn't process the request", and a request abandoned on a timeout leaves no trace you can go back and read — the page is fast again by the time you look. If your flags cluster around a traffic peak, a large import, or an app doing bulk work, that correlation is the evidence, and it is the only evidence you will get. The Search Console side of a timeout looks different again, and the Page indexing report has its own vocabulary for it.

Why this one comes back

Requesting a review does not repair anything. It re-asks a question, and when the answer depends on conditions rather than on configuration, a second ask at a quieter moment gets a better answer. The row clears. Nothing has changed. The next request that arrives while a rate threshold is tight, or from an address a provider has since decided it dislikes, re-opens it — one product at a time, which is why it looks like a slow drift rather than an outage.

The cost is not the flag, it is the interval. Google says a fixed store may take "up to 12 hours" to review, and its own instructions describe products starting to show again in ads and free listings over the following days. Every relapse therefore spends days of Shopping visibility on a product that was, throughout, in stock, correctly priced and perfectly able to serve a customer. Nothing announces the relapse. Merchant Center will show it to you when you next open Merchant Center — which is the general problem with relying on a platform to tell you a product went quiet.

That is the honest reason this belongs on a short list of things worth watching rather than fixing once. The trigger events are not yours and not announced: a hosting provider tightens a default, a security app is installed for an unrelated reason, a DNS plan changes, a bad traffic week makes a fraud rule stricter. Shopify admin will show the product as active and published the whole time, because from Shopify's point of view nothing is wrong — the request never arrived.

Being straightforward about our own boundary: StoreCanary does not report what Google's crawler receives. Nothing outside Google can, since the only witness to that request is Google. We fetch your storefront as ourselves, and when a store refuses us we record the scan as blocked rather than inferring anything about Googlebot from it. What we do check, on every product page in your public catalogue, is everything underneath that — the markup, prices, availability and indexing directives that decide whether a page Google can reach is one it can actually list. For the reachability question itself, Merchant Center's own diagnostics remain the instrument, and this is the row to keep an eye on.