Run an automated crawl, cross-check it against your server logs, and triage what you find by business impact, not alphabetical order. That combination catches what a single scan misses: broken links your crawler can see, plus the dead URLs Googlebot is still hitting that no internal link points to anymore.
Do this in the next hour, in this order:
Pro Tip: Fix by traffic and crawl frequency, not by URL order. A single broken link in your main menu does more damage than fifty dead links buried three folders deep in an archive nobody visits.
Fixing broken links well means combining automated discovery with server-log evidence, then remediating by business impact rather than by page count.
| Point | Details |
|---|---|
| Scan plus logs, always | Crawler tools miss orphaned 404s that only show up in server logs or Search Console coverage reports. |
| Triage before you fix | Score broken links by traffic, backlink profile, funnel role, and template location before touching code. |
| Match the fix to the case | Use source updates, topical 301s, or 410s deliberately, never a blanket homepage redirect. |
| Scale needs edge redirects | Pattern-based Regex rules pushed to the CDN edge handle enterprise volume without origin overhead. |
| Automate the monitoring | CI/CD pre-deploy checks and scheduled crawls stop link rot before it reappears. |
| Viaductgen’s role | Viaductgen folds this triage-and-fix workflow into technical SEO engagements, prioritising developer handoff by impact rather than page order. |
A broken link is any hyperlink that fails to load its intended destination, and it shows up in three distinct places: internal links (pointing to another page on your own site), outbound links (pointing to someone else’s site), and inbound backlinks (other sites linking to a page on yours that no longer exists or has moved). Each type causes a different kind of damage, so lumping them together as “broken links” hides the real problem.
The error codes behind them vary more than most site owners realise:
.js, .css, font files, or images that don’t return a 404 in the address bar but quietly wreck how the page renders.Broken links don’t carry a direct Google ranking penalty, but the damage compounds indirectly. Crawlers waste budget hitting dead ends instead of your live pages, internal link equity stops flowing to the pages that need it, and visitors who hit a dead end pogo-stick straight back to the search results, a behavioural signal that search engines do track. Industry guidance suggests sites with more than 2% broken links start seeing measurable performance impact, and once you cross 5%, you’re typically looking at significant crawl waste alongside real user abandonment. Broken asset links are their own quiet menace too: a missing stylesheet or web font can shift layout mid-load, which is exactly the kind of instability that hurts Core Web Vitals scores.
Finding broken links well means matching the tool to the job, because a five-page brochure site and a fifty-thousand-page catalogue need entirely different approaches.
Start with the quickest checks. Dead Link Checker and BrokenLinkCheck both scan a page or full domain and return a list of failures within minutes, no installation required. The W3C Link Checker at Validator does something slightly different: it validates link health at the HTML level, useful for catching malformed markup alongside dead URLs. All three are genuinely free, but they’re surface tools. They won’t render JavaScript reliably, and they won’t tell you what’s happening beneath the page you’re checking.
For full-site coverage, you need a crawler. Screaming Frog SEO Spider remains the standard for desktop crawling, handling JavaScript rendering, exporting response codes in bulk, and mapping exactly where each broken link sits in your site structure. Semrush Site Audit does the same job as a hosted service, adding scheduled recurring crawls and integration with the rest of a Semrush account if you already use one for keyword or backlink tracking.
Neither a checker nor a crawler will show you what’s happening on the server, though. That’s where Google Search Console’s coverage report and your raw server access logs (Apache, Nginx, or CDN logs) come in. Logs reveal something crawlers alone can’t: URLs that Googlebot is still hammering even though no internal link on your site points to them any more. Combining crawler output with log-file analysis is how you catch these orphaned 404s before they quietly burn crawl budget for months. For backlink-side breakage, tools like Ahrefs, Semrush, or Majestic show you which external sites are linking to your dead URLs, which matters more than most site owners assume, because every one of those links represents lost equity you can often reclaim.
Pro Tip: If a URL shows heavy Googlebot activity in your logs but zero internal links pointing to it, that’s an orphaned page. Crawlers won’t flag it on their own, only log analysis will.
The right sequence depends almost entirely on scale. A ten-page site and a ten-thousand-page site are not solving the same problem, even when the symptom looks identical.
On the engineering side, WP-CLI’s search-replace command handles bulk link fixes across a WordPress database far faster than editing pages one by one. Regex-based redirect rules in Nginx or Apache config let one pattern catch an entire retired URL structure, which is exactly how enterprise teams handle mass URL changes without writing thousands of individual rules. At real scale, pushing those redirects to the CDN edge, through Cloudflare Workers, Fastly, or CloudFront functions, keeps the redirect logic off your origin server entirely, which matters when you’re handling volume.
Pro Tip: Never redirect every dead URL to your homepage. It’s the laziest fix and search engines notice: a topical-match redirect to the closest relevant category page preserves far more of the original link’s value.
Not every broken link needs the same remedy, and picking the wrong one wastes the fix.
Soft 404s deserve particular attention because they hide in plain sight: the page returns a 200 OK status while showing an empty result or a disguised “not found” message. Fixing these means auditing your back-end code to return an honest 404 or 410, or rebuilding the content properly when the page’s existing link equity justifies the effort. Whichever remediation you choose, always verify it. Re-crawl the affected URLs, confirm the response codes match what you intended, and watch Search Console for the indexing update to actually land.
Large sites don’t have a broken-link problem, they have a prioritisation problem. Finding four thousand dead URLs is the easy part; deciding which forty to fix this week is where most teams stall.
A weighted formula solves this cleanly. That scoring, used by enterprise SEO teams to prioritise remediation, turns a spreadsheet of thousands of rows into a ranked list your team can actually action.
| Priority band | Typical location | Recommended action |
|---|---|---|
| P0 | Main navigation, homepage, checkout flow | Immediate code fix or deploy, same day |
| P1 | Top-traffic landing pages, high-authority backlinks | Edge redirect promptly |
| P2 | Mid-tier category or blog pages | Standard 301 redirect in next release cycle |
| P3 | Long-tail archive or low-traffic pages | Bulk update in a scheduled maintenance pass |
Server logs earn their place here too. A URL with low direct traffic but high, sustained Googlebot request frequency deserves an escalation even if your traffic-weighted score would otherwise leave it in P2 or P3, because crawl attention itself is a signal worth respecting. And when it comes to backlink reclamation specifically, chasing every dead URL with a single referring domain is low return; focus outreach on URLs with multiple referring domains or demonstrable referral traffic, since that’s where most of the recoverable link equity actually sits.
Fixing today’s broken links matters far less if next month’s content update quietly creates fifty new ones. Monitoring cadence should match how often your site changes: a weekly scan suits a small, static site, daily scans suit an actively updated one, and enterprise sites usually need partitioned daily scans that cover different sections on a rolling basis rather than crawling the entire domain every night.
The strongest setups don’t wait for a scheduled scan to catch a problem, they block it before it ships:
Good broken-link monitoring runs on a schedule with built-in alerting and triage, rather than someone remembering to run a manual check every so often. One caveat worth flagging: not every flagged link is genuinely broken. Auth-required pages and rate-limited third-party services often return error codes to an automated crawler that a real logged-in visitor would never see, so build exclusion rules for those before your alerts fill up with noise.
Pro Tip: Start monitoring with internal links and core templates first, since that’s where the highest-traffic damage lives, then expand coverage to outbound links and backlinks once the foundation is stable.
Picking a tool without matching it to your site’s size and complexity is how teams end up either overpaying for enterprise software they don’t need, or under-tooled for a problem that’s already outgrown a free checker.
A five-page brochure site needs nothing more than a free online checker run every few weeks. A five-thousand-page CMS is Screaming Frog or Semrush Site Audit territory, where scheduled crawls and CSV exports make sense against a realistic budget. A multi-million-URL commerce cluster is a different problem entirely, one that needs log-file ingestion and CI/CD integration baked in, because manual triage simply can’t keep pace with catalogue-scale change. For readers running WordPress specifically, a practical CMS-level guide to checking for broken links covers plugin-based scanning options worth pairing with any of the above.
When Viaductgen runs a technical audit, the sequence follows the same logic laid out above, but with the operational muscle to act on it without waiting on a client’s internal developer queue. Discovery starts with a full crawl paired against server logs to surface orphaned 404s a crawl alone would miss. From there, every broken link gets triaged by business impact before a single fix ships, so engineering time goes to the P0 navigation and homepage issues first, not whatever’s easiest to fix.
Fixes happen at source wherever possible, correcting the actual link rather than layering a redirect on top of a mistake. At scale, that shifts to pattern-based edge redirects, keeping redirect logic off the origin server entirely. Patterns drawn from 50-plus client engagements inform how aggressively to triage, since recurring issues like faceted-navigation 404 bloat or migration-era redirect chains show up again and again across very different sites.
A typical sprint delivers:
There are DIY routes through all of this: a free checker, a Screaming Frog licence, a Saturday spent cross-referencing log files by hand. They work, especially for a smaller site. What they don’t solve is the bottleneck most site owners actually hit, which is developer time. Finding four thousand broken links is one afternoon’s work with the right crawler. Getting a development team to prioritise fixing them, correctly, without redirecting everything to the homepage out of expedience, is where most remediation plans stall for months.
Viaductgen’s technical SEO work folds broken-link remediation into a wider site health engagement, covering site migrations, crawl budget recovery, and the SEO, AEO, and GEO services that keep a site visible as search itself keeps changing. The typical outcome is straightforward: reduced crawl waste, reclaimed backlink equity, better UX signals, and indexation that stops fluctuating month to month. If your site’s broken-link count has crept past the point a weekend fixes, get in touch about a technical audit or a 90-day sprint scoped around exactly this.
Run a crawl or free checker to find them, then fix the source link directly where possible, use a 301 redirect to a topically relevant page when the original is gone, or return a 410 for content that’s permanently removed.
Dead links are commonly called broken links, and the specific error behind them is usually a 404 Not Found, a 410 Gone, or a 5xx server error, depending on the cause.
Checking for malware isn’t the same task as checking for broken links. Broken-link tools like Dead Link Checker or Screaming Frog test whether a URL loads at all, not whether its destination is malicious, so use a dedicated security scanner for virus checks.
Identify the failing link with a crawler or checker, confirm the correct destination URL, then update the source code or CMS content directly rather than relying solely on redirects, which is the most durable fix.
Cadence depends on how often your site changes: weekly for a small, static site, daily for an actively updated one, and partitioned daily scans for enterprise sites with high content volume.