Three of 790 internal links did not resolve, and all three failed differently

787 of 790 distinct internal links on this site resolve to a real page. That number is almost worthless on its own. The useful part is that the three that did not resolve failed for three unrelated reasons and required three different responses: one was an image source inside a code example and is correct exactly as written, one pointed at the wrong path prefix of a page that does exist and has been repointed, and one pointed at a page that exists under no path at all and has been unwrapped with every word of its sentence kept. A count tells you how many rows to look at. It does not tell you what any of them mean.

That is the argument for running this check with your own eyes on the output rather than accepting a dashboard figure. A 99 point something pass rate reads like a clean bill of health, and the entire information content of the exercise was sitting in the three rows underneath it.

The three failures, and what each one actually needed

What the checker saw	What it was	What we did
An image source that does not resolve	A sample path inside a code example, written for a reader to copy	Nothing. It is correct as it stands
A link to a page that returns not found	The right page under the wrong path prefix	Repointed at the url the sitemap publishes
A link to a page that returns not found	A destination that exists under no path on the site	Unwrapped the anchor and kept the sentence intact

Three rows, three verbs: ignore, repoint, unwrap. A tool that reported them as one category called broken links would have sent somebody to delete a correct code sample and to remove a sentence that a reader needed.

The false positive is the most expensive row

The first row deserves its own paragraph because it is the one that burns time repeatedly. A code example is documentation. The paths inside it are illustrations of a shape, not navigation, and they are supposed to point at a domain the reader will substitute for their own. A link checker reads markup and cannot tell the difference, so it reports a sample as a defect, somebody investigates it, and the conclusion is that nothing was wrong.

Do that three times and people stop reading the report, which is the real damage. A checker that generates work rather than finding it trains its audience to ignore it. The fix is to exclude anything inside a preformatted or code region before you classify, and to say in the report that you excluded it and how many you excluded, so nobody wonders later whether the sample was missed or skipped.

This is the same discipline any tool that produces a list of suspects needs, and the question of which job you are asking a checker to do, and what to do with what it hands back, is worked through in our page on the two jobs a duplication checker does and what to do with its output.

The wrong prefix row, which is a url problem wearing a link problem's clothes

The second failure was a link to a page that is live, written in the form the rest of the site uses, aimed at a page that does not use that form. This site serves content under two path prefixes, and a link assembled from a slug rather than copied from the sitemap lands on the wrong one about as often as you would expect.

The repair is to take the url from the sitemap and repoint. The prevention is to never write a link by assembling a path, and to resolve every candidate against the sitemap before it goes into a body. That one habit removes this entire class of failure, and it costs one lookup.

The dead destination row, and the decision that goes with it

The third had no destination anywhere. The temptation is to delete the sentence, because the sentence was obviously written around the link. Resist it. The sentence was written for a reader, and the anchor was one word choice inside it. Unwrapping the anchor and keeping the prose leaves the reader with the information and removes only the promise the site could not keep.

Deleting prose to fix a link is a trade in the wrong direction, and it is worth writing the preference down somewhere a future editor will find it, because the quick fix looks tidier in a diff.

How to run this on your own site

• Work from distinct targets, not from occurrences. One dead destination linked from forty pages is one problem and forty rows, and the dedupe is what makes the output readable.
• Exclude code and preformatted regions before classifying, and report how many you excluded.
• Resolve against the sitemap rather than only by fetching. A fetch tells you what happened to that request; the sitemap tells you what the site claims to publish, and the disagreement between them is where the prefix errors live.
• Count every check and compare the count to what you expected. A scan that quietly swallows failures reports a clean site having read almost nothing, and good news from an empty input is the hardest bug in this work to notice.
• Classify before you act, every time. Ignore, repoint or unwrap. If a row does not fit one of those three, you have not understood it yet.

Anchor text is the other half of this audit, because a link that resolves can still say the wrong thing about where it goes, and the seven types and the internal rules are set out in our page on auditing the anchor text profile you already have.

Questions about auditing the internal links you have already published

Is a 99 percent pass rate good?

It is not a grade, it is a filter. The number tells you how much reading is left and nothing about severity. One dead link on your pricing page matters more than fifty on archive posts, and no pass rate distinguishes those.

How often should this run?

After every batch of publishing, because new pages are where new links come from, and after any change to your url structure, because that is what turns a working link into a broken one without anybody editing a page.

Does a broken internal link hurt how an assistant reads my site?

The direct cost is to the reader who clicks it. The indirect cost is that your structure stops describing itself accurately, and the pages you were pointing at lose the only durable signal you control. Fix them because the reader deserves it and the structure follows.

Should I use a crawler or my own stored bodies?

Both answer different questions. Your stored bodies tell you what you published, which is what you can edit. A crawler tells you what is live, which may differ if anything republishes pages behind you. Start with what you published.

What about links out to other sites?

Same classification, different tolerance. An external destination can disappear without anybody doing anything wrong, so the sensible policy is to recheck periodically and to unwrap rather than delete when a source you cited is gone.

The three rows are the report

If we had published only the pass rate, this page would say nothing a reader could use. Publishing the three failures with their causes is what makes the exercise repeatable on somebody else's site, and it is the same reason we publish the numbers that do not flatter us: the windows, the export dates and the denominators behind every claim we make, including two Google Search Console exports and a dated blind scan, are set out on our proof page. Running audits like this on client domains and repairing what they turn up is the work we sell, so the method and the awkward rows are both printed here.