Broken link audits: how often, and what to fix first

A weekly link crawl catches most broken links before they cost you traffic. When you find them, fix internal links returning a 4xx or 5xx status on your highest-traffic pages first, then broken redirect chains, and treat outbound links to other sites as a lower-priority cleanup pass.

A broken link does not announce itself. Unlike a site going down, nothing pages you when a link starts pointing at a 404. It sits there until a visitor clicks it, a search engine stops crediting the page it was supposed to reach, or someone happens to notice during an unrelated task. By the time it is noticed, it can have been broken for weeks.

How often you actually need to check

Once a week is the practical default for most sites. WebPixie’s own Link Crawler re-scans on roughly that schedule, with a minimum of 24 hours between runs, and that cadence is not arbitrary. Links do not fail the way servers fail. A server can go down between one check and the next and stay down for the whole gap. A link breaks when something changes elsewhere: a page gets renamed without a redirect, a linked external site restructures its URLs, someone deletes a page a dozen other pages still point to. Those changes accumulate gradually, so checking daily rarely finds something a weekly check would have missed a day later.

The exception is right after you change something big. A CMS migration, a bulk URL restructuring, or a large content prune is exactly when internal links break in batches, so a check right after one of those events catches a cluster of breakage that a routine weekly pass might not flag as unusual for days.

What actually breaks, and why it stays hidden

Broken links come from a small number of repeat causes:

Internal moves without a redirect: a page gets renamed or merged, and every internal link still pointing at the old path now 404s.
External link rot: a site you linked to reorganizes, shuts down, or paywalls the page you referenced.
Typos at creation time: a link was wrong from the day it was published, and nobody clicked it until now.
Dying redirect chains: a redirect that pointed at another redirect, and one link in that chain eventually breaks.

None of these show up in normal browsing. A visitor who never clicks that one link, a page that ranks fine without anyone following its outbound reference, an internal link buried three levels deep, all of these can carry a broken destination indefinitely without a single alert firing on their own.

What to fix first

When a crawl turns up a list of broken links, they are not equally urgent. A rough order that holds up in practice:

Internal 404s and 5xx errors on high-traffic or conversion pages: these are self-inflicted and usually a one-line fix, correct the href or restore the redirect, and they directly cost visits or sales while broken.
Redirect chains and loops: each extra hop adds latency and can waste the crawl budget search engines allocate to your site, so collapsing a chain to a single redirect is worth doing even when nothing is technically broken yet.
Outbound links to other sites: these hurt credibility and user experience more than function, and they are lower priority precisely because the failure is on someone else’s site, not yours.

One caveat worth being honest about: a link crawler that discovers pages by following links from your homepage will not find an orphaned page that nothing on your site links to anymore. That page can carry its own broken outbound links and never surface in a homepage-based crawl at all. Homepage-based discovery is a real limitation, not just a technical footnote, if part of your audit goal is finding content nobody can navigate to in the first place.

What a crawler catches that a manual check will not

Clicking around a site by hand finds the links you happen to click, which is a small, biased sample of the total. A crawler following every discovered internal link finds all of them, including the ones three clicks deep that nobody manually checks twice a year. It also records detail a human scan skips: response time, redirect status, and content size alongside the plain status code, so a link that "works" but returns a slow, oversized response shows up as a different kind of problem than a clean 404.

It has real edges, too. A crawler that only follows publicly reachable pages will not check anything behind a login, and one that has to fetch a page to confirm the link works cannot fully honor robots.txt mid-crawl without leaving gaps in the report. Outbound links usually get listed rather than health-checked, since verifying every external destination on every crawl is a different, heavier job than checking your own pages. None of that makes crawling pointless, it just means the fix-first order above should stay anchored to what the crawl actually covers, not to an assumption that everything got checked.