Short answer. Merchant Center disapproves a product with “Unavailable desktop landing page” or “Unavailable mobile landing page” when Google’s crawler could not load the URL in the link attribute: a 404 for a deleted product, a 5xx from the server, a timeout, a bot block or a redirect somewhere else. Make the URL return the product page with a 200 status for any visitor, then re-fetch the feed; Search Console’s URL Inspection tool shows you what Google sees.
| Shown in Merchant Center as | Unavailable desktop landing page |
|---|---|
| Attribute | link |
| Effect | Product disapproved — Many failing pages become “Landing page not working” on the account |
| Where to find it | Products → Needs attention, then filter by this issue |
| Free check | Reported by the free feed check |
What Merchant Center means by “Unavailable desktop landing page”
Google’s crawler tried to open the URL in the product’s link attribute, once as a desktop browser and once as a smartphone, and one of them did not get a working product page back. The Content API lists the issues as landing_page_error, “Unavailable desktop landing page”, and mobile_landing_page_error, “Unavailable mobile landing page”, in its product issues reference. Google’s help page for the desktop issue says to make the page accessible from any device, location or browser and to test with Search Console’s URL Inspection tool, choosing “Desktop” as the fetch type. The link specification has the requirements the page must meet.
The product is disapproved until a crawl succeeds. When many products fail at once, Google raises the account-level issue covered by its “Landing page not working” page, which needs a review after the fix and, unresolved, can suspend the account.
Why it happens
- Deleted or unpublished products whose URL now returns 404, while the feed still lists them.
- Server errors (5xx) during a deployment, a plugin failure or an overloaded host at the moment of the crawl.
- Bot protection and geo-blocking. Cloudflare challenges, firewall rules, or a country block that keeps Google’s US-based crawler out.
- Password-protected or coming-soon storefronts, and staging URLs in the feed.
- Redirects to somewhere else. A URL that lands on the homepage or a category page, an interstitial, or a redirect loop.
- Mobile-only failures. A separate mobile site, an app-install interstitial, or a mobile redirect that breaks, so the smartphone fetch fails alone.
- http:// links on a store that has moved to https, where the old scheme no longer answers or redirects badly.
How to fix it
In Shopify
Shopify pages are rarely down; the failures are usually password-protected stores, products unpublished from the Online Store channel but still in the feed, or apps that insert interstitials. Remove the storefront password, make sure every product in the feed is published to Online Store, and test one affected URL in Search Console’s URL Inspection tool as both desktop and mobile.
In WooCommerce
Check the affected URLs’ status codes in your server log or with a quick fetch. For 403s, allow Googlebot through your security plugin, firewall or CDN without a JavaScript challenge; for 5xx, look at the error log around the crawl time; for 404s, remove the product from the feed. Our free connector only includes published, visible products and writes their current permalinks, so a deleted product leaves the feed on the next fetch.
In a CSV or XML feed
Filter Needs attention to this issue, download the CSV, and fetch each link with a plain HTTP client from outside your network: anything other than a 200 with the product page is the cause. Fix the URLs (current https address, the product page itself, no redirect), remove rows for products that no longer exist, and re-fetch the feed. Then, if the account-level landing page issue is showing, request a review.
How long until Merchant Center clears it
Google re-crawls the pages after the feed changes; a successful crawl re-approves the product, typically within 24–48 hours of the fix. The account-level “Landing page not working” issue clears only after you request a review, once the item-level failures are gone.
What FeedRobin does about it
The free check opens a sample of the product pages in your feed to compare prices, so a page that cannot be fetched shows up in that sample as unreachable, and the check separately reports product links still on http://, with the https rewrite shown before and after. It does not crawl every URL, and the report says how many it looked at. For connected stores the links are the platform’s current product URLs, regenerated on every sync, so a renamed or deleted product cannot leave a dead link behind in the feed.
Questions merchants ask
The page loads for me. Why not for Google?
Google fetches from US data centres with a crawler user agent and no cookies. Geo-blocking, bot protection, a maintenance page shown to unknown visitors, or a store password all pass your test and fail Google’s. The URL Inspection tool in Search Console shows exactly what Google received.
Why is only the mobile version unavailable?
Google fetches with a smartphone user agent too. A theme that serves a different mobile URL, an app-install interstitial, or a mobile redirect that loops fails that fetch alone.
I deleted the product. Should I leave it in the feed until it clears?
No. Remove it from the feed. A deleted product’s URL will keep failing, and every failing URL counts toward the account-level landing page issue.
Sources
- How to fix: Unavailable desktop landing page — Google Merchant Center Help
- How to fix: Landing page not working — Google Merchant Center Help
- Link [link] — Google Merchant Center Help
- Product issues (Content API for Shopping): the issue codes and the titles Merchant Center shows — Google Merchant Center Help