The problem
Broken links are cheap to create and expensive to leave alone. A page gets renamed, a product goes out of stock, a URL loses a trailing slash in a migration — and every internal link still pointing at the old address now serves a 4xx (client error) to whoever clicks it, human or crawler. A server error (a 5xx) is a different animal — the URL might be fine, but the server failed to answer — and repeated 5xxs slow a crawler down and erode the trust search engines place in the domain. Neither is dramatic on its own. At scale, both waste crawl budget on dead ends, break user journeys mid-click, and leak link equity into pages that no longer exist.
Do it in RacingRoach
Start a crawl against the site and response-code data streams in as each page completes — you don't wait for the crawl to finish to start seeing broken links, because nothing in RacingRoach holds the full result set in memory before it's usable. Once pages are in, filter the results by status-code band (2xx/3xx/4xx/5xx) on the Issues screen to isolate everything that isn't a clean 200.
The part that makes the list actionable rather than just alarming: RacingRoach surfaces every broken link alongside the internal pages that link to it. You're not handed a bare list of dead URLs to go hunting for the source of — each 4xx or 5xx comes with its inlink count and the specific pages doing the linking, so you can jump straight from "this URL is broken" to "this is the template/nav link/blog post that needs editing." That link-source data is what turns a triage exercise into a worklist.
Interpret the results
Not every broken link deserves the same urgency. The short version: a 4xx with internal inlinks is actively breaking something on your own site right now and should be fixed first; a 4xx with only external inlinks is declining incoming link equity, which is worth cleaning up but isn't urgent; and a 4xx with no inlinks at all is usually noise — a stale bookmark or a scraper guessing paths — safe to ignore. For the full triage framework and how to work a list of hundreds of 404s without panicking, see how to read a 404 report without panicking.
Fix it
For internal 4xxs, there are two fixes and they're not interchangeable: if the destination still exists under a different URL, either update the source link to point there directly, or add a 301 from the broken URL to the correct one so anything you missed still resolves. If the destination is genuinely gone, remove the link rather than leaving it dangling. Either way, work internal-linked 4xxs first — they're the ones actively degrading a page your own site is serving right now.
Repeated 5xxs are a different kind of problem. A one-off 500 during a crawl is often just a transient blip, but a pattern of 5xxs on the same URL — or across a whole section of the site — is a server-health signal, not a crawl artifact. That's worth escalating to whoever owns the infrastructure, not just noting in an export: it means real visitors and search engines are hitting the same failures your crawl did.