How to Diagnose Broken Internal Links
Diagnose broken internal links by checking the source, response and destination. Separate missing pages, blocked access and wrong replacements before repair.
Broken-link field guide · Step 2 of 5
- Find the Failed Links
- Diagnose the Cause — you are here
- Plan the Repair
- Avoid Repair Mistakes
- Verify the Result
A support editor sees a broken-link warning for a download that opens perfectly on her Mac. She is about to delete the warning. A customer, however, still sees “Access denied.” Both observations can be true: the editor is signed in, and the customer is not.
Diagnosing broken internal links means finding the reason a specific source-to-destination journey fails. Do that before choosing a redirect, replacing the link or deleting it. A response code starts the investigation. It does not know what your reader was promised.
Real Product Evidence: One Repair, Checked Again
The controlled scan confirmed a 404 and exposed both source pages. That evidence separates a missing destination from a timeout or blocked request.
In our controlled LLMIC test on 3 October 2026, one confirmed 404 affected two pages. After manual source edits and a fresh crawl, both counts were zero. See the actual scans, repair and test limits.
Start With the Source, Not a List of Errors
Open the page that contains the link. Record the exact anchor text, the link address and the place it appears: an article, menu, footer or download button. Then follow it in the conditions a normal reader uses. If access depends on a login, record that condition rather than treating your signed-in result as universal.
A destination imported from a spreadsheet is not automatically an internal link. You still need a captured reference from a source page. If no source appears in the current crawl, check coverage before concluding that the URL is orphaned. A skipped folder, failed fetch or JavaScript-only component can explain the missing relationship.
Read the Response as Evidence
A 404 says the requested resource was not found. First compare the recorded address with the intended one. A missing character, a moved upload folder or a retired filename can lead to the same response while requiring different repairs. Look at the publishing history and ask the content owner what should exist.
A 401 or 403 is an access problem under that request’s conditions. A 429 indicates rate limiting. A server error or timeout may be temporary. Keep those findings separate from confirmed missing resources and investigate the actual cause. Retrying aggressively can make a rate limit worse and turn a small diagnostic task into a load problem.
Check Whether the Final Page Keeps the Promise
Sometimes a source points to an old address that redirects successfully. Follow the path to the final destination and inspect its content. If the anchor promises a worksheet, a generic help homepage is not a satisfactory replacement merely because it loads. A technically successful response can still strand the visitor.
Inspect downloads too. The destination might deliver a login page with a PDF-looking filename, an obsolete version, or an empty file. Check the content and the visible promise together. Keep the original link, redirect destination and final response in the handoff so another person can reproduce your conclusion.
Look for One Shared Cause
Imagine that 40 help pages reference one retired installation PDF. The audit has found 40 source relationships, but the root cause may be one shared component or one removed asset. Restoring the correct resource could repair every relationship; changing a footer could alter many pages at once.
Compare a few representative sources before grouping the entire set. The same target can appear in a navigation menu and an old article with a different historical purpose. Preserve each source relationship even when you assign one underlying task. Grouping should reduce repeated work without erasing exceptions.
Compare Source HTML With Rendered Links
A link may appear only after JavaScript runs. Conversely, a script may replace a valid source link with a malformed address. Compare the actual link values in the original and rendered documents when the page depends on client-side behavior. A screenshot alone does not expose the destination stored in the element.
Record which layer produced the finding. If rendering did not finish, label that limitation and repeat an appropriate test. Do not invent a source page or assume a missing capture proves the link never appears. The useful question is what the crawler observed, on which page, under which conditions.
An Illustrative Diagnosis With Three Different Causes
A team reviews 18 flagged destinations after a documentation release. Ten addresses have a misspelled upload directory, four require a customer login, and four external checks timed out. The editor corrects the ten internal link values. The product owner confirms that the four protected resources are intentional and improves the wording to say a login is needed. The external checks remain open.
Those are 18 investigated destinations, not 18 confirmed missing pages. The example shows why the repair decision must follow the evidence. Do not report the four timed-out requests as fixed just because the internal work is complete. Keep a separate status and an owner for the next check.
Choose the Smallest Repair That Solves the Cause
Correct an inaccurate link at its source. Restore a resource when it should still exist. Redirect a moved page to an appropriate replacement when the move is intentional. Rewrite or remove a reference when there is no useful destination. Each choice should preserve the reader’s task rather than simply reduce a warning total.
For third-party destinations, you usually cannot implement the server repair. You can verify the source, find an appropriate alternative, or revise your own claim. Do not replace a research citation with an unrelated source just because its address works. Editorial accuracy is part of the repair.
Hand Over a Diagnosis Someone Can Reproduce
Write the source URL, anchor, target, observed response, date, access conditions and expected result. Add the likely cause as a hypothesis until the owner confirms it. Include the proposed action, responsible person and acceptance check. This helps an editor distinguish a content decision from a server configuration task.
After publication, open the source again and follow the new link. Compare equivalent crawl scopes if you report a change in totals. A disappeared row is meaningful only when you know why it disappeared. Continue to the repair checklist once the cause is established, then use the verification guide to close the task.
| Observation | First Question | Likely Owner |
|---|---|---|
| 404 | Is the address wrong or the resource missing? | Editor or asset owner |
| 401 / 403 | Should the reader have access? | Product or access owner |
| 429 / timeout | Did the request complete under suitable limits? | Technical reviewer |
| 200, wrong content | Does the destination fulfil the anchor promise? | Editor |
Frequently Asked Questions
Why Does a Broken Link Work in My Browser but Fail in an Audit?
Your browser may have a saved login, cookies or cached content, while the audit uses different request conditions. Compare the exact URL and response, then test the public journey. Do not remove the finding until you understand the difference.
How Do I Find the Page That Contains a Broken Internal Link?
Use the recorded source-page relationship and anchor text. If the result came only from an imported URL list, inspect the crawl coverage before assuming there is a captured internal reference. A known destination and a measured link are different evidence.
Does Every 404 Need a Redirect?
No. A typo usually needs a source edit; a mistakenly removed resource may need restoration. Use a redirect when an appropriate replacement serves the original purpose. A genuinely retired resource can remain unavailable while you update links you control.
Can a Link With a 200 Response Still Be Wrong?
Yes. It may open an irrelevant page, a login screen or the wrong download version. Check that the destination fulfils the anchor promise. Response success and content suitability are separate acceptance checks.
Should I Delete External Links That Time Out?
Not automatically. A timeout means the check did not complete under its conditions. Recheck important sources at a suitable rate and verify their relevance before replacing or removing a citation.
Why Are Many Pages Reporting the Same Broken URL?
One target can be referenced by many pages or a shared template. Keep the count of unique destinations separate from source occurrences. Investigate representative sources before deciding whether one component change covers the whole set.
How Do I Prove the Diagnosis Was Correct?
Publish the approved correction, inspect the original source and follow its link again. Retain the expected destination, fresh response and date. Keep failed or unavailable checks open rather than interpreting a smaller crawl as a successful repair.
Sources, Statistics and Measurement Notes
Technical references checked on 1 October 2026: How HTTP Status Codes Affect Google’s Crawlers (Google); Redirects and Google Search (Google); and SEO Link Best Practices (Google). These explain response behavior, redirects and crawlable links; they do not predict traffic uplift. All worksheet counts and scenarios on this page are illustrative, not customer results. Product labels were checked against the LLMIC development source on 1 October 2026. The public installer may differ; check its release notes before buying for a specific control.
Use the Evidence in LLMIC
Ready to apply this to your own crawl? The LLMIC broken-link workflow explains how to inspect a destination and the pages that refer to it. Start with one important URL and keep its source, anchor text and response together. LLMIC helps you investigate and hand over the work; you still review and publish the website change.
The documentation identifies development-build controls separately from the public download. Before subscribing for a particular feature, check the current release and requirements or ask support. Access requires a paid subscription; there is no automatic free trial.
Find the source. Give the repair an owner.
See how LLMIC connects a failed destination to its captured source pages. Review the public release before subscribing for a specific control.