How to Find Broken Links on a Website

Broken links are rarely found all at once. They accumulate — a vendor reorganizes their site, a blog post gets retired, a staging URL slips into production copy — and the longer they sit, the more they erode trust with readers and search engines alike. This guide walks through a practical way to find them, decide which ones actually matter, and fix the right things first.

Start with the pages that matter most

Not every page deserves the same attention. Before you scan anything, make a short list of the pages where a broken link actually costs you something:

Your homepage and primary navigation — broken links here are the most visible and the most damaging to trust.
Your highest-traffic landing pages or blog posts, especially ones that rank well and still bring in organic visitors.
Recently published or recently edited pages, where a typo or a copy-paste error is more likely than on a page that’s been stable for years.
Any page you’ve just migrated, redesigned, or moved to a new domain or URL structure — link rot spikes immediately after a migration.

A quick page-by-page check of this list will usually surface more real problems per minute than a single sweep across an entire site.

Scan the page, not just the sitemap

A sitemap tells you a page exists — it doesn’t tell you whether the links inside that page still work. The fastest way to check a single page is to open it and run an extension-based link checker (Link Alpha, for example) directly in your browser: it reads the links actually rendered in the page’s HTML and checks each destination in place, without you needing to export a URL list anywhere first.

This matters more than it sounds. A sitemap-driven crawler checks whether the page itself loads — not whether the forty links inside that page still point somewhere useful. For catching dead references in body copy, footers, and navigation, checking the rendered page directly is the more direct test.

Don’t treat every failed check as “broken”

This is the step most people skip, and it’s the one that causes the most wasted time. A link check can fail for reasons that have nothing to do with the link actually being broken:

The destination blocks automated requests. Plenty of sites rate-limit or reject requests that don’t look like a normal browser visit — this is a defensive measure on their end, not a sign anything is wrong with the link.
A browser security restriction (CORS) prevents reading the real response. When a checker runs from a web page or extension, cross-origin requests sometimes resolve without revealing their actual status code — the destination might be completely fine; the checker just isn’t allowed to confirm it.
The request timed out once. A slow server isn’t the same as a dead one.
The page requires a login. A broken-looking result behind an auth wall usually just means the checker can’t authenticate, not that the content is gone.

A good link checker separates these “couldn’t confirm” cases from confirmed failures — Link Alpha calls this state Inconclusive, kept visually and semantically distinct from a confirmed Broken result, so you don’t spend time “fixing” a link that was never actually broken.

Prioritize what you fix

Once you have a list of confirmed broken links, triage them roughly like this:

Internal links to pages that no longer exist. These are entirely within your control to fix and usually take two minutes — update the link or restore a redirect.
External links to resources your content depends on (a cited source, a tool, a reference doc). Replace with an archived or updated version if one exists; remove or caveat the reference if not.
External links that are merely decorative or secondary (a footer “learn more” link, an old social share link). Low priority — fix in batches, not urgently.
Inconclusive results. Don’t fix anything based on these alone — open the link manually in a normal tab first to see whether it’s really a problem before you touch anything.

When a single page isn’t enough

If you need to check more than a handful of pages on the same site, a one-page-at-a-time workflow gets tedious fast. That’s the point where a bounded full-site scan — crawling a capped number of same-origin pages in one pass, with the same checking logic applied to each — is worth reaching for instead of manually opening every page. See our guide to full-site scanning for exactly how that works, including its real limits.

A repeatable routine

For most sites, checking once a quarter — or right after any redesign, migration, or large content push — catches the majority of link rot before it becomes visible to visitors. Pair a quick page-level check on your most important pages with an occasional full-site pass, and you’ll rarely be surprised by a broken link a reader finds before you do.