Broken link checker, the three different jobs hiding behind one phrase and the only one that recovers something you already paid for

A broken link checker crawls a set of links, requests each destination, and reports the ones that do not return a working page. That single sentence describes three audits that have almost nothing in common. Outbound checks the links you wrote to other people's pages. Inbound checks the links other people wrote to pages of yours that no longer exist. Internal checks your own navigation and in body links to your own pages. Different tool, different output, different fix, and very different value. The inbound audit is the one that recovers something, and it is the one almost nobody runs.

Verified against Google's India geo target alone on 22 October 2026, broken link checker tool draws 170 searches a month in India, with a further 140 a month in India on the same reading for broken link finder. People arrive wanting a tool. The more useful thing to arrive with is the right one of the three questions.

The three audits, and what each one is worth

Read the third column twice. An outbound dead link is an editorial embarrassment. An internal one is a navigation defect. An inbound one is money on the floor, because somebody chose to link to you, that link still exists, and it now points at an error page. Fixing it costs one redirect line and recovers the whole value of the link.

The inbound audit, which is the one to run first

You cannot find these with a crawler that starts at your home page, because the broken URLs are not on your site any more. They have to come from a source that knows about links pointing at you.

• Start inside Search Console. The pages report lists URLs Google tried and found missing, and the top linking pages data tells you where links to your site come from. This is free, it is first party, and it is the only source in the stack that is reporting Google's own experience of your site rather than modelling it.
• Add a backlink tool for the external half. Any backlink index can list referring pages whose target on your domain now returns not found. Each vendor sees a different slice of the web, which is why the counts never match between tools. Pick one and work its list.
• Sort by referring domains, not by link count. One dead URL with links from fourteen separate domains is worth more attention than forty dead URLs with one link each.
• Redirect each one to the closest genuinely relevant page. Not the home page. A redirect to a page that does not answer what the original did is a slightly politer dead end, and it helps nobody.
• Check for the pattern. If twenty dead URLs share a path prefix, you did not lose twenty pages, you changed one URL structure and forgot a rule. One redirect rule fixes the set.

This audit is worth running once a quarter and after every site migration, platform change or URL restructure, which are the three events that create almost all of these.

The internal audit, and the trap in the output

An internal link audit is easy to run and easy to misread, because the report hands you a list of suspects rather than a list of defects. We ran this on our own site and published the result, and the finding was not the pass rate. 787 of 790 distinct internal links resolved to a real page, and the three that did not had three unrelated causes needing three different responses, read off the live page on 22 October 2026: one was an image path inside a code example and was correct exactly as written, one pointed at the wrong path prefix of a page that does exist, and one pointed at a destination that exists under no path at all. The full account is on three of 790 internal links did not resolve and all three failed differently, including why the false positive is the most expensive row in the report.

The practical lesson for anybody running the same audit is short. Exclude code and preformatted regions before you classify anything, because a sample path inside documentation is an illustration and not navigation. Then read every row yourself and assign it one of three verbs: ignore, repoint, or unwrap. A tool that lumps all three into a category called broken links will send somebody to delete a correct code sample.

Where a link resolves but the destination still fails to appear in search, the cause is usually a response header rather than the link, and the four checks for that are set out in noindex, canonical, server header and cache checks. Internal links are also the half of this question with the most upside beyond repair work, because the same crawl tells you which of your pages nothing points at. Our page on internal linking, the structure that decides what ranks and the audit that finds the gaps covers that side of it.

The outbound audit, done without generating busywork

Outbound checking is where most free tools point, and it produces the longest list and the least value per row. Four rules keep it proportionate.

• Treat a 403 or a 429 as unverified, not as broken. Plenty of sites refuse an automated request from an unfamiliar client and serve the same page perfectly to a browser. A rate limit response anywhere in a run puts the whole run in doubt, because the host is telling you it throttled you rather than that the page is gone.
• Re-check a failure once, later, from a different session before you edit a page on the strength of it. A single reading of somebody else's server is a lead rather than a finding.
• Fix by intent, not by status. If the page you linked has moved, repoint. If the resource is genuinely gone, either find an equivalent or unwrap the anchor and keep the sentence, because the sentence was doing a job.
• Ignore links inside quoted examples. Same rule as the internal audit, and the same reason.

Choosing a tool, by what you are crawling

• A desktop crawler for internal and outbound work on a site up to a few tens of thousands of URLs. It reads the whole site, follows every link, and gives you a status code per destination with the pages it was found on, which is the column that makes a fix possible.
• A browser extension for checking one page before you publish it. Fast, free, and the right scale for an editorial check.
• Search Console plus a backlink index for the inbound audit, which no crawler can do.
• A hosted monitor if the site is large enough that somebody needs to be told about a new failure rather than finding it at the next audit.

Free tools cap the crawl, usually at a few hundred URLs, and that cap is the thing to read before you start rather than after. If your list is in the thousands rather than the hundreds, the constraint stops being the checker and becomes the throughput, which we cover in bulk SEO tools for checking thousands of URLs at once.

What to do with the finished list

• Record the date of the crawl on the sheet. A link report is a reading taken at a moment, and the web moved while you were reading it.
• Group by cause before you group by page. One changed URL structure, one retired supplier site, one typo in a template. Three causes usually explain most of a long list, and each has one fix rather than many.
• Keep the redirects you create. A redirect is a permanent part of the site now. Document why it exists, because the next person to tidy the configuration will otherwise remove it and break the link a second time.
• Re-run the inbound audit after the redirects are live and confirm each one lands on the page you intended with a working response, rather than assuming the rule did what you meant.

Questions about checking for broken links

Do broken links hurt my search rankings

A handful of dead outbound links is a quality signal rather than a penalty, and the clearer cost is to the reader. The case with a real and measurable cost is inbound: a link somebody gave you that now points at a missing page passes nothing, and a redirect recovers it.

How do I find links to pages I deleted

Combine Search Console, which reports the URLs Google tried and could not find, with any backlink index, which can list referring pages pointing at those URLs. A site crawler will never find them, because the pages are no longer there to be crawled.

Should I redirect every missing page to the home page

No. Redirect to the closest page that genuinely answers what the original did. A blanket redirect to the home page delivers a visitor who wanted something specific to a page that does not mention it, and the link stops doing the work it was given.

Why does the checker report a page that works in my browser

Because the destination treated an automated request differently from a browser, which is common and legitimate. Re-check it later from a separate session before changing anything, and treat a rate limit response as a reason to doubt the whole run.

How often should the audit run

Internal and outbound once a quarter for most sites, and immediately after any migration or URL change. The inbound audit after every structural change without exception, because that is when earned links get orphaned in bulk.

Does a link in a code example need fixing

No. A path inside documentation is an illustration for a reader to substitute, and a checker reading markup cannot tell it apart from navigation. Exclude those regions before classifying, and say in the report how many you excluded so nobody wonders later whether they were missed.

The link that is not a link

Every audit on this page assumes the thing worth finding is a hyperlink, with a source page and a destination URL. There is now a route to a buyer that leaves no link at all. An assistant asked which company to use in a category reads a handful of sources, names two or three businesses, and the person acts on that without ever clicking through, so your site can be the source behind an answer and show nothing in any report you own. A crawler cannot find that reference, because there is no anchor tag anywhere to find. What can be done is to ask the question the way a buyer would, record which sources the answer leaned on and which companies it named, and repeat it on a schedule so the result is a series rather than an anecdote. AI Knows Us runs that reading across ChatGPT, Gemini, Perplexity, Claude and Google AI Overviews, which is the one part of your link graph no checker can crawl.