Google Shopping landing page errors: crawl failures explained and fixed
Why Google Shopping flags landing page errors, desktop and mobile crawl failures, robots.txt blocks, timeouts, redirects, soft-404s and geo-blocking, and how to test each one.
A landing page error means Google's crawler tried to visit the URL in your feed and didn't get a working product page back. The feed data can be perfect, if the page 404s, times out, blocks the crawler or redirects somewhere unhelpful, the item is disapproved. This guide covers how Google actually crawls landing pages, the six failure modes behind desktop and mobile landing page errors, and how to test each one yourself before requesting anything from Google.
How Google crawls your landing pages
Every product in your feed carries a link (and optionally mobile_link). Google doesn't take those URLs on trust: it crawls them, repeatedly, to verify the page exists, loads, and shows the product at the price and availability the feed claims. Crawls run with both a desktop and a smartphone user agent, which is why Diagnostics reports desktop and mobile landing page errors as separate issues: each user agent gets its own verdict.
The crucial mindset shift: the crawler is a cold, anonymous, probably-American robot. It has no cookies, no login, no basket, no cached assets, and it announces itself as Googlebot. Your landing page has to work for that visitor: not for you, warm-cached and logged in on the store's home Wi-Fi. Nearly every "but the page works fine!" investigation ends at a difference between those two visitors.
A failed crawl disapproves the item. Persistent failures across the catalogue escalate to account-level enforcement, because unreachable landing pages are, from Google's side, indistinguishable from a broken or fake shop.
The six failure modes
1. Hard errors: 404s and 5xx
The page is genuinely gone (deleted product, changed URL structure, platform migration) or the server errored. The feed keeps sending the old URL because nothing told it the page moved. Fix the source of URLs in your feed generation, not the individual links: a migration that changed URL structure is one fix upstream, not 5,000 link edits.
2. robots.txt blocks
If robots.txt disallows Google's crawlers on product paths, Merchant Center cannot verify anything and disapproves the lot. This one loves to appear after site maintenance ("we blocked bots during the redesign and forgot"), or from a platform app that ships its own robots rules. Product URLs and image URLs must be crawlable.
3. Timeouts and slow pages
The crawler gives up if the page doesn't respond in time. Culprits: cold caches on low-traffic long-tail products, an origin that renders product pages on demand, or third-party scripts that stall the response. Mobile crawls are less patient: chronically slow pages often show as mobile-only errors first, making mobile errors your early-warning signal.
4. Redirect problems
A redirect isn't automatically an error: a clean 301 to a working product page is fine. Failures are: redirect chains that are too long, redirects to the homepage or a category page (Google wanted this product), redirect loops, and desktop URLs bouncing to a mobile subdomain that then errors. If a product is discontinued, the honest fix is removing it from the feed, not redirecting its URL to the home page.
5. Soft-404s
The server says 200 but the page says "product not found", shows an empty template, or renders a search-results page with nothing in it. Google detects these (a success status wrapping a failure page) and treats them as errors. Soft-404s are the sneakiest mode because every naive monitoring check (status code == 200) reports the page as healthy.
6. Geo-blocking and bot protection
Google crawls predominantly from US IP addresses. If your firewall, CDN country rules or bot protection blocks or challenges those requests, the crawler sees a wall. CAPTCHAs, "verify you are human" interstitials, and WAF rules that throttle datacentre IPs all land here. You must allow Google's crawlers even for a UK-only shop: the crawler's origin is not your customer's.
How to test a Google Shopping landing page error yourself
Work through this before touching Merchant Center, using an exact URL from your feed (not one you typed from memory):
- Fetch the URL cold, as Googlebot, from outside your network. A plain HTTP client with a Googlebot user agent, following redirects. Record the final status code and how long it took.
- Check robots.txt. Fetch
/robots.txtand confirm no disallow rule covers product or image paths for Google's user agents. - Inspect the final page content. Is the product actually on it: name, price, add-to-basket? A 200 with the wrong content is a soft-404.
- Repeat with a smartphone user agent if the error is mobile-specific. Watch for interstitials, app-download banners and mobile redirects.
- Run the URL through Search Console's URL Inspection tool. This performs a real Google crawl and shows the rendered result: the ground truth for "what does Google see".
- Check timing at the 95th percentile, not the average. Test a long-tail product nobody visits, not your best-seller that's always cached.
Once the underlying failure is fixed, the crawl has to re-verify: data-level fixes clear on re-crawl without a review request, typically within 72 hours. The general fix workflow covers what to expect after resubmission, and products pending review covers the waiting.
Deep dive The crawl is also how Google checks your prices: and why feed and page must move together
Landing page crawls do double duty. The same visit that verifies the page works also reads the price and availability on the page and compares them against your feed. This is why landing page health and price and availability mismatch are two ends of the same pipeline: and why some landing-page-adjacent disapprovals aren't about reachability at all.
The failure sequence merchants hit:
- The site changes a price or a product sells out.
- The feed, refreshing daily, still carries yesterday's numbers.
- The crawler visits, reads the page, sees the disagreement, and disapproves for mismatch: or, if the pattern repeats, starts preemptively disapproving items it predicts will mismatch, before any crawl catches them in the act.
Three structural consequences worth designing around:
- Crawlability is a precondition for trust. If Google can't crawl your pages, it can't verify your prices: and unverifiable prices are treated as a risk, not a neutral unknown. A catalogue with patchy crawl success gets more preemptive scepticism, not less scrutiny.
- The page is the source of truth. In every feed-vs-page disagreement, Google believes the page. So machine-readable pricing on the page (structured data with
priceandavailability) gives the crawler an unambiguous read and removes "the crawler misread my page" from the failure space. On Shopify, see structured data on the PDP. - Feed refresh cadence is a crawl-error lever. The faster your feed reflects the site, the smaller the window in which any crawl can catch a disagreement. Stock that changes hourly against a feed that syncs daily is a standing invitation: see inventory and availability sync for closing that gap.
The durable setup treats the feed and the site as one system with two outputs that must agree at crawl time: pages fast and crawlable from anywhere, structured data present, feed refreshed at the pace the site actually changes, and monitoring on both: because a landing page error and a price mismatch are the same root problem wearing different reason strings. A drop in crawl success after a deploy is the signal worth tracing immediately; change monitoring exists to surface exactly that movement before the disapprovals pile up.
Failure modes at a glance
| Failure | Typical cause | Test | Fix |
|---|---|---|---|
| 404 / 5xx | Deleted products, URL migration | Cold fetch, check status | Fix URL source in feed generation |
| robots.txt block | Maintenance rules, platform apps | Read robots.txt | Allow Google's crawlers on product + image paths |
| Timeout | On-demand rendering, cold cache | Time a long-tail product cold | Cache product pages; speed up origin |
| Bad redirect | Discontinued products, mobile subdomains | Follow the full chain | 301 once to the product, or remove item from feed |
| Soft-404 | Empty templates returning 200 | Inspect final page content | Return real 404s; remove dead items from feed |
| Geo/bot blocking | WAF, CDN country rules, CAPTCHAs | Fetch as Googlebot from a datacentre IP | Allowlist Google's crawlers |
The pattern across all six: fix the class of problem at its source, resync, and let the re-crawl clear the items. Fixing landing page errors one URL at a time is the same trap as fixing disapprovals one product at a time: the reason string names an instance, but the fix belongs to the category.
Frequently asked questions
What does "landing page error" mean in Google Merchant Center?
Google's crawler requested the link in your feed and got a failure, a 404 or error status, a timeout, a robots.txt block, or a page that didn't show the product. The item is disapproved until a crawl succeeds, regardless of how clean the feed data is.
Why do I get mobile landing page errors but not desktop ones?
Google crawls with both desktop and smartphone user agents, and mobile is the stricter check. Common mobile-only failures, an interstitial or app banner blocking the page, a mobile subdomain that redirects badly, mobile-specific bot rules, or a page too slow on the mobile crawl budget.
How do I test my landing page the way Google sees it?
Fetch the exact feed URL with a Googlebot user agent from outside your network, follow redirects, and check the final status code and content. The URL Inspection tool in Search Console runs a genuine Google crawl and shows the rendered result, the closest you can get to Google's own view.
Does robots.txt affect Shopping ads?
Yes. If robots.txt disallows the crawler for your product URLs, Merchant Center can't verify the page and disapproves the items. Product and image paths must be crawlable, check for disallow rules added by platform apps or during site maintenance.
My pages work fine in my browser, why does Google say they're broken?
Because you aren't crawling like Google. You're logged in, cookied, in the right country, on a warmed cache. The crawler arrives cold, from a US IP, with a bot user agent, and hits the geo-block, bot challenge or cold-cache timeout you never see.