Broken Links vs. Redirects: What's the Difference, and What to Do About Each
It’s tempting to treat any link that doesn’t land you on the exact page you expected as “broken.” That’s a mistake. A redirect and a broken link are fundamentally different outcomes, and treating them the same way leads to wasted effort — either chasing redirects that are working exactly as intended, or missing genuine errors buried in a results list that doesn’t distinguish them.
What a broken link actually is
A link is confirmed broken when the request to its destination returns a real error — most commonly an HTTP 4xx (like 404 Not Found) or 5xx (server error), or the connection fails outright because the domain no longer resolves or the server refuses the connection. This is a confirmed outcome: something at the other end responded with an error, or nothing responded at all.
What a redirect actually is
A redirect (HTTP 3xx — 301, 302, 307, and so on) means the server explicitly told the requester “this content now lives somewhere else,” and the browser followed that instruction to a new destination. If that final destination then responds successfully, the overall link still works — it just took one extra hop to get there.
Redirects are a completely normal, intentional part of how the web works: a site reorganizes its URL structure, moves to HTTPS, merges two pages into one, or renames a category, and puts redirects in place specifically so old links keep working. A redirect is evidence the site owner handled a change correctly, not evidence something is broken.
Why they get confused
Older or simpler link checkers sometimes report anything other than a clean 200 OK as a single “not working” bucket, which lumps genuine 404s in with perfectly healthy redirects. If you’re relying on a tool like that, you’ll end up “fixing” links that were never actually a problem, while real issues are harder to distinguish in the noise.
A link checker that’s useful for real auditing work reports these as separate categories. Link Alpha, for example, classifies a successfully resolved redirect as Redirect — distinct from Broken, which is reserved for a confirmed error or an unreachable host.
When a redirect is worth fixing
Redirects aren’t inherently a problem, but they’re not always free either. A few cases worth cleaning up:
- Long redirect chains (a link that redirects to another redirect, multiple times before landing on the final page) add latency and are worth pointing directly at the final destination instead.
- A redirect to a page that no longer matches the original link’s context — for example, an old product page that now redirects to your generic homepage instead of a relevant replacement. The link “works,” but it no longer serves the reader well.
- Internal links you control that still point at the pre-redirect URL. Even though the redirect handles it, updating your own links to point directly at the current URL is cleaner and slightly faster for readers.
When to leave a redirect alone
If an external link you don’t control redirects to a working, relevant page, there’s usually nothing to do. You can’t “fix” someone else’s redirect, and a single extra hop to a page that still answers the reader’s question isn’t worth chasing.
The practical takeaway
When you’re reviewing link-check results, read the status, not just whether the link “worked” on the first try:
| Status | What happened | Typical action |
|---|---|---|
| Working | Responded successfully, no redirect | Nothing |
| Redirect | Forwarded to a page that responded successfully | Usually nothing; update internal links to the final URL if convenient |
| Broken | Confirmed error, or host unreachable | Fix or remove the link |
| Inconclusive | Couldn’t be reliably confirmed (CORS, timeout, rate-limit, login wall) | Check manually before assuming anything is wrong |
Separating these four outcomes — rather than collapsing them into “worked” or “didn’t work” — is what turns a link check from a blunt pass/fail test into something you can actually act on with confidence.