What a Broken-Backlink Report Actually Checked

A broken-backlink report is a join between two things your vendor knows: a set of links pointing at URLs on your domain, and the last status code its crawler received when it requested those URLs. Every row means one crawler got one response at one moment. That is a useful signal and a much weaker claim than the interface implies.

Read it as a list of candidates, never as a list of facts. The rate of rows that don’t survive a manual check is high enough that reporting the raw count is a mistake.

What the check consists of

The vendor requests the target URL with its own user agent, from its own infrastructure, on its own schedule, and stores what came back. Sometimes it also stores whether the linking page was still fetchable. Those are two different columns and conflating them produces the most common misreading of the report.

Two distinct things get called “broken”:

• The target is broken. Someone links to a URL on your site that no longer responds successfully. Your problem, and usually fixable.
• The linking page is gone. The page that hosted the link no longer exists, so the link is gone with it. Not the same event at all, and it belongs in the churn conversation in lost-link reports and index churn rather than here.

Check which one a given view is showing you before you act on it. Vendors label these differently and some views mix them.

The failure modes, in rough order of frequency

Stale check date. The status is from whenever that URL was last requested, which may be weeks ago. A URL you fixed in June can still show as broken. Every row needs its check date read, and the recrawl intervals behind that lag are unpublished.

Soft 404s pass the check. A page that returns 200 with “sorry, this content is unavailable” in the body is recorded as live. So a broken-link report systematically misses the most common way a page dies on a modern CMS, because the check is a status code, not a comprehension test.

Blocked, not broken. A 403, a 429, a bot challenge, or a WAF rule aimed at commercial crawlers all produce a failure code for the vendor and a perfectly good page for users. The crawler’s experience is not the visitor’s. This is the mirror image of the coverage problem in why two tools report different backlink counts — a site can be hostile to one vendor’s agent and not another’s.

Timeouts and transient errors. A single failed request during a deploy or a traffic spike can populate rows. Whether the vendor requires repeated failures before flagging is a policy, and policies differ and change.

Redirect resolution. The link may point at a URL that redirects, and what gets recorded depends on how many hops the crawler follows and which response it stores. A row can be “broken” because the chain ends badly several hops in, which looks nothing like the original URL in the report.

Case and parameter variants. The linked URL may differ from your canonical URL by case, a trailing slash, or a tracking parameter, and whether the vendor treats that as one URL or several is a normalisation decision — one of the six listed in what a link index actually contains.

The verification pass

Before any number from this report enters a report of yours:

1. Read the check date on every row. Discard anything older than your last relevant change.
2. Request each URL yourself, without the vendor’s user agent, and record the status and final URL.
3. Read the body, not just the code. A 200 that says the content is gone is a dead page.
4. Separate target-broken from source-gone into two lists. They have different owners and different next steps.
5. Note the ones that only fail for the crawler. These aren’t broken. They may be worth knowing about for a different reason, but they are not link losses.

A hypothetical outcome from a 40-row report: 12 rows stale and already fixed, 6 blocked-for-crawler-only, 4 source pages gone rather than targets broken, 3 redirect chains resolving to a 404, 15 genuinely dead targets with live links pointing at them. The last group is the report’s actual value, and it’s a bit over a third of the rows. (Illustrative figures, not measurements.)

What the list is genuinely good for

Finding inbound links pointing at nothing. That’s the real job, and it’s a job no other data source does as well. A live editorial link aimed at a dead URL is a specific, correctable loss, and this report is how you find it.

Prioritising by the referring page, not the row count. Sort the surviving rows by something that indicates the linking page matters — its own link position, for instance, per page-level authority metrics. One dead target with a well-cited page pointing at it outranks thirty from abandoned directories.

Noticing patterns. If forty broken rows all point at one legacy URL shape, that’s one event, not forty findings. If they cluster by date, something happened on your side.

What to do about the survivors — redirect, restore, or leave — is a plumbing decision and out of scope for this site. The measurement job ends at a verified list.

Reporting practice

Report the verified count and the raw count, in that order, with the difference explained: “15 confirmed dead targets with live inbound links, from a 40-row vendor report; the remaining 25 were stale, crawler-blocked, or source-page losses.”

Do not put the raw number in a chart or on an alert. A broken-link count is noisy on the crawler’s schedule rather than yours, which makes it exactly the kind of series that generates false alarms — the argument in setting alert thresholds on link metrics.

And never compute a percentage from it without saying what the denominator is. “8% of our backlinks are broken” almost always means “8% of the rows in one view of one index last returned an error to one crawler.”

What nobody outside the vendor knows

The exact request conditions: user agent string, retry policy, timeout thresholds, how many consecutive failures flag a URL, how many redirect hops are followed, and how long a flagged row persists after the URL starts responding again. Vendors document some of this in outline; none of it is verifiable from the outside.

Which is fine, as long as you treat the report as what it is: a cheap, wide net that catches real losses and a lot of debris, and hands you a list to check rather than a number to publish.