Why Is My Website Down on Mobile but Not Desktop: The Four Differences That Explain It

If your website loads on your desktop but not on your phone, the site is almost certainly not down. Two devices looking at the same domain take four different paths to reach it, and one of those paths is holding stale or broken information. The four differences are the network, the DNS resolver, the cache, and the connection the browser is willing to negotiate, and identifying which one is at fault takes about two minutes.

This article gives you the tests that isolate each difference in turn, explains why a recent DNS or certificate change makes this symptom overwhelmingly likely, and covers the one scenario where the site genuinely is down and only some visitors can tell.

The two minute test that narrows it immediately

Turn wifi off on the phone and try again on cellular. This is the single most informative test available, because it changes the network and the DNS resolver at once while keeping the device, browser, and cache identical. If the site loads on cellular and fails on wifi, the problem is the wifi network you were on. If it fails on both, the problem is the device or the site.

Open the site on someone else's phone. A second device on the same network isolates your handset. If their phone works and yours does not, the fault is local to your device: a cached DNS entry, a stale certificate state, a VPN profile, or a content blocker.

Load the site in a private browsing window. Private mode bypasses much of the browser's stored state and disables most extensions and content blockers. A site that loads privately and fails normally is being broken by something the browser is holding.

Check it from outside your own devices entirely. Run the URL through an external checker such as our website down checker to see what a neutral client on a different network receives. If a third party loads it fine, you have confirmed the site is up and the investigation belongs on your side.

Why DNS is usually the answer

The most common version of this problem follows a DNS change. When you point a domain at a new server, every resolver on the internet keeps the old answer until its cached copy expires, and that expiry is governed by the record's time to live. Your desktop, sitting behind an office router that already refreshed, gets the new address. Your phone, on a mobile carrier whose resolver caches aggressively and refreshes on its own schedule, keeps handing back the old one. The site is not down anywhere. Two devices are simply looking at two different servers, one of which no longer serves the site.

This explains several things people find baffling. It explains why the problem clears itself after a few hours without anyone doing anything. It explains why colleagues in the same office all see one result and everyone on their phones sees another. It explains why a customer in another country reports an outage that nobody on your team can reproduce. Mobile devices also switch resolvers constantly as they move between carrier networks, home wifi, and public hotspots, so a phone can genuinely show you a different answer in the afternoon than it showed in the morning. Our guide to DNS lookup covers how to query a specific resolver directly, which is how you prove this rather than guess at it.

The differences that are not DNS

Once DNS is ruled out, three other asymmetries remain. The first is transport security. Older phones carry older trust stores and support older TLS versions, so a certificate whose chain is incomplete, or a server configuration that dropped support for an older protocol, can fail on a five year old handset while working perfectly on a current laptop. A site that fails on one specific old device and works everywhere else is usually a certificate chain problem rather than an outage, and it will affect a slice of your real audience silently.

The second is the mobile-specific delivery path. Sites with a separate mobile subdomain, a device-detecting redirect, or a CDN configuration that varies by user agent have a code path that only phones execute, and it can break independently of everything else. The third is the network itself: corporate wifi with content filtering, a captive portal that has not been accepted, a VPN profile routing traffic somewhere unhelpful, or a mobile carrier with a routing problem to your host's region. Each of these produces an outage that is entirely real for the affected visitor and entirely invisible from your desk.

When it is actually down and only some people know

There is one scenario where the site really is broken and the split you are seeing is genuine rather than illusory. Content delivery networks and multi-region hosting serve visitors from the nearest edge, which means a failure at one edge takes the site down for everyone routed to it while everyone else sees no problem at all. If your desktop resolves to a healthy edge and your phone on a different network resolves to a broken one, both observations are correct and the site is partially down.

This is the case a single monitoring check cannot detect. Checking from one location tells you whether the site is up at that location, which is a much smaller claim than it sounds like. A regional edge failure, a routing problem affecting one continent, or a DNS record that propagated to some resolvers and not others all present as healthy to a check running from the wrong place. The only way to see the split as it happens is to check from several places at once and compare, which is why global check locations exist and why the number of them matters more than most feature lists suggest.

Common mistakes in diagnosing a mobile-only outage

Assuming the site is down because one device says so. A single device is a single vantage point. Before telling anyone the site is down, confirm it from a different network and from an external checker.

Clearing the browser cache and stopping there. Browser cache is one of four differences, and rarely the deciding one. If clearing it does not help, move to the network and DNS tests rather than clearing it again.

Ignoring a recent DNS change. If anyone touched a DNS record in the past forty eight hours, that is the first suspect, and the symptom of some devices working and others not is exactly what a partially expired cache produces.

Testing only on modern hardware. Older phones carry older trust stores and older TLS support. A certificate or protocol problem that spares every device in your office can still be failing for a real share of your visitors.

Treating a regional edge failure as a false alarm. When some visitors genuinely cannot reach the site and others can, both reports are accurate. Checking from a second location settles it faster than arguing about it.

FAQ

Why does my site load on wifi but not on mobile data?

The two networks use different DNS resolvers and different routes. Most commonly one resolver still holds an outdated address after a DNS change, so the two connections reach different servers.

How long does it take for DNS changes to reach mobile carriers?

It depends on the record's time to live and on how aggressively the carrier caches. Some resolvers refresh within minutes and others hold answers considerably longer, which is why the same change reaches some devices hours before others.

Could an SSL certificate cause a site to fail only on phones?

Yes. Older devices carry older trust stores and support fewer TLS versions, so an incomplete certificate chain or a dropped protocol can fail on an older handset while a current laptop connects without complaint.

How do I prove the site is up when only my phone says otherwise?

Check it from a service outside your own network and devices. A neutral external check that succeeds confirms the site is reachable and moves the investigation to your device, network, or resolver.

Closing thought

The instinct when a site fails on one device is to conclude the site is broken, and that instinct is wrong far more often than it is right. Two devices are two different journeys to the same address, and the interesting question is never whether the site is up but which leg of which journey is carrying old information. Test the network first, DNS second, and the device last.

The uncomfortable version of this problem is the one where the split is real and nobody on your team is on the wrong side of it. Odown checks your site from seventeen locations across North America, Europe, Asia, and South America simultaneously, so a failure affecting one region shows up as a failure rather than as a rumour from a customer. If you would rather see a partial outage on a dashboard than hear about it in a support ticket, website monitoring starts at twelve dollars a month with a fourteen day trial.