Why does Google randomly disapprove my products as unreachable when the page clearly loads?
Intermittent Merchant Center disapprovals for unreachable landing pages almost always trace back to something blocking Google's crawler some of the time, not a real problem with the product page.
What's going on
A merchant runs a normal Google Shopping feed for weeks, then out of nowhere a batch of products gets disapproved with an unreachable or can't-be-crawled error, even though clicking the product link in a browser works perfectly. A day or two later, some or all of the products come back on their own, only for the same thing to happen again a few weeks later with no obvious trigger.
This is a genuinely confusing failure mode because the page is clearly live and clearly loads for a human. The problem is that Google's Shopping crawler, and AdsBot-Google if the merchant runs Shopping ads, doesn't fetch the page the way a browser does. Anything that treats bots differently from browsers, such as a CDN security rule, a bot-management app, a firewall, a region lock, an age gate, or even a slow app script that only times out under load, can intermittently block or stall just the crawler's request while every human visitor sees a normal page.
Why it happens
Google Merchant Center's crawler and AdsBot-Google make automated, unauthenticated requests to each product's landing page to verify it exists, loads, and matches the feed data. If any of those requests gets a non-200 response, a timeout, a redirect loop, or a robots directive telling it not to index the page, Merchant Center logs a crawl error and disapproves the product, even if the very next request from the same crawler would have succeeded.
Because the failure is about one specific crawler request at one specific moment, the most common causes are things that behave differently for bots than for regular visitors: a CDN or WAF, most often Cloudflare on stores using a custom domain, applying rate limits or bot-challenge rules to non-browser traffic; a leftover robots.txt or noindex change from an old SEO edit; an intermittent server error or slow response during high load; or a geo or age-restriction app that blocks based on the crawler's IP address. Because these causes are intermittent by nature, the disapproval can look random even though there's a concrete, findable cause each time.
5 ways to fix it
Check the actual crawl error in Merchant Center and Search Console first
Don't guess. In Merchant Center, open the product's diagnostic details and read the exact crawl error (404, 5xx, timeout, robots block, or redirect loop) along with the timestamp. Google Search Console's URL Inspection tool also lets you test the live URL to see exactly what Googlebot receives right now. This usually shows the disapproval lined up with a specific outage window, an app error, a theme deploy, or a CDN hiccup, rather than anything actually wrong with the product. Once you fix the underlying cause, you can request a fresh crawl instead of waiting for the next scheduled one.
Rule out a stray robots.txt or noindex change
Shopify's default robots.txt already allows crawlers on product and collection pages while blocking admin, cart, and checkout, so it's rarely the cause out of the box. But if anyone on the team, or an SEO app, has customized the theme's robots.txt template, a stray disallow rule or an accidental noindex tag on product pages will tell Google the page can't be indexed, which shows up in Merchant Center as unreachable rather than as a clear robots error. Revert any recent changes and confirm the live product URL returns a normal response with no noindex directive.
Check Cloudflare or any WAF, CDN, or bot-blocking app for crawler allowlisting
This is the most common cause of intermittent, seemingly random unreachable disapprovals on stores that front their domain with Cloudflare or run a bot-management app. Challenge pages, rate limiting, or generic bot-blocking rules can reject Google's crawlers on some requests but not others, which matches the random, recurring pattern merchants describe. Check your security event logs around the disapproval timestamp for requests from Google's crawlers, and make sure they're explicitly allowlisted rather than just not currently blocked.
Pull server or CDN logs for Google's crawler requests
If Merchant Center and your CDN both look clean, check raw access logs, available through your CDN or a logging app, for crawler requests around the time of the disapproval. Look for server errors, redirect chains (especially protocol or www redirects that loop), or unusually slow responses. Google can mark a page unreachable if a request times out, even if no human visitor ever notices the slowness, which often happens during a traffic spike or heavy app load on product pages.
Rule out region, age-gate, or password-protection apps that block by IP
Apps that restrict storefront access by country, show an age-verification wall, or password-protect the store will block a crawler the same way they block a real visitor from a disallowed region, and Google's crawler traffic doesn't always geolocate the way you'd expect. That can cause a geo or age-restriction app to intermittently deny the crawler while working fine for most human shoppers. Temporarily disable or allowlist Google's crawler for any such app to see if the pattern of disapprovals lines up.
Bottom line
Most randomly unreachable disapprovals trace back to something intermittently blocking Google's crawlers, not a real problem with the product or listing: a CDN or WAF rule, a stray robots.txt or noindex change, a server hiccup, or a geo or age-gate app. Work through Merchant Center's diagnostics and your server or CDN logs to find the actual blocked request before changing anything else, since fixing the wrong thing won't stop the pattern from recurring. This is a crawler-access and infrastructure issue rather than something a single app setting controls, though a general site-health scan can help catch robots.txt or noindex mistakes on your own product pages before they trigger the next round of disapprovals.
Browse the rest of the problem library, run a free storefront scan to catch issues like this automatically, or email us and we'll work out a custom solution for it.