External URL 5XX Error: What to Do About Failing Outbound Links

This check fires when a page on your site links out to a URL that returns a 5xx status code, meaning the destination's server hit an error while trying to serve the page. The stakes differ from a broken 4xx link in one crucial way: a 5xx is often temporary. The target server may be overloaded, mid-deploy, or briefly down, so the right first move is to verify and monitor before you touch the link.

What a 5xx on an outbound link means

A 5xx is the destination's server admitting its side failed, not that your request was wrong. The common ones: 500 Internal Server Error (an unhandled crash in their app), 502 Bad Gateway (a proxy or load balancer got a bad response from an upstream server), 503 Service Unavailable (down for maintenance or overloaded, usually short-lived), and 504 Gateway Timeout (an upstream took too long). Because these frequently clear on their own, a 5xx sits between a permanent 4xx and a total no-response. The server answered, which rules out DNS and connectivity, but it answered with a failure. Your job is to figure out whether the failure is a blip or a pattern.

A real failing example

You link to a third-party tool's status page and the crawler flags a 503. Confirm it live:

$ curl -sI -A 'Mozilla/5.0' https://api.example.com/status
HTTP/2 503
server: gunicorn/19.9.0
retry-after: 120
content-type: text/html

The 503 plus a Retry-After: 120 header is the destination explicitly telling crawlers "I'm temporarily down, come back in two minutes." That's a strong signal not to remove the link yet. Contrast a hard 502 that persists across checks:

$ for i in 1 2 3; do curl -s -o /dev/null -w "%{http_code}n" https://api.example.com/status; sleep 60; done
502
502
502

Three failures a minute apart, no Retry-After, means this isn't a momentary blip. At that point you treat it like a broken link: find an alternative destination or pull it. The decision hinges on persistence, which is why you sample over time rather than trusting a single crawl.

The 5xx codes and how to read them

How to detect it

1. Screaming Frog, filtered to Server Error. Enable Check External Links, run the crawl, then open the External tab and filter by Server Error (5xx). The Inlinks pane shows which of your pages hosts each flagged link. Note the timestamp, because a single crawl can catch a target mid-restart.
2. curl -I, sampled over time. The 5xx-specific technique is repetition. Run curl -sI -A 'Mozilla/5.0' https://target/url now, in an hour, and tomorrow. Watch for a Retry-After header (temporary) versus a stubborn error that never clears (broken). One check is not enough for a 5xx.
3. Third-party uptime lookup. Before assuming the target is dead, check whether it's an outage on their end via a public status page or an "is it down" service. A widespread outage is nothing you can fix and nothing you should overreact to.
4. GSC won't help for outbound links. Search Console reports 5xx on your own URLs (Pages report, "Server error (5xx)"), which matters for your site's crawlability but says nothing about the external destinations you link to. Use the crawler for those.

How to fix it

1. Verify persistence first. Unlike a 4xx, don't act on a single 5xx. Re-test over hours to a day. Transient 500/502/503 responses clear on their own and need zero action.
2. Honor Retry-After. If the response carries a Retry-After, the destination is telling you it's temporary. Wait it out and re-check rather than editing anything.
3. Escalate only on a stable pattern. When the same URL 5xxs across multiple checks with no recovery, treat it as effectively broken: find a current equivalent or remove the link, same as a permanent error.
4. Prefer stable destinations. If a domain you cite is chronically flaky, that's a signal to link somewhere more reliable for anything load-bearing to your content.
5. Add it to a monitoring loop. Outbound 5xx links are worth a recurring crawl so a temporary outage that becomes permanent gets caught before readers do. See the broader 5xx server errors and SEO guide for how these codes behave.

Frequently asked questions

Should I remove a link the moment it returns a 5xx?

No, and this is the biggest difference from a 4xx. A 5xx is frequently temporary; the server is broken right now but may be fine in ten minutes. Verify persistence across several checks before you decide the link is genuinely dead.

What does Retry-After actually tell me?

It's the destination server explicitly saying "I'm down on purpose or under load, try again after N seconds (or a given date)." Its presence is a strong hint the failure is deliberate and temporary, so honor it and re-check rather than pulling the link.

Does linking to a 5xx page hurt my SEO?

Not in any direct, penalizing way, especially since it's often transient. The real cost is user experience if the outage persists and readers keep hitting a broken destination. Chronic failures also erode the credibility of citing that source.

How do I tell a 5xx apart from a no-response?

A 5xx means the server answered with an error status, so DNS and the connection worked. A no-response means nothing came back at all, pointing at a timeout, refused connection, or DNS failure. If curl prints an HTTP status line, it's a 5xx; if it hangs or errors out with no status, it's a no-response.

The target is a huge site that's clearly up. Why the 5xx?

Big sites throw transient 502/503 during deploys, cache purges, or traffic spikes, and crawlers sometimes catch that exact window. It can also be a bot-specific rate limit dressed as a 503. Re-test as a normal browser and over time before concluding anything. For the permanent variant, compare against the 4xx triage playbook.