Desktop and mobile page not working

Merchant Center crawls product pages as desktop and as mobile. When either fetch fails, the item can be disapproved as Product page unavailable, including the desktop or mobile variant of that error. Google’s fix guide is How to fix: Product page unavailable. It lists 404s, bad URL schemes, and regional URLs that do not load, and it tells you to test both desktop and smartphone fetches. Crawl failures are also summarized in Product crawl issues.

Shopify serves one theme to both, with a different viewport. A page can still fail on one device if the theme errors only in that layout, or if a geo app returns a different status.

Shopify causes

The product URL 404s for everyone. Draft, archived, or a deleted handle fails desktop and mobile together. See Destination not working.

The theme throws on one layout. A section that assumes a desktop image, or an app embed that errors in the mobile template, can return 500 only for that crawl. See Product page unavailable.

A market or geo app redirects phones and desktops differently. One hop lands on the product. The other lands on the home page or a country selector. Google expects the product on both.

The mobile link attribute points somewhere else. If a feed sets `mobile_link` to a URL that is not the product, Google’s mobile crawl uses that URL. The Google & YouTube app normally uses the online store URL for both. A custom feed can override it. This app checks the catalog online-store URL, not a separate mobile_link field.

What to change

1. Open the product URL on a phone-sized window and on a wide window. Both should render the product, not a selector and not a 500.
2. If only one layout fails, fix that section or disable the app embed that throws, then publish the theme.
3. Remove geo redirects that send one device type to `/` or to a collection.
4. If you maintain `mobile_link` in a supplemental feed, point it at the same product the desktop link uses.
5. Allow Googlebot and the mobile crawler in robots.txt. See Destination not crawlable.

How PageCop detects it

The app fetches each catalog URL with the PageCop user agent. It does not run a browser at phone width, and it does not read a `mobile_link` attribute from Merchant Center. A shop can turn on a second fetch with the Googlebot smartphone token. That request is labeled and is not from Google. A 404, a bad redirect, or a robots.txt block is Destination not working. A 5xx or a failed fetch is Product page unavailable. Use those issues as the shared cause when Google’s diagnostics split the same URL into desktop and mobile. A failure that exists only on a real phone still needs a manual check in both layouts.

FAQ

Why would mobile fail when desktop works?

Shopify can render a different set of sections by breakpoint, and an app embed can throw only then. Google fetches both. This app’s single fetch can miss a mobile-only error. Check the phone layout when the diagnostics name mobile and this app’s scan is clean.

Does the user agent count as mobile?

The default user agent identifies PageCop. It is one request for the server-rendered page, not Google’s smartphone fetch and not Google’s desktop fetch. Settings can add the Googlebot smartphone token for this shop only. Matching status on that request is evidence, not a substitute for both of Google’s crawlers.