Fixing “product page unavailable” in Google Merchant Center when the page loads fine

Google disapproves a product with “product page unavailable” or a landing page error. You open the URL and it loads instantly. Support asks if the page is up. It is. The disapproval stays.

The catch: Google never sees your page the way you do. You are logged in, cookied, and browsing from a residential connection. Googlebot is none of those things, and any one of these differences can wall it off.

The five causes, most common first

1. An access wall you forgot exists. Password protection, a members-only gate, a bot challenge, or a geo block. Password-protected storefronts redirect every product URL to a password page that returns a healthy-looking 200, which is exactly why the error confuses people: the response is fine, the content is not your product.

Reproduce it honestly: fetch the URL with no cookies and follow redirects. If the final URL is not your product page, that is the answer.

2. robots.txt rules blocking the path. A theme change, an app, or an old rule can disallow product paths for Google’s crawlers specifically. Check your robots.txt against the exact path, and remember that Googlebot honors the most specific matching rule, not the first one.

3. Redirect chains that end somewhere else. URL structure changes, market redirects, or an app rewriting URLs can send the submitted feed URL somewhere the product no longer lives. Google wants the submitted URL to serve the product, not a chain of hops to a different page.

4. Slow or throttled responses. If your storefront rate-limits or responds slowly under load, the crawler gives up before the page renders. This one comes and goes, which makes it the most maddening to reproduce by hand.

5. A noindex tag or canonical pointing away. A stray meta robots tag or a canonical URL to a different page tells Google the page it fetched is not the page to trust.

The manual diagnosis

For one product, run through this list: fetch the URL cold with redirects visible, read robots.txt against the path, check for noindex and the canonical target, compare structured-data price and stock against the feed, and confirm the image URL responds. That is an hour done carefully, and disapprovals rarely stop at one product.

The monitored version

FeedWarden runs this exact checklist on every flagged product during every scan: HTTP status, hop-by-hop redirect chain, robots rules as Google reads them, noindex, canonical, structured-data parity, and image reachability. A page that redirects to an access wall is called out as blocked, with the wall named, and the incident carries the evidence so a support ticket ends the argument instead of starting one.