Reviewed November 11, 2026

Mobile-Only 404s: The Page Works on Desktop and Vanishes on Phones

A page that loads on desktop and 404s on mobile is not a broken page. It is a page the two devices are asking for differently. The usual causes are boring and specific: a mobile menu or tap target still calls an old collection URL with a tag filter or sort parameter the theme update dropped, a cached redirect on the phone serves a stale destination, the product was never added to the market the phone is shopping from, or the theme is missing the viewport meta tag and the phone is rendering the desktop layout. The fix starts by reproducing it on a real phone, not in DevTools, then checking the exact URL the phone requested against the exact URL the desktop requested. When they differ, you have found it.

The two devices ask for different URLs

The first thing to understand is that a mobile-only 404 is almost never a broken page. It is a broken link that only mobile follows. When a theme is updated, or collection rules change, or items are pruned in bulk, the desktop navigation menus sync fast. The mobile drop-down elements and tap interaction boxes inside responsive templates often continue calling outdated parameter paths, and the phone hits a dead end the desktop never sees. Responsive layout components condense sorting parameters or append trailing tags that do not replicate on desktop views, so a smartphone browser calls a URL with a tag filter or a sort sub-string that the desktop menu no longer includes, and the server returns 404. The desktop test passes because the desktop menu is current. The mobile test fails because the mobile menu is stale. The fix is to check the mobile menu links in the theme editor, in mobile view, section by section, and to test the tap targets on a real phone, not in the editor preview.

The cache that lies to you

The second cause is caching, and it is the one that makes merchants swear the page works. Your desktop might be loading a cached version, while the phone gets a broken redirect or a 404. Mobile networks cache DNS longer than desktop networks, so a DNS change that has propagated on a laptop can still be stale on a phone for days, and a cached redirect on the phone can keep sending the shopper to a destination that no longer exists long after the redirect was fixed. The test is to open the page in incognito mode on the phone, on mobile data rather than Wi-Fi, which bypasses both the browser cache and the network cache. If it loads in incognito and 404s in a normal tab, the page is fine and the cache is the problem, and the fix is to clear the phone's cache and to check the redirect chain for a stale entry. If it 404s in incognito too, the link itself is wrong.

The market you forgot

The third cause is markets, and it is the one merchants miss most often because they test from their own country. A product that was never added to a market returns a 404 for shoppers in that market, and the merchant testing from their own desk never sees it. One store's product pages worked on desktop and showed nothing on mobile, and the problem turned out to be that the merchant had only checked the abroad market and not the primary market. The fix was to add the products to the international market and the primary market both. The test is to open the store from a VPN in each market you sell in, on a phone, and to check that the product pages load. If you sell internationally, this check belongs in the launch checklist for every new product, not in the debugging session after a customer complains.

The viewport tag and the firewall

The fourth cause is the viewport meta tag, and the fifth is a firewall or CDN rule that blocks mobile user agents. A missing viewport tag does not cause a 404 directly, but it makes the phone render the desktop layout, which looks broken and can make buttons and links behave differently, including sending the shopper to the wrong page. The fix is a single line in theme.liquid, and the test is to open the store on a real phone and check that it renders the mobile layout. A firewall or CDN rule that blocks certain user agents or IP ranges can affect mobile access while desktop works fine, and the fix is to check the hosting or CDN settings and confirm that mobile traffic is not being blocked or throttled. Mobile browsers are also stricter about SSL certificates, so a certificate problem that desktop tolerates can fail on mobile. Check the certificate with SSL Labs if the phone fails while the laptop loads. The order to check is: the exact URL the phone requested, the cache, the market, the viewport tag, then the firewall and the certificate.

Frequently asked questions

Why would a page work on desktop but 404 on mobile?

Because the two devices request different URLs. Mobile menus, tap targets, and cached links often carry old tag filters, sort parameters, or trailing slashes that a theme update dropped, and the phone requests a URL that no longer exists while the desktop menu requests the current one. A cached redirect on the phone can do the same thing. The page is fine; the link the phone follows is stale.

Can a missing viewport tag cause a 404?

Not a 404 directly, but it causes the symptom merchants report as a mobile failure. Without the viewport meta tag, a phone renders the desktop layout, which looks broken and can make buttons and links behave differently, including sending the shopper to the wrong page. One merchant's Taste theme buttons all led to the same banner page on mobile while working on desktop, because the mobile configuration had the wrong URLs.

How do I reproduce a mobile-only 404?

On a real phone, not in Chrome DevTools, in incognito mode, on mobile data rather than Wi-Fi, so you bypass both the browser cache and the network cache. Open the exact link a shopper would follow, from an ad or an email, not by typing the homepage and navigating. Note the exact URL in the address bar when the 404 appears, and compare it character by character with the URL the desktop requests for the same page.

Do markets cause mobile 404s?

Yes, and it is the cause merchants miss most often. A product that was never added to a market returns a 404 for shoppers in that market, and the merchant testing from their own country never sees it. One store's product pages worked on desktop and 404'd on mobile because the merchant had only checked the abroad market and not the primary market. Add the product to every market you sell in, and test from a VPN in each market.