How to find broken links on a website

404 Not Found and 410 Gone: the target does not exist. 410 additionally says the absence is intentional and permanent. Both are genuinely broken and both are yours to fix if the link is on your site.

5xx: the server failed while answering. This is a server problem, not necessarily a link problem, and it is often transient. Re-test before editing anything.

Redirect chains: a link that reaches its destination through several hops still works, but each hop costs a request. A chain that ends in a 404 is broken; one that loops never ends.

Not broken, though often reported: 401 and 403 mean the target exists and requires authorisation or refuses the request. On an external link this usually means the other server blocked an automated client, not that the page is gone.

Also not broken: a link to a page that exists but contains the wrong thing. No status code will tell you that.

For a small site this is entirely feasible, and it is worth doing once to understand what a tool is doing for you.

Collect the URLs. Read the XML sitemap if there is one, and walk the navigation. Anything reachable only from a page you did not open will be missed — which is the limitation a crawler removes.

Test each target's status. `curl -I -L <url>` issues a HEAD request and follows redirects, printing the status of each hop, so a chain is visible rather than collapsed into its final code. Some servers reject HEAD; `curl -sS -o /dev/null -w '%{http_code}' <url>` falls back to a GET.

Check your own server logs for 404s that visitors already hit. That list is evidence of links people actually follow, including ones from other sites you cannot see by crawling your own.

If the site is verified in Google Search Console, its page indexing report lists URLs Google found and could not fetch. That is a second, independent view of the same problem.

Internal link to a page that moved: update the link to the new URL. Redirecting the old URL is also correct and often necessary for external traffic, but it does not excuse leaving your own links pointing at a redirect.

Internal link to a page that is gone for good: remove the link, or point it at the nearest useful page. Serve 410 rather than 404 on the old URL when the removal is deliberate.

External link that is dead: replace it, or remove it. If the content mattered, a link to an archived copy is better than a link to nothing — the Internet Archive's Wayback Machine keeps snapshots of many pages.

Broken image or script: the same problem with a different element. A missing image is a 404 the visitor sees as a gap rather than an error page.

Typos and case: on most servers paths are case-sensitive. `/About` and `/about` are different URLs, and this is a common cause of internal 404s after a migration between systems.

Broken links are not a one-time defect. External targets disappear without telling you, internal URLs change with every restructure, and a bulk edit can break a template's links across every page at once.

The practical answer is to re-check on the events that cause them — a migration, a redesign, a bulk import — and periodically for the external ones, which decay on someone else's schedule.

VeriFixScan crawls the site, records the status of every link target it reaches, and reports the broken ones with the page each was found on — which is the part that makes a finding actionable, since a bare list of dead URLs does not say where to edit.

It also reports redirect chains and the URLs it could not reach, so an empty result can be read as 'nothing broken in what we covered' rather than as an unqualified all-clear.