A site that will not load could be broken for everyone, or broken only for you, and the fix is completely different in each case. Five minutes of checking saves an hour of restarting things that were never the problem.
Is it down for everyone?
Start with an outage checker. Several free services attempt to load a site from their own servers and report back, which immediately separates “the site is broken” from “my connection is broken”.
These sites also carry user reports, which are useful for a different reason: they show whether other people started complaining in the last few minutes. A sudden spike is a real outage. A flat line with your own report on it points back at your setup.
Most large services also run a status page, usually at status. followed by their domain. That is the authoritative source when it exists, though companies are sometimes slow to update it during the first minutes of an incident.
The thirty second local check
- Try a different site. If nothing loads, the problem is your connection, not the site.
- Try mobile data with Wi-Fi off. If it works there, the fault is your home network or your provider.
- Try a different browser, or a private window. This isolates extensions and cached data.
- Try a different device on the same network. That separates one machine’s problem from the whole network’s.
Those four tests identify the layer at fault almost every time, and each takes seconds.
When it works on mobile data but not at home
This pattern usually points at DNS, the system that turns a domain name into an address. If your provider’s DNS is struggling, sites fail to resolve while the connection itself is perfectly healthy.
Clearing the local DNS cache often fixes it. On Windows, open Command Prompt and run ipconfig /flushdns. On macOS the equivalent is a dscacheutil command in Terminal, and restarting is a simpler route for most people.
Changing your device or router to a public DNS resolver is the more durable fix, and is often noticeably faster than a provider’s default.
Reading the error you were given
- 404 — the server is fine; that specific page does not exist. Usually a broken or outdated link.
- 403 — the server is fine but is refusing you. Sometimes geography, sometimes a block.
- 500 — the site’s own software has crashed. Nothing you can do but wait.
- 502 or 504 — one server is waiting on another behind the scenes. Typically a real outage in progress.
- 503 — the site is deliberately unavailable, often maintenance or overload.
- “Server IP address could not be found” — a DNS failure, not a site failure.
- A certificate warning — do not click through it on anything involving an account. It can indicate interception, and on public networks that matters.
The distinction worth remembering: a 404 or 403 means you successfully reached the server, so your connection and DNS are both working.
Reaching a page that is down
If you need the content rather than the site, a cached copy may exist. Web archive services store historical snapshots of a great many pages, which also works for pages that have been deleted rather than merely being offline.
This is worth knowing for reference material, documentation and news that has moved behind a broken link.
If it is your own site
Check in this order, because it goes from cheapest to most alarming.
- Has the domain expired? This is embarrassingly common and produces a total outage with no warning.
- Has the certificate expired? Also common, also abrupt, and it makes browsers refuse the site outright.
- Is the host having an incident? Check their status page before investigating your own code.
- Did something change recently? A deployment, a plugin update, a configuration edit. Recent change is the leading cause.
- Is the disk full? A server out of space fails in confusing, intermittent ways rather than cleanly.
Set up uptime monitoring afterwards. Free services will check a site every few minutes and message you when it stops responding, which is considerably better than learning about an outage from a customer.
Join the discussion