External Links Returning 4XX: How to Triage and Fix Them

This check fires when a page on your site links out to a URL that returns a 4xx status code, meaning the outbound link is broken from the client side: the resource is gone, forbidden, or was never there. The stakes are mostly UX and trust: readers hit a dead end, and a page riddled with broken external links reads as unmaintained to both users and, at the margins, to search engines assessing quality.

What a 4xx on an outbound link means

A 4xx is the server telling you the request was the problem. The most common ones on outbound links are 404 Not Found (the page moved or was deleted), 410 Gone (deliberately removed, permanent), 403 Forbidden (access denied, often paywalls or geo-blocks), and 401 Unauthorized (login required). These are permanent-ish client errors, which is the key distinction from a 5xx server error (the target's server is broken, possibly temporary) or a no-response timeout (nothing answers at all). A 4xx almost always means the destination genuinely isn't coming back at that URL, so the fix leans toward replace-or-remove rather than wait-and-see.

A real failing example

You link to a documentation page that got restructured. A quick header check tells the whole story:

$ curl -sI -A 'Mozilla/5.0' https://developer.mozilla.org/this-page-does-not-exist-404
HTTP/2 404
server: Google Frontend
content-type: text/html; charset=utf-8

That's a clean, permanent 404. Before you rip the link out, check whether the destination just moved. Follow redirects and look for the real page:

$ curl -sIL -A 'Mozilla/5.0' https://old.example.com/docs/setup
HTTP/2 301
location: https://example.com/guides/setup
HTTP/2 200

If a 301 chain lands on a live 200, update your link to the final destination. If the header check returns a bare 404 or 410 with no redirect, the resource is gone; find a current equivalent or remove the link. For a 403, verify from a second network or user-agent, because some hosts block bots but serve humans fine, which would make it a false positive.

Which 4xx code means what

How to detect it

1. Screaming Frog, external response codes. Run the crawl with Configuration → Spider → Crawl → "Check External Links" enabled. When it finishes, open the External tab and filter by Client Error (4xx). Then use the lower Inlinks pane to see exactly which of your pages carries each broken link, so you know what to edit.
2. curl -I on the suspect URL. The fastest confirmation: curl -sIL -A 'Mozilla/5.0' https://target/url. The -L follows redirects so you see whether it resolves to a live page or dead-ends on the 4xx. Spoofing a browser user-agent also flushes out bot-only 403 false positives.
3. Manual browser check for 403/401. Access-denied codes are the ones that lie. Open the URL in a normal browser (and ideally a second location or incognito). If it loads for you, the "error" is a bot block, not a broken link.
4. GSC is not your tool here. Search Console reports on your URLs, not the external ones you link to. Don't expect the Pages report to surface outbound 4xx; that's what the crawler is for.

How to fix it

1. Triage by code. 410 and confirmed 404 mean gone: replace or remove. 403/401/429 mean verify first, because a chunk of these are false positives from bot-blocking or rate limits.
2. Chase the redirect before deleting. A surprising share of "broken" links just moved. Run the URL through curl -IL or the Wayback Machine to find where the content lives now, and point your link there.
3. Replace, don't just strip. If you linked to a resource because it supported a claim, find a current authoritative equivalent. Deleting the link leaves the claim unsupported.
4. Fix it at the source of the inlinks. Use the crawler's inlinks data to edit the actual pages carrying the link. One dead external URL can be referenced from a dozen posts.
5. Re-crawl to confirm. After edits, re-run the external-link crawl and confirm the 4xx count drops. Broken links breed, so make this part of a recurring audit, not a one-off.

Frequently asked questions

Do broken outbound links hurt my rankings?

There's no confirmed direct ranking penalty for linking to a 404. But a page full of dead external links signals staleness and poor maintenance, degrades user experience, and wastes the trust you built by citing sources. It's a quality-and-UX problem worth fixing on its own merits.

Is a 404 different from a 410 for my purposes?

Practically, both mean the destination is gone. A 410 Gone is the site explicitly saying "removed on purpose, don't come back," while a 404 can occasionally be temporary or a misconfiguration. Either way your action is the same: find a replacement or remove the link.

The tool flags a 403 but the page opens fine in my browser. What gives?

That's the classic false positive. Many sites (news, retail, anything behind Cloudflare) serve a 403 to automated crawlers while serving humans normally. Verify in a real browser; if it loads, leave the link alone. Re-test 429 rate-limit hits the same way.

Should I add rel="nofollow" to fix this?

No. nofollow changes how link equity flows; it does nothing about the link being broken. The reader still hits a dead page. Fix the URL or remove it.

How is this different from a 5xx or no-response flag?

A 4xx is a permanent client-side "not here." A 5xx means the target's server broke and might recover, so you monitor before acting. A no-response means nothing answered at all, pointing at DNS, timeouts, or a dead host. Different causes, different playbooks. For internal broken links, see broken external links and how to find and fix broken links.