Google fetches your pages separately
Submitting a feed is only half the contract. Google crawls the landing page URL of each product independently to verify that the page exists, loads, and agrees with the feed. This verification happens from Google infrastructure — cold requests, no session, no cookies, no admin preview. Your browser, by contrast, visits warmed, logged-in, often whitelisted. The entire failure category this article covers is the gap between those two viewpoints: works for me, fails for Google.
What “unavailable” really means
When Merchant Center says the landing page is unavailable, it means the crawler got an unusable HTTP response. A 5xx error is the classic: the page renders for you because your session avoids the broken path, while a cold request hits it. 403 or 401 means bot protection or a firewall refused the crawler outright — common behind CDNs and security apps with aggressive defaults. 429 means rate limiting bit during a crawl burst; failures that cluster in time rather than on particular products point here. Any of these disapproves the product, and none of them is visible from your desk.
Redirects and soft 404s
A product URL that redirects to a collection page or the homepage reads as missing, not moved — submit the final URL in the feed instead. Renamed handles are the slow version of the same bug: the old URL 404s or lands somewhere generic while the feed keeps pointing at it. Soft 404s are worse — a 200 status with no product on it — because everything looks healthy until Google decides the page has no usable content. After any handle change, fix the source of the URL rather than stacking redirects.
Price and availability parity
The feed price and the landing page price must match to the cent, in the same currency. Multi-currency stores, sales that expire overnight, and prices that update in Shopify before the feed re-fetches all create windows where they disagree — and even a one-cent rounding difference can trigger a disapproval. Availability must agree too: a product the feed calls out of stock while the page still sells it (or the reverse, common with “continue selling when out of stock” enabled) is the availability version of the same mismatch, and it draws preemptive disapproval.
How to test like a crawler
- Open the exact public product URL in a private window with no session — never the admin preview.
- Check the status code, not just the rendering. A page can look right while returning the wrong code.
- Follow the redirect chain to its end and confirm it lands on the product, not a collection or homepage.
- Compare the page price, currency and stock state against the feed values character by character.
- Repeat from outside your network. An incognito window still uses your network; only a third-party request shows what Google receives.
Shipwork requests a sample of your product pages from outside your network the way a crawler would, and reports the status, redirect chain and final destination of each one. Free, no account, no signup — paste your store address.
Check my pagesQuestions
- My product page loads fine — why does Google say it is unavailable?
- Because Google fetches from its own infrastructure with no session. Bot protection, firewall rules or rate limiting often treat that cold request differently than your warmed browser.
- Does a redirecting product URL cause disapproval?
- It causes mismatch-class problems: submit the final URL in the feed. A product URL ending on a collection or homepage reads as a missing product page.
- How exact must the price match be?
- To the cent, same currency. Rounding differences from multi-currency conversion are a documented trigger.
- How many pages should I test?
- A sample across templates is enough to find systemic issues — bot rules and price logic apply store-wide, not per product. The free check samples up to 12 product pages.
Keep reading