Why Can't I Access a Website That Works for Everyone Else?

You type the address and get "This site can't be reached". A colleague opens the same link, and it loads straight away. Or a client tells you their site is down, and on your screen it's fine. Both of you are telling the truth.

Whether a site is down for everyone or just you depends on several factors. A visit to a website involves multiple steps, and each one can behave differently depending on your network connection, internet service provider, or device. Once you understand those steps, you can determine in a few minutes whether it's a widespread outage or an issue on your end and take the appropriate steps to resolve it.

In this guide:

• What happens between typing a URL and seeing the page
• Six reasons a website is down for you but not for others
• How to check whether a website is down for everyone, in six steps
• If your own website is not loading for some visitors
• Frequently asked questions

What happens between typing a URL and seeing the page

1. DNS lookup: Your device asks a resolver (usually your ISP's, or a public one you chose) for the site's IP address. The answer can come from a cache, and a large site can intentionally return different answers in different places.
2. Routing: Your traffic crosses several networks to reach that address. The path from one ISP can be very different from the path from another.
3. The edge or the origin: Many sites sit behind a CDN, so you're usually talking to a nearby edge server, not the main server.
4. TLS: Your browser checks the site's certificate before anything loads.
5. The application: The server builds the page. It can answer quickly and still send the wrong thing.

A failure at any one of these steps can affect some visitors and not others.

Six reasons a website is down for you but not for others

When you can't access a website that other people open without trouble, the cause is almost always one of these.

1. DNS answers that don't match

After a server move or a DNS change, resolvers keep the old answer until its TTL (time to live) runs out. If the old record had a TTL of 86,400 seconds, some people can be sent to the old server for up to a day. Different resolvers also refresh at different times, which is why "it works on my phone but not on my laptop" is so often DNS. In Chrome, a lookup that fails completely shows up as "This site can't be reached" with the code DNS_PROBE_FINISHED_NXDOMAIN.

2. One CDN edge in trouble

A CDN serves visitors from the edge closest to them. If one edge location has a bad configuration or a stale cache, only the people routed to it see the problem. Everyone else is fine.

3. Routing and ISP problems

Sometimes the server is healthy, but the path to it isn't. A peering problem between one ISP and the host can make a site unreachable for that ISP's customers only. Chrome usually reports this as ERR_CONNECTION_TIMED_OUT, and a traceroute that stops at the same hop every time is the clue.

4. Firewalls, geoblocking, and bot protection

Country blocks, rate limits and bot checks often treat some IP ranges differently. Visitors on a VPN, a corporate network, or a cloud server can be blocked or challenged, while normal home connections get through. A site can also block a single IP address after too many failed logins.

5. Your own machine

A cached redirect in the browser, an old entry in the hosts file, a browser extension or a VPN that's still switched on can all make a healthy site look broken. So can a proxy at work.

6. The site is up, but broken

The server answers, the page loads, and the checkout button is gone. Or a plugin update broke the layout, or an error page comes back with a success status code. Ping tests and simple checkers still report the site as up, even though visitors can't buy anything.

How to check whether a website is down for everyone, in six steps

Step 1: check the website from different locations

Use a checker that requests the page from multiple regions and shows the result for each. For example, a website checker such as Visual Sentinel requests the page from different regions and reports whether it answered normally, how long it took, the DNS lookup time, and whether the SSL certificate is valid. If every region reaches the site, it's not down for everyone. If some regions reach it and others don't, it's a partial outage, and that points away from your own machine.

Step 2: run a quick DNS propagation check

Ask two public resolvers for the address and see whether they agree:

dig @1.1.1.1 example.com A +noall +answer

dig @8.8.8.8 example.com A +noall +answer

On Windows, use nslookup example.com 8.8.8.8. The number in the answer is the TTL in seconds: how long that answer can stay cached. If the two resolvers return different addresses and the site doesn't use location-based DNS, a recent change probably hasn't reached every resolver yet.

Step 3: check who the IP address belongs to

Run the address you got through an IP lookup tool, such as the one on this site. If it belongs to the site's old host rather than its current host or CDN, the DNS answer is stale. Its location also tells you roughly where your traffic is going.

Step 4: trace the route

traceroute example.com on macOS and Linux (or tracert example.com on Windows) shows each hop on the way. mtr -rw example.com runs the same test repeatedly and shows packet loss per hop. If every test stops at the same network, the problem is on the route, not the server.

Step 5: read the response directly

curl -sS -o /dev/null -w "%{http_code} %{time_total}s\n" https://example.com/

curl -I https://example.com/

The first command prints the status code and the total time. The second shows the headers, including redirects and, often, which CDN edge answered. To test one specific server while skipping DNS, pin the address with curl --resolve example.com:443:203.0.113.10 https://example.com/ (replace the IP with the one you want to test). To check when the certificate expires:

openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | openssl x509 -noout -dates

Step 6: switch networks

Turn off Wi-Fi on your phone and load the site over mobile data, or use a VPN that exists in another country. If the site works there, the problem sits between your usual network and the site.

If it turns out to be your own cache, clearing it usually fixes it: ipconfig /flushdns on Windows, or sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder on macOS. Then restart the browser.

Reading the results

What you see	Likely cause	What to do next
Every region fails	Origin server, DNS, CDN, hosting or firewall	Check the server and host status, recent deploys and DNS records
Some regions fail	Regional routing, a CDN edge, DNS propagation or geoblocking	Compare DNS answers and traceroutes from the failing region
Every region works, but you can't load it	Local DNS cache, ISP route, browser cache, or a firewall on your side	Flush DNS, try another network, check the hosts file and VPN
It loads, but looks wrong	A bad deploy, plugin update, failed script or injected code	Compare with a known-good version and check recent changes

If your own website is not loading for some visitors

When your own site works for you and fails for some visitors, the same six causes apply, and you're the one who has to find them. A monitor that checks from a single place inherits that place's blind spots. A short network hiccup near the monitor triggers an alert at 3 a.m. for a site that never went down, and after a few of those, people start ignoring the alerts. Meanwhile, a real outage that only hits another region goes unnoticed because the monitor's own route is fine.

The fix is to check from more than one location and to confirm a failure before alerting anyone. A failure seen from two places is worth waking up for. A failure seen from one place is worth a second look first. The check interval matters too: a check every minute catches short outages that a 5-minute check can miss, but it only helps if someone can act on the alert that fast.

For example, website monitoring tools such as Visual Sentinel perform checks to assess website availability and performance. When a check fails, a second check may be used to confirm the issue before triggering an alert. These checks can verify whether the site loads, the server responds, and specific keywords remain visible on the page. Some monitoring tools also provide DNS and performance monitoring, as well as SSL certificate and domain expiration alerts.

Website monitoring also helps identify the "up, but broken" problem from reason 6. Visual monitoring captures the page a visitor sees and compares it with the last good capture, so it can detect a missing section, a broken layout, or an injected script even while the page is still loading.

Alerts can be delivered through various channels, including email, browser push notifications, Slack, Discord, Microsoft Teams, Telegram, WhatsApp, PagerDuty, Opsgenie, webhooks, or Prometheus Alertmanager, as well as iOS and Android apps. Uptime checks can run at different intervals depending on the monitoring tool and configuration, helping website administrators identify potential issues.

FAQ

Frequently asked questions

01Why does a website work on my phone but not my computer?

If your phone is on mobile data, it uses a different network, resolver, and route, so a DNS cache, ISP route, or firewall rule on your home or office network can block the computer only. If both are on the same Wi-Fi, look at the computer itself: its DNS cache, hosts file, browser extensions, VPN or security software.

02Can a website block just me?

Yes. Sites block by IP address, and some block whole countries, networks, or VPN ranges. Look up your own IP address to see which network and country it belongs to, then try from another network. If the site loads there, your address or network is probably the one being blocked.

03How long does DNS propagation take?

It depends on the TTL of the old record. Resolvers can keep a cached answer until its TTL runs out, which is often between 5 minutes and 24 hours. If you're planning a move, lower the TTL a day or two before the change so the switch-over is quicker.

04Is it down for everyone or just me?

Check the site from at least two outside locations (step 1). If every location reaches it, the problem is on your side. If none do, it's most likely down for everyone.