External URL No Response: How to Triage Dead Outbound Links

This check fires when a page on your site links out to a URL that never answers at all: no status code, no headers, nothing. Unlike a 4xx or 5xx where a server responds with an error, a no-response means the connection itself failed. The stakes: these are often dead domains, DNS failures, or hosts that vanished, so a chunk of them are permanently gone, but a chunk are transient network hiccups you shouldn't overreact to.

What "no response" actually means

With a 4xx or 5xx, the destination server received your request and replied, just with a failure code. A no-response means your crawler never got a reply to react to. The usual causes: DNS failure (the domain doesn't resolve, often because it lapsed or was never registered), connection timeout (the host is unreachable and the request hangs until it gives up), connection refused (something is at that address but nothing is listening on the port), or SSL/TLS failure (the handshake breaks, often an expired or misconfigured certificate). This is the "unreachable" bucket, distinct from "server errored" (5xx) and "client error" (4xx). Because DNS-dead domains never come back, no-response links skew more permanent than 5xx, but transient timeouts mean you still verify before acting.

A real failing example

You link to a small tool whose domain quietly lapsed. A normal header check just fails, with no HTTP status to show:

$ curl -sI -A 'Mozilla/5.0' https://nonexistent-zzz-abc123.example/
curl: (6) Could not resolve host: nonexistent-zzz-abc123.example
$ echo $?
6

Exit code 6 is "could not resolve host": the domain no longer maps to an IP. That's a DNS-dead link, and it's almost certainly permanent. Contrast a host that resolves but refuses the connection:

$ curl -sI -A 'Mozilla/5.0' http://example.com:9/
curl: (7) Failed to connect: Connection refused
$ echo $?
7

# and a timeout on an unreachable host:
$ curl -sI --connect-timeout 8 https://192.0.2.1/
curl: (28) Connection timed out after 8001 ms
$ echo $?
28

The exit code tells you the cause. Exit 6 (DNS) and 7 (refused) usually mean permanently gone; exit 28 (timeout) is the one that can be a temporary network or firewall issue worth re-testing. No HTTP status line ever prints, which is the tell that separates this from a 4xx/5xx.

Reading the failure by curl exit code

How to detect it

1. Screaming Frog, no-response filter. With Check External Links on, run the crawl and open the External tab. No-response URLs surface with a status like "Connection Timeout," "DNS Lookup Failed," or a blank/0 status code rather than a numeric HTTP code. The Inlinks pane maps each one back to the pages that link to it.
2. curl with exit codes. The diagnostic that matters here is the exit code, not the HTTP status (there isn't one). Run curl -sI --connect-timeout 10 -A 'Mozilla/5.0' https://target/url; echo $? and read the number: 6 is DNS, 7 is refused, 28 is timeout. That single number tells you permanent-vs-maybe-transient.
3. DNS lookup to confirm a dead domain. For an exit 6, run dig +short target.com or nslookup target.com. An empty answer confirms the domain doesn't resolve, which is about as permanent as it gets.
4. GSC has nothing for outbound links. Search Console can flag your own URLs as unreachable ("Server error" or "DNS" issues in crawl stats), but it never reports on the external destinations you link to. The crawler and curl are your only real tools here.

How to fix it

1. Sort by cause using the exit code. DNS failures (exit 6) and refused connections (exit 7) are almost always permanent; timeouts (exit 28) and TLS errors deserve a re-test before you conclude anything.
2. Re-test timeouts before acting. A single timeout can be a crawler network hiccup, an aggressive firewall, or a slow host under load. Check again from a different network or later before deciding the link is dead.
3. For dead domains, replace with the archived or successor page. Pull the old URL through the Wayback Machine. If the content survived elsewhere, link there; if it's truly gone, find a current equivalent or remove the reference.
4. Watch for expired-certificate cases. A TLS handshake failure often means the site is alive but let its certificate lapse. That's frequently fixed on their end within days, so monitor rather than immediately stripping the link.
5. Fix at the inlinks and re-crawl. Edit the pages carrying each dead link, then re-run the external crawl to confirm the no-response count drops. Lapsed domains accumulate over time, so schedule this as a recurring check.

Frequently asked questions

How is a no-response different from a 5xx?

A 5xx means the server answered, just with an error, so DNS and the connection worked. A no-response means nothing answered at all: the request hung, the domain didn't resolve, or the connection was refused. If curl prints an HTTP status line it's a 5xx; if it fails with an exit code and no status, it's a no-response.

Is a no-response always a permanent problem?

Not always. DNS failures (exit 6) and refused connections (exit 7) usually are permanent. But timeouts (exit 28) and TLS/certificate errors can be transient, caused by a temporary outage, a firewall, or a lapsed cert the owner renews within days. Verify before you delete.

Could this be a false positive from my own crawler?

Yes, especially timeouts. If your crawler runs behind a strict firewall, a low timeout threshold, or an IP that a destination blocks, you'll see phantom no-responses. Re-test the URL manually with a longer --connect-timeout and from a normal network before trusting the flag.

The domain resolves in my browser but the tool says no response. Why?

Common culprits: the crawler used a shorter timeout than your browser, the host rate-limited or blocked the crawler's user-agent at the network layer, or a TLS setting the crawler rejected but your browser tolerated. Reproduce with curl using a browser user-agent and a generous timeout to settle it.

Does a dead outbound link hurt my rankings?

No direct penalty, but a pile of links to vanished domains signals an unmaintained page and gives readers dead ends. It also undercuts the value of citing sources when those sources no longer exist. Treat it as a UX and content-quality fix. For the broader picture, see how to find and fix broken links and the 4xx triage guide.