Issue 237

One or more links pointing away from your site answer with an error status code — a 404 because the page has been removed, a 403 because it is now behind a login, or a 5xx because the server it lives on is failing.

A passing page means every outbound external link resolves with a successful status.

Example of a broken external link:

<a href="https://partner.example.com/case-study">Read the case study</a>

• Requested: https://partner.example.com/case-study
• Responded: 404 Not Found

The link still looks perfectly normal on the page. Nothing about it tells a reader it leads nowhere until they click it.

One finding is raised per page, not per link. If a page carries six broken links, that is a single issue listing all six, because the page is the thing you open to fix them.

Reader Trust: A link that leads to a 404 is a dead end in the middle of your content. It is one of the most visible signs that a page has not been maintained, and it costs credibility exactly where you were citing evidence for a claim.

Link Equity Wasted: Links to broken destinations still consume the authority you pass outward, without any of the benefit of pointing at a live, relevant source.

Signals of Staleness: Broken outbound links accumulate on pages nobody revisits. A page dense with them is usually a page whose content is out of date too, and search engines have plenty of other ways to notice that.

Reference Rot: External pages disappear without telling you. An article that was accurate when published can rot over years purely through its citations, which is why this needs checking on a schedule rather than once.

Cheap to Fix: Unlike most content problems, the remedy is mechanical — repoint, replace or remove. It is among the highest-value-per-minute fixes on this list.

Work from the status code — it tells you which of these applies.

404 / 410 — the page is gone

The destination no longer exists.

• Check whether the content moved. Many sites reorganise without redirecting; searching the destination site for the page title usually finds it.
• If it moved, repoint the link.
• If it is genuinely gone, either replace it with an equivalent source or remove the link and leave the sentence standing on its own.
• For a citation you cannot replace, link to an archived copy (https://web.archive.org/web/*/original-url) rather than dropping the evidence.

403 / 401 — the page is behind a wall

The page exists but will not serve your reader, or will not serve an automated request.

• Open it in a private browser window. If it loads for you, it is likely refusing automated requests rather than being broken — but note that it is also refusing search engine crawlers, so the link passes nothing on.
• If it now requires a login or a subscription, say so in the link text so a reader can decide before clicking.

5xx — the destination server is failing

Usually temporary.

• Re-check before acting. A single failing scan is not evidence of a dead page.
• If it persists across several scans, treat it as gone and follow the 404 advice.

429 — you are being rate limited

Not a broken link. The destination is throttling repeated requests. If a scan reports many 429s from one host, that host is rate limiting the scan rather than serving errors to your readers.

Preventing recurrence

• Schedule scans so reference rot is caught while it is one or two links, not fifty.
• When citing something likely to move, prefer a stable URL — a DOI, a permalink, or a documentation page with a version in the path.

A removed page

<p>
  Our methodology follows the approach described in
  <a href="https://research.example.org/2019/method">this 2019 paper</a>.
</p>

https://research.example.org/2019/method → 404 Not Found

Fixed — repointed at the paper's DOI, which does not move:

<p>
  Our methodology follows the approach described in
  <a href="https://doi.org/10.1000/182">this 2019 paper</a>.
</p>

A page now behind a login

<a href="https://news.example.com/article/12345">the original report</a>

https://news.example.com/article/12345 → 403 Forbidden

Fixed — the link stays, but the reader is told what to expect:

<a href="https://news.example.com/article/12345">the original report</a>
(subscription required)

A source that cannot be replaced

<a href="https://oldvendor.example.com/spec.pdf">the original specification</a>

https://oldvendor.example.com/spec.pdf → 404 Not Found

Fixed — archived copy, so the citation survives the source:

<a href="https://web.archive.org/web/2019/https://oldvendor.example.com/spec.pdf">
  the original specification (archived)
</a>

Not a broken link

<a href="https://api.example.com/status">service status</a>

https://api.example.com/status → status recorded as 0 (connection timed out)

No issue is raised. The request never completed, so there is nothing to conclude about the page — see How PixyScan detects this.

PixyScan checks outbound links after the crawl has finished, not during it:

1. Collects external links — while crawling, every <a href> pointing to a different host than the site being scanned is recorded against the page it was found on, along with its anchor text.

2. Requests each destination — once the crawl completes, each distinct external URL is requested with a HEAD, which asks only for the response headers and not the body. A 10 second timeout applies.

3. Retries with GET on 405 — some servers reject HEAD outright with 405 Method Not Allowed. Treating that as broken would be wrong, so those URLs are requested again with a GET, also with a 10 second timeout.

4. Records the status — the resulting status code is stored against the link. A request that never completed at all — DNS failure, connection refused, timeout — is recorded as 0 rather than being guessed at.

5. Raises one issue per page — links whose status is 400 or above are grouped by the page they appear on, and one finding is created for that page listing each broken destination with the status it returned.

Links that could not be reached at all (status 0) are recorded but do not raise this issue. A transient DNS failure or a server that refuses automated requests is not the same as a page that is genuinely gone, and reporting it as such produces findings that resolve themselves by the next scan.