How do I tell if a website is down or just blocking me?
Distinguishing a real outage from bot protection, geoblocking or a network problem — and what each failure mode looks like.
Read the failure carefully. A connection that never establishes is usually a real outage or DNS problem. An HTTP response that arrives and refuses you — 403, 429, or a challenge page — means the server is healthy and has decided about you specifically.
The failure tells you where it happened
| What you see | Layer | Usually means |
|---|---|---|
could not resolve host | DNS | Domain expired, records deleted, or your resolver is broken |
connection refused | TCP | Host reachable, nothing listening on that port |
connection timed out | TCP | Packets dropped — firewall, or the host is gone |
| TLS handshake failure | TLS | Certificate or protocol mismatch, not an outage |
403 Forbidden | HTTP | Server is fine. It has decided about you. |
429 Too Many Requests | HTTP | Rate limited. Healthy, and asking you to slow down. |
503 Service Unavailable | HTTP | Overloaded or in maintenance. Usually temporary. |
200 with a challenge page | HTTP | Bot protection. The most misleading of the set. |
The last row deserves attention because it defeats naive monitoring: the status code is 200, the response has content, and a checker that only reads status codes will report the site as perfectly healthy while every automated client is being turned away.
Working through it
# 1. Does the name resolve?
dig +short example.com
# 2. Does the port accept a connection?
nc -vz example.com 443
# 3. Does TLS complete?
echo | openssl s_client -connect example.com:443 -servername example.com 2>&1 | head -5
# 4. What does HTTP actually say?
curl -sI -o /dev/null -w '%{http_code}\n' https://example.com
# 5. Does it treat a browser differently?
curl -sI -o /dev/null -w '%{http_code}\n' \
-A 'Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36' \
https://example.comStep five is the decisive one. If a default user agent gets 403 and a browser user agent gets 200, the site is up and filtering automated clients. That is a finding about their edge configuration, not about their availability.
Is it just you?
- Try another network. Mobile data instead of office wifi separates a local problem from a global one immediately.
- Try another DNS resolver.
dig @1.1.1.1 example.comagainst your default. A difference points at your resolver or at incomplete propagation. - Check for geoblocking. Some sites refuse entire regions. Consistent 403s from one location and 200s from another is the signature.
- Check your IP reputation. Shared hosting, VPNs and cloud ranges are frequently blocked wholesale, regardless of what you are doing.
Why this matters for automated measurement
An audit that cannot distinguish these will produce actively misleading results. A blocked check is not a failed check — the site may be immaculately configured behind the block. Reporting it as a failure invents problems; reporting it as a pass invents reassurance.
The correct handling is a third state: the check is recorded as undetermined with reason blocked, excluded from scoring in both directions, and reported so the reader knows why coverage is incomplete. If a site suddenly shows several such entries where it previously had none, bot protection was almost certainly enabled — which is a fact worth surfacing rather than a regression to panic about.
What our audit reports about this
Every item below is measured directly, not inferred. Run it against your own site and the result names the exact rule or header responsible.
- Failures classified by layer — DNS, connection, TLS, HTTP — rather than reported as a single generic error.
- Blocked and timed-out checks recorded as undetermined with the reason, excluded from scoring in both directions.
- Challenge pages returning 200 distinguished from genuine content, so bot protection is not mistaken for a healthy response.
- An honest user agent on every request, with no spoofing to work around a site's access decisions.
For agents and scripts, the same measurement is at
/api/v1/infra?url=yoursite.com —
see the API documentation.
Related questions
Why does my site work in a browser but fail an audit?
Bot protection, almost always. Many WAF configurations challenge or block non-browser clients by default. The site is healthy; automated clients — including AI crawlers you may want — are being turned away.
Should I whitelist auditing tools?
If you want automated measurement of your own site, allowing an honest, identifiable user agent is reasonable. Be aware that the same rules blocking an auditor are often blocking AI crawlers, which is worth knowing regardless.
Is a 403 ever a real outage?
It is a real failure for you and not an availability problem for the site. The server received your request, processed it and declined — which is the behaviour of a working server, correctly or otherwise.
How do I check if only I am affected?
Switch networks — mobile data versus wifi is the quickest test. If the site loads on one and not the other, the problem is your network, your IP reputation or your resolver rather than the site.
Read next
What should an AI agent do when it cannot determine something?
Why "not checked" and "passed" must never be the same answer, and how a well-built tool keeps them apart.
ReadWhat is a CDN and how do I tell if I am behind one?
How to detect a CDN from response headers, and why it changes what an audit of your site is actually measuring.
ReadHow do I audit a website I don't own?
What is legitimate to measure on someone else's site, where the line is, and how to do it without being a nuisance.
ReadWhy did my website score change when I did not change anything?
The four causes of an unexplained score movement, and how to tell which one you are looking at in under a minute.
Read