Website Not Loading for Customers but Works for You? That Is an Outage

If your website loads for you and not for your customers, your website is down. Not "a bit temperamental". Not "probably their phone". Down, for the people who matter, while every check you run tells you it is fine.

I say this bluntly because the pattern is so easy to dismiss. You open the site on your laptop and it loads. You open it on your phone and it loads. Your hosting dashboard shows green. So when a customer says they could not get onto the booking page, the natural response is to assume the fault is at their end and move on.

That assumption is where the lost business hides. A partial outage produces no alarm, no error email and no angry headline. It produces customers who quietly give up and book with someone whose site did open. You never hear from most of them, because the ones who bother to tell you are the minority.

This article covers the five causes I see most often behind "works for me, not for them", how to verify which one you have, and what a hosting platform should be doing about each.

Your Uptime Monitor Is Asking the Wrong Question

Most uptime monitoring, including the free services many owners set up themselves, asks one question: does the site respond to a request from our checking server? That is a useful question. It is not the same question as "can my customers reach this site".

A monitoring probe sits in a data centre, on a clean network address, with an up-to-date operating system and no corporate firewall in the way. Your customers are on mobile data in a car park, on an office network run by an IT contractor, or on a six-year-old tablet at the kitchen table. Every one of those conditions can break access for them while the probe keeps reporting a healthy production environment.

So the first operational point is simple. A green status page proves the server is up. It does not prove your customers can get in. Treat every "I could not open your site" report as a real incident until you have verified otherwise.

What the customer reports	Who is usually affected	Likely cause
Site times out or refuses to connect, only on mobile data	Customers on one mobile network	A security ban on a shared network address
"Blocked by policy" or a category warning at work	Staff at larger firms and public bodies	Office web filter treating your domain as new or uncategorised
Certificate or "connection not private" error	People on very old phones and tablets	The device no longer trusts your certificate
Red full-screen "dangerous site" warning	Visitors on Chrome, Firefox and Safari	Your domain is on a Safe Browsing list
Old prices, old opening hours, missing page	Everyone except you, or only you	You and they are looking at different copies

Each of those rows has its own section below, because each one needs a different fix.

Cause One: Someone Else Tripped the Alarm on a Shared Address

This is the one that catches owners out most, because it is caused by a security feature working as designed.

Mobile networks do not give every phone its own public internet address. There are not enough to go round. Instead, many subscribers share one public address through a system called carrier-grade NAT, which the IETF describes plainly in RFC 6888: "a public IPv4 address would be shared by many subscribers" ^[1]. To your web server, hundreds of different people can look like one visitor.

Now add intrusion prevention. Tools like fail2ban watch server logs and, in the words of the project's own documentation, ban "IP addresses conducting too many failed login attempts" by updating firewall rules "for a configurable amount of time" ^[2]. That is exactly what you want when a bot is hammering your login page. The trouble is who else shares that address.

The IETF flagged this collateral damage years ago. RFC 6269 notes that with shared addresses, "one user who fails a number of login attempts may block out other users who have not made any previous attempts" ^[3]. One infected phone on a mobile network misbehaves, the address gets banned, and every innocent customer behind the same address hits a closed door.

Consider a composite case built from a pattern that operations teams see regularly. A driving instructor in Carlow gets a run of texts from learners saying the online booking page will not open. The instructor tries it at home on broadband and it works every time. The learners are all on the same mobile network. By the time anyone connects the dots, a week of lesson bookings has gone by text message, phone call, or to a rival instructor whose page happened to load.

How to verify it

Ask the customer two things. Does the site open on Wi-Fi instead of mobile data? And which network are they on? If Wi-Fi works and mobile data fails, and more than one report comes from the same network, you are almost certainly looking at a ban on a shared address. That is a job for whoever runs your server, because the ban list lives there, not in WordPress.

Cause Two: The Office Firewall Has Not Met Your Domain Yet

If you sell to other businesses, public bodies or schools, a large slice of your visitors browse from behind a managed web filter. Those filters sort every domain into categories and block the risky ones. One category many of them block by default is brand new domains, because criminals register fresh domains for phishing and discard them within days.

Palo Alto Networks, one of the larger firewall vendors, documents that a domain is categorised as "newly-registered-domain" when it "has been registered or re-registered (indicating a potential change in ownership) within the last 32 days" ^[4]. Other vendors use their own windows. The effect is the same: for roughly the first month after you register or transfer a domain, some office networks may refuse to show your site at all.

That lands at the worst possible moment. You have just launched, or just rebranded, and you send your new link to a procurement contact. They click it at their desk and get a policy block page. They do not ring to tell you. They assume your business looks dodgy and move to the next supplier on the list.

How to verify it

Ask for a screenshot of what they see. A block page from their own IT system, often mentioning a category or a policy, confirms it. The fix is on their side (their IT team can allow your domain) or simply time. Where you can plan ahead, register a new domain a few weeks before you need to send it to corporate contacts, so the "newly registered" window has closed by launch day.

Cause Three: Old Phones and a Certificate They No Longer Trust

Every secure website presents a certificate, and every device keeps a list of certificate authorities it trusts. When a device's list is too old to include the authority behind your certificate, the browser shows a privacy or certificate error instead of your site.

Let's Encrypt, which issues a large share of the world's free certificates, ran into exactly this with older Android phones. Its compatibility bridge for older devices expired on 30 September 2024, and Let's Encrypt warned that anyone on "Android 7.0 or earlier" might lose access to sites using its certificates ^[5]. At the time of that announcement, Let's Encrypt put the share of Android devices already trusting its newer root at roughly 94%, so somewhere around one Android device in sixteen was on the wrong side of the line, and that figure has shrunk as old handsets are retired.

In practice this affects a thin but real slice of visitors: an older relative's hand-me-down tablet, a cheap phone kept for years, a device in a care setting that never gets updated. For most businesses that group is small. For a business whose customers skew older, it is not trivial.

An honest limitation

Web60 provisions free Let's Encrypt certificates automatically and renews them without anyone touching them. That removes the far more common failure, the expired certificate that takes a whole site offline. It does not rescue a device running Android 7.0 or earlier, and no hosting setting will. The only fix for that customer is a browser that carries its own up-to-date trust list, such as Firefox, or a newer device. Know that before you promise a customer it will work on anything.

Cause Four: A Browser Warning Only Some People See

Google Safe Browsing keeps lists of sites it believes are distributing malware or phishing, and Chrome, Firefox and Safari use those lists to put a red warning screen in front of the site. You will often not see it yourself, particularly if you only ever visit your own site logged in from the same browser, while a new customer clicking from search hits a full-page warning telling them the site is dangerous.

That is a reputation problem as much as a technical one. Very few people click past a red screen. If your site has been compromised, the warning is the symptom and the hidden malware is the cause.

How to verify it

Google's Transparency Report has a Safe Browsing site status page where you can enter your domain and see whether it is flagged. If it is, the site needs cleaning first, then a review request through Search Console. Google's own help pages say a clean site is "typically removed from the list within 24 hours" after the rescan ^[6]. The cleaning is the slow part, not the delisting.

Cause Five: You Are Looking at a Different Copy

Sometimes the site is not broken at all. You and your customer are simply seeing different versions of it. Browsers keep their own copy of pages. Servers keep a cached copy to serve pages quickly. When you are logged into WordPress, you usually bypass that cache, so you see your latest edit while customers still see yesterday's prices, or the reverse.

This one gets its own full treatment in our piece on why website changes are not showing for customers, so I will keep it short. The quick verification step is to open the page in a private browsing window, logged out, on mobile data. That is the closest you can get to seeing what a stranger sees.

How to Diagnose a Partial Outage in Five Steps

When a customer reports they cannot reach your site, work through this in order. It takes ten minutes and it saves you guessing.

1. Capture the evidence. Ask the customer for a screenshot, the time it happened, their device, and whether they were on Wi-Fi or mobile data.
2. Verify from outside. Load the site yourself on mobile data, in a private window, logged out, and compare what you see with their screenshot.
3. Isolate the pattern. If several reports share one mobile network, suspect a banned address; if they come from office desks, suspect a web filter; if they come from old devices, suspect the certificate.
4. Check the public lists. Enter your domain into Google's Safe Browsing site status page to rule a warning screen in or out.
5. Escalate with specifics. Send your host the time, network and error message so they can verify their security logs rather than tell you everything looks fine.

What a Hosting Platform Should Be Doing About This

Strip the marketing away and a platform that handles partial outages properly does four things. It runs intrusion prevention, because an unprotected login page is worse than an occasional false positive. It has people who can look at the ban list and lift a block when a legitimate customer is caught, quickly, in your time zone. It keeps certificates renewing without anyone having to remember. And it scans for malware, so a Safe Browsing flag is caught as an infection rather than discovered by a customer.

Anything less leaves you doing the diagnosis alone. Consider the version without it: a customer rings, you forward the complaint to a support queue in another hemisphere, and three days later you get a reply saying the server is up. It was always up. That was never the question.

Web60 meets those criteria on its Irish-hosted, fail2ban-protected WordPress infrastructure: server-level security hardening with fail2ban intrusion prevention, automatic malware scanning, Let's Encrypt certificates provisioned and renewed automatically, and an Irish-based support team made up of real people rather than an outsourced queue. When you report "it will not load for my customers on this network at this time", the answer comes from someone who can look at the server side of that picture.

One genuine concession. If you are a larger organisation with your own security team who wants to write firewall rules by country, by network and by path through a self-service console, enterprise managed hosts with a full web application firewall suite suit that workload better. That is a real need for some businesses. It is not the need of a driving instructor, a café or a three-person consultancy, who need the sensible defaults to be right and a person to ring when they are not.

Trust the Customer, Then Verify

The habit worth building is simple. When someone says your site will not open, believe them first and verify second. The server being up is the start of the investigation, not the end of it.

Most of these causes are temporary, and most are fixable within the day once you know which one you are dealing with. Keep the five-step check somewhere you can find it, and use it the next time the phone rings with a complaint your own laptop cannot reproduce. If you want the performance side of the picture too, our complete WordPress performance guide for business owners covers how fast the site should be once customers do get in.

Frequently Asked Questions

Why does my website work on Wi-Fi but not on mobile data?

The most common reason is that a security system on your web server has banned a network address shared by many mobile customers. Mobile networks put large numbers of phones behind one public address, so a ban triggered by one misbehaving device can block everyone else on it. Your host can check the ban list and lift the block. Less often, it is a caching or network routing conflict, which your host can also verify from their logs.

How can I see my website the way a customer sees it?

Open a private or incognito window, make sure you are not logged into WordPress, switch your phone to mobile data instead of Wi-Fi, and load the page. That removes your browser's stored copy, your logged-in view that bypasses the server cache, and your home or office network from the picture. It is not perfect, but it is far closer to a stranger's experience than your normal browser.

Why is my new website blocked on my customer's work computer?

Many office web filters block domains registered within roughly the last month, because criminals use fresh domains for phishing. Palo Alto Networks, for example, uses a 32-day window for its newly registered category. Your customer's IT team can allow your domain straight away, or the block will lift once your domain ages out of that category.

Is my website down if an uptime checker says it is up?

Not necessarily for everyone. An uptime checker tests from its own server on a clean network. It will not notice a block on one mobile network, a filter on one office network, or a certificate error on older devices. Treat customer reports as real incidents even when your monitoring shows green.

Why do some old phones show a certificate error on my site?

Devices keep a list of trusted certificate authorities, and very old devices never receive updates to that list. Since 30 September 2024, phones running Android 7.0 or earlier may not trust Let's Encrypt certificates, which a large share of websites use. Installing an up-to-date version of Firefox, which carries its own trust list, or moving to a newer device resolves it.

How long does it take to remove a Google dangerous site warning?

Once the site has been cleaned and you have requested a review through Google Search Console, Google says the site is typically removed from the list within 24 hours of a clean rescan. The cleaning itself takes longer, and the review will fail if any malware remains.

Sources