English 
French 
There’s a specific kind of stuck you get into when a site won’t load. You refresh. You refresh again. You start wondering whether it’s the site, your Wi-Fi, the router, that browser extension you installed last week, or something you did.
Ten minutes disappear this way, and at the end of them you still don’t know.
The diagnosis doesn’t need ten minutes. It needs about one, if you run the checks in the right order. Here they are, roughly fastest to slowest, and you can usually stop after the first or second.
1. Run an external check (5 seconds)
Paste the URL into CheckSiteStatus. The request goes out from a server that shares nothing with your laptop: different network, different ISP, different DNS resolver, possibly a different country.
Two possible answers, and they split the entire problem in half.
Site responds for us, not for you. The server is fine. Something between your device and it is broken. Keep reading from step 3.
Site doesn’t respond for us either. It’s genuinely down. Nothing on your end will fix it. Skip to step 6.
This one check eliminates about 90% of the guesswork, which is why it goes first rather than after you’ve already restarted your router twice.
2. Try it on mobile data (10 seconds)
Turn Wi-Fi off on your phone and load the site over cellular.
This isolates your network completely. Different connection, different DNS, different route to the internet. If the site loads on mobile data and not on your Wi-Fi, the fault is in your home or office network: the router, the ISP, a DNS setting, or a filter somewhere on the line.
If it fails on both, and the external check said the site was up, the problem is likely your ISP or something further upstream rather than your local hardware.
3. Open a private window (5 seconds)
Ctrl+Shift+N in Chrome, Ctrl+Shift+P in Firefox.
Private windows skip most cached content and, by default, run without extensions. If the site loads here and not in your normal window, you’ve found it: either a cached broken page, or an extension interfering with the request. Ad blockers and privacy extensions are the usual suspects, and they break more sites than people realise because a blocked script can stop a page rendering entirely.
Disable extensions one at a time to find the culprit. Start with anything that filters requests.
4. Flush your DNS cache (20 seconds)
If a site changed hosting recently, your computer may still be holding the old IP address and knocking on a door that isn’t there anymore.
Windows: open Command Prompt and run ipconfig /flushdns
macOS: sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
Then try again. If that doesn’t do it, switch your DNS to a public resolver: 1.1.1.1 (Cloudflare) or 8.8.8.8 (Google). Your ISP’s resolver having a bad day is more common than most people assume, and it produces a failure that looks exactly like the site being down.
This step is also where you catch the case where the site genuinely has a DNS problem: expired domain, nameservers pointed somewhere wrong, or a missing record after a migration. The error you get in the browser tends to be vague about which side is at fault, which is why “this site can’t be reached” is one of the most frustrating messages to troubleshoot without a second opinion.
5. Turn off the VPN and check the network you’re on (10 seconds)
If you’re on a VPN, disconnect and retry. VPN exit nodes get blocked by site firewalls all the time, usually because someone else on that IP range did something abusive. You inherit the ban without doing anything wrong.
Corporate and school networks add their own layer. Content filters block whole categories, and the block page sometimes looks like a generic connection error rather than an obvious “this is blocked” message.
Geo-restrictions work the same way in reverse: if your VPN exits in a country the site doesn’t serve, you’ll get blocked while everyone around you loads it fine.
6. Check the status page and the crowd (15 seconds)
If the external check said the site is down for everyone, the remaining question is just how long it’ll last.
Large services publish status pages, and they’re usually updated within twenty minutes of a significant incident. Social platforms tend to get reported faster on other social platforms than on their own status page, for obvious reasons. When a major service goes down, the volume of people asking about it is itself the confirmation you needed. This is why “is Instagram or WhatsApp down” spikes into the search charts within minutes of an incident starting.
For your own site, the equivalent is your host’s status page. Check it before you start debugging your code, because if their platform is having an incident there is nothing in your application to fix and you’ll waste an hour proving it.
The 60-second version
| Result | What it means | Do this |
|---|---|---|
| Up externally, down for you | Local problem | Private window, flush DNS, try mobile data |
| Down on Wi-Fi, up on mobile | Network or router | Restart router, change DNS resolver |
| Works in private window | Cache or extension | Clear cache, disable extensions |
| Fixed by disabling VPN | IP blocked or geo-restricted | Use a different exit node, or none |
| Down externally too | Real outage | Check status page, wait |
| DNS won’t resolve | Domain or nameserver issue | Check registration and DNS records |
When the answer is “it’s down for some people”
There’s a seventh case that doesn’t fit the binary, and it’s the one that generates the most confused support tickets.
Sometimes a site is up for you and down for a colleague two desks away. Or working across Europe and failing in Asia. Regional CDN failures, BGP routing problems, and partial cloud incidents all produce this. So does DNS propagation after a migration, where different resolvers around the world update at different rates for a day or more.
If reports contradict each other, that’s the signal. Test from a couple of different locations rather than assuming one of the reporters is confused.
If it’s your site that’s down
The external check gives you more than up or down. It gives you what the server said, and that’s the fastest route to a cause.
A 500 points at your application code. A 502 or 504 points at whatever runs behind your web server. A 503 usually means overload or a maintenance mode flag someone forgot to turn off. A 403 is a firewall or permissions rule, not a code problem.
If your site sits behind Cloudflare, you get a more specific set: 521, 522 and 523 errors each point at a different part of the connection between Cloudflare and your origin server, which narrows things considerably compared to a generic gateway error.
Whatever the code, note the time. Log entries are much easier to find when you know the minute to look at.
Run the URL through an external checker like CheckSiteStatus. It tests from outside your network entirely, so its answer is independent of your browser, router, ISP and DNS. If the tool reaches the site and you can’t, the problem is on your side. Loading it on mobile data confirms this in a few seconds.
The most common causes are a cached broken page, a browser extension blocking a required script, a stale DNS entry pointing at an old server, a VPN exit IP that the site has blocked, or a filter on your network. Working through a private window, a DNS flush, and a different network isolates almost all of these.
If other sites load normally, your internet is working and the problem is specific to that one site. If nothing loads, it’s your connection. That single comparison is the fastest test available and takes about three seconds.
The server is responding but something is struggling, usually a database query, an overloaded server, or a slow third-party script the page depends on. It often precedes an actual outage by an hour or two, which makes it worth paying attention to rather than waiting out.
Neither. Run an external check first, because it tells you whether the problem is even on your side. Restarting the router is a slow fix for a problem you haven’t diagnosed yet, and it’s the step people reach for first purely out of habit.
The short version
One external check, one mobile data test, one private window. That’s under thirty seconds and it resolves the question almost every time.
The router restart can wait until you actually know it’s the router.