How to Find Broken Links Across Your Website
Find broken links with the source page, anchor text and failed destination together. Separate real failures from blocked checks and prioritize useful repairs.
Broken-link field guide · Step 1 of 5
- Find the Failed Links — you are here
- Diagnose the Cause
- Plan the Repair
- Avoid Repair Mistakes
- Verify the Result
A visitor reaches the final paragraph of your setup guide and clicks “Download the template.” The destination returns an error. Your audit may list the missing file, but the editor needs another fact: which sentence promised that download?
Finding broken links means preserving the relationship between a source page and a destination. A list of failed URLs is only half the job. Keep the anchor text, location and response evidence so the execution team can repair the actual journey.
Real Product Evidence: One Repair, Checked Again
See how a missing destination becomes an actionable repair: the real scan records both source pages and their anchor text.
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.
The Workflow at a Glance
- Collect source-to-target links
- Check responses and uncertain failures
- Group destinations and occurrences separately
- Assign the smallest useful repair
| Field | Example | Why the Editor Needs It |
|---|---|---|
| Source | Setup guide | Shows where the promise appears |
| Anchor | Download the template | Explains the expected outcome |
| Destination | Removed worksheet file | Identifies the failed resource |
| Observation | Confirmed missing response | Separates failure from uncertainty |
Broken Website Links vs Broken Backlinks
A broken link on your website points from a page you inspect to a failed destination. A broken backlink points from another website to a missing page or file on yours. One failed destination can affect both journeys, but you need a different source list and owner for each.
To find broken backlinks, start with known referring URLs, such as the external links in Search Console’s Links report. Google’s report is a historical sample, not a complete or current failure list. Recheck the destination response and the referring page before assigning a repair. Crawling your own site does not discover every page on the web that links to it.
If you control the failed destination, review whether the original resource should be restored or whether it moved to a truly equivalent replacement. If the incorrect source belongs to another site, that site’s owner controls its link. Keep the source, destination and proposed action together; a successful response alone does not verify a useful journey or recovered rankings.
Decide What You Are Checking
Start with public pages in an agreed scope. Identify the hosts, sections and exclusions before crawling. Account areas, destructive actions and private systems should not be followed casually. Record whether external destinations will be checked and how conservatively those requests will run.
Separate navigational links from images, scripts and other resources. All can fail, but they require different owners and acceptance checks. A missing stylesheet is not the same task as a broken link to a downloadable worksheet, even if both return the same status.
Keep the Source With the Target
For every link, retain the source URL, visible anchor, destination and document layer. If a link appears only after rendering, say so. A page imported from a sitemap proves that you know its address; it does not prove another page links to it.
Record the component or surrounding text when practical. “Footer support link” is more useful than an isolated target shared by 500 pages. The source context reveals whether one template edit can repair many occurrences or whether individual articles need editorial review.
Interpret Responses Before Labelling Failures
A confirmed missing-resource response differs from an access block, rate limit, server failure or timeout. Preserve the actual observation. Recheck uncertain failures under an appropriate request rate before declaring the destination permanently broken.
An external website may reject automated requests while serving normal visitors. That needs investigation, not an immediate link deletion. Conversely, a successful response may display an error message or irrelevant page. Inspect important destinations for meaning as well as status.
Trace Redirected Destinations
A link can pass through a redirect and then fail. Keep the entire path so the owner can tell whether the source is outdated or the final destination is unavailable. If the intended replacement exists, update the owned source directly when appropriate.
Do not assume the final address is automatically a suitable replacement for the anchor promise. A link labelled “download the spreadsheet” should not quietly become a link to a general resources homepage. The wording and destination need to agree.
Group Work Without Losing Occurrences
Report unique failed destinations and affected link occurrences separately. One missing PDF linked from 80 articles is one destination with 80 source relationships. Restoring the correct file may repair all journeys, while replacing each link requires a different workload estimate.
Group by a shared cause only after checking examples. Similar filenames do not prove the same publishing error. Preserve the complete source list even when the summary names one template, so verification can confirm the repair reached its intended scope.
An Illustrative Template Audit
A documentation site contains 1,000 observed link occurrences. Eighty point to one removed PDF, 12 point to six mistyped internal addresses, and eight external checks are blocked. The remaining 900 respond as expected under the test.
The team has 92 confirmed failed occurrences across seven destinations, plus eight unresolved external checks. It does not have 100 confirmed broken destinations. These illustrative numbers show why denominators and source relationships matter when assigning work or reporting progress.
Prioritize the Promise Being Broken
Repair failures in installation instructions, pricing journeys and primary navigation before low-value historical references. Use actual page purpose and available usage evidence, not a made-up severity score. A link on one important setup page can matter more than dozens of repeated footer occurrences.
For each task, state whether the best action is restoring the original resource, correcting a typo, replacing the destination, updating the wording or removing an obsolete reference. A developer cannot choose the right editorial replacement merely from a status code.
Hand Over a Repairable Record
Include the source page, anchor, failed address, observed response, intended action and owner. Attach a screenshot when placement is hard to identify, but retain the actual link value too. This lets a content editor act without rerunning the entire audit.
After the edit, revisit the source and follow the published link. If the target was restored, recheck the original destination and representative sources. Save unresolved blocked checks separately. A lower warning count can reflect a smaller crawl, so compare the same scope when judging progress.
Follow One Broken Download From Report to Repair
Illustrative walkthrough — not an app screenshot or a customer result. Open each step to see how a raw warning becomes an instruction someone can finish.
1 · See What the Reader Was Promised
The setup guide at /help/getting-started/ says “Download the setup worksheet.” Its link points to /files/setup-v1.pdf. Save those three pieces together: the source page, the anchor text and the destination. The source page itself can return 200 while its download is missing.
2 · Check the Actual Failure
A fresh request to the PDF returns 404. The same address appears on 12 observed source pages. That is one failed destination and 12 affected source pages, not 12 different missing files. If the scan covered only those pages, do not describe the number as a site-wide total.
3 · Choose and Verify the Repair
The owner confirms that /files/setup-v2.pdf is the current, equivalent worksheet. Update the source links and their wording where needed. Consider a permanent redirect for old external bookmarks only if the replacement really serves the same purpose. Open the new PDF, follow the link from the published source, and recheck the 12 affected pages.
| Evidence | Before | Acceptance Check |
|---|---|---|
| Source link | Points to setup-v1.pdf | Published link uses approved destination |
| Destination | 404 response | Correct worksheet opens successfully |
| Affected pages | 12 observed sources | All 12 checked; failures remain open |
Separate a Finding From a Repair Ticket
The audit tells you what happened under its test conditions. A repair ticket must also say what should happen instead. For the worksheet example, “fix the PDF” is too vague: the developer could restore an outdated file and technically remove the error. “Make the current setup worksheet available from the 12 listed source pages” expresses the reader’s need and gives the reviewer a useful acceptance test.
Keep an observation date beside the status. A file that failed yesterday may have returned today; a browser that succeeds for you may be using a saved login. Test the public journey in a suitable logged-out session, then mark the outcome as confirmed, unresolved or intentionally removed. Do not silently remove uncertain rows from the denominator.
Frequently Asked Questions
What is a broken internal link?
It is an internal navigation relationship whose destination fails to provide the intended resource. A missing response is one clear example. Keep the source page and anchor text so the repair can address the actual user journey.
Can Google Search Console find every broken link?
No. Its reports provide useful search-related observations, not a complete inventory of every current source-to-target relationship. Use them alongside a scoped link audit and preserve where each candidate URL came from.
Does a timeout mean a link is permanently broken?
No. It means the request did not complete under those conditions. Recheck with appropriate limits and inspect important cases. Keep timeouts separate from confirmed missing resources rather than converting unavailable evidence into certainty.
Should I check external links too?
Yes when the scope and request limits allow it. External failures may be temporary or caused by bot restrictions. Verify important cases and choose replacements editorially; do not remove citations merely because one automated request was blocked.
Why should I save anchor text?
It records what the link promised the reader. A technically reachable replacement can still be wrong for that promise. Anchor text and nearby context help editors choose the destination and update wording together.
How should repeated broken links be counted?
Count unique destinations and source occurrences separately. One failed file can affect many pages. Both numbers are useful, but they answer different questions about root causes, user exposure and the effort required to repair them.
Will removing broken links guarantee more traffic?
No. Repairing them improves specific journeys and can remove discovery barriers, but traffic depends on many factors. Verify the link behavior first and discuss search performance separately without a guaranteed ranking claim.
Sources, Statistics and Measurement Notes
- SEO Link Best Practices — Google Search Central. Crawlable destinations and descriptive link context. Accessed 30 September 2026.
- How HTTP Status Codes Affect Google Crawlers — Google Crawling Infrastructure. Distinguishes response classes and their interpretation. Accessed 30 September 2026.
- Redirects and Google Search — Google Search Central. Relevant when a broken journey involves moved content. Accessed 30 September 2026.
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.