Broken Link Repair Checklist
Use a broken link repair checklist to choose the right fix, assign an owner and verify the published source and destination without losing useful context.
Broken-link field guide · Step 3 of 5
- Find the Failed Links
- Diagnose the Cause
- Plan the Repair — you are here
- Avoid Repair Mistakes
- Verify the Result
The editor receives a spreadsheet of red rows and a request to fix them today. Some are typos, one is an important missing download, and several external sites refused the crawler. Treating every row the same would be quick and wrong.
This broken link repair checklist turns a detected failure into a reviewed action. It starts with the reader’s expectation, then chooses the smallest change that restores a useful path. Use it for execution after the initial audit has collected source evidence.
Real Product Evidence: One Repair, Checked Again
The test followed this sequence: save both sources, replace both links, then crawl the same two URLs again.
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
- Confirm failure and current source
- Read the anchor promise
- Choose and assign the repair
- Verify the public journey and record why
| Decision | Use It When | Verify |
|---|---|---|
| Restore | Owned resource should still exist | Original URL serves the right content |
| Correct | Address contains an identifiable typo | Published link uses intended address |
| Replace | A relevant successor is confirmed | Anchor promise matches replacement |
| Rewrite or remove | Reference is obsolete or unsupported | Surrounding passage remains accurate |
Confirm the Failure Is Real
Read the response and test date before editing. A missing-resource response, server error, blocked request and timeout belong in different categories. Recheck uncertain cases with suitable request limits. Do not erase an important reference to make an audit report look cleaner.
Open the source record and verify the link still exists in the published page. Content may have changed since the crawl. If the source relationship is already gone, record that fresh observation rather than performing a redundant edit based on an old export.
Understand the Anchor’s Promise
Read the sentence around the link. Is the reader expecting a download, a detailed explanation, a purchase page or an official source? Write that expected outcome beside the task. It is the criterion for choosing a replacement.
If the original material is no longer available, decide whether the surrounding claim still stands. Replacing a citation with a vaguely related homepage can leave the article unsupported. Sometimes the correct repair is rewriting the passage or removing an obsolete claim, not swapping an address.
Choose One Repair Type
Restore the original resource when it should still exist and you control it. Correct a typographical error when the intended destination is clear. Update to a relevant moved resource when its identity is verified. Remove or rewrite an obsolete reference when no useful replacement exists.
Use a redirect only when it is the appropriate publishing decision, not as a universal link-repair shortcut. If you control the source, a direct link edit may be cleaner. Historical external visitors may still need a separate legacy route, so keep those responsibilities distinct.
Assign the Right Owner
A missing file may belong to the publishing team. A footer URL may belong to the theme owner. A failed external citation needs editorial judgment. Name the responsible person or role rather than sending every row to a developer.
Group repeated instances from the same component, but attach the affected source list. If a shared block appears in several languages or templates, include representative exceptions. The fix should not silently replace localized destinations with one generic language version.
Protect Meaningful Context
Update the anchor and nearby sentence if the replacement changes what the reader will receive. Preserve useful accessibility and descriptive wording. “Click here” hides the destination’s purpose and makes a future audit harder to interpret.
Check whether the link opens a file or another page. A replacement PDF, article and interactive tool may cover similar information but offer different experiences. Tell readers what they are opening instead of making them discover the change after the click.
An Illustrative Repair Board
A team starts with 60 flagged occurrences. Twenty-four share a missing guide file, 18 contain a typo repeated in a reusable block, ten need individual citation review and eight are blocked external checks. The board should show four work groups, not 60 identical delete-link tasks.
The first two groups may be resolved through two owned changes, while the citation review requires ten decisions. The eight blocked checks remain unverified. These teaching numbers explain effort and uncertainty; they do not claim a typical distribution for websites.
Verify the Published Result
After saving, inspect the public source page. Confirm the intended address is present and follow it to the final resource. Check the anchor wording at the same time. A CMS save confirmation proves the edit was accepted, not that the live journey is correct.
If a template changed, recheck the affected source set or clearly state the sampled coverage. Separate verified occurrences from those not yet revisited. A repaired destination can restore many links, but you still need evidence that their paths reach the intended resource.
Close With a Small Audit Trail
Retain the old value, new value, reason, owner and verification date. This is especially useful when a future editor asks why an old reference was removed. A brief explanation prevents the same broken link from being restored during a content refresh.
Keep unresolved items visible with a next step. For a blocked external source, that might be a manual review or a later controlled retry. A checklist is complete when each row has a defensible outcome, not when all red labels have been hidden.
Create a Ticket Your Editor Can Finish
Choose one row and hand it to a teammate who did not run the audit. Can they find the sentence, understand the promised destination and explain the proposed change? If they need to ask which page contains the link, the ticket is missing its source. If they need to guess which replacement is correct, it is missing an editorial decision.
| Ticket Field | Illustrative Entry |
|---|---|
| Source and anchor | /help/start/ — Download the worksheet |
| Failed target | /files/setup-v1.pdf — 404 observed today |
| Approved action | Replace with the reviewed current worksheet |
| Owner | Documentation editor; developer reviews any redirect |
| Acceptance | Open the published source, follow its link and inspect the file |
| Outcome | Pending until the fresh check succeeds |
Your Repair Readiness Check
- The exact source and anchor are recorded.
- The failed response has been checked recently.
- The replacement serves the same reader need.
- An owner has approved the change.
- Repeated source pages are included.
- A fresh source-to-destination check is planned.
Use the button below to download a blank CSV handoff template. The checklist is a preparation aid; checking every box does not verify a website change.
For a shared navigation link, the owner may need to change one component and verify several page templates. For a citation in an article, an editor must also read the replacement source. Keep these jobs separate even when the original destinations return the same error. The right repair depends on what the link promised, not only on which status code appeared.
Frequently Asked Questions
What should a broken link repair checklist include?
Record the source, anchor, failed target, response, chosen action, owner and verification date. Include a reason for replacements or removals so later editors understand the decision rather than restoring the old link.
Should I delete every broken link?
No. Restoring a file or correcting an address may preserve useful information. Review the original promise and the surrounding claim. Delete or rewrite only when that is the appropriate editorial outcome, not simply to reduce warnings.
When should I redirect a missing page?
When a suitable replacement and publishing decision justify it. A redirect is not mandatory for every missing resource. If no relevant successor exists, an honest removal response can be better than sending readers to unrelated content.
Who should approve a replacement citation?
Someone able to assess whether the new source supports the actual claim. A developer can implement the address change, but a response code or similar page title cannot establish that the evidence is equivalent.
How do I repair a link repeated across many pages?
Identify the shared component and test the change there, then verify affected sources. Keep the occurrence list and exceptions. One template edit can reduce work, but should not erase language-specific or context-specific destinations.
Does saving the editor prove the link is fixed?
No. Inspect the published page and follow the link after saving. Caches, templates or incorrect values can leave the public experience unchanged. Record the actual destination and content observed during verification.
Will completing the checklist guarantee rankings?
No. It provides a controlled repair process for broken journeys. Search performance depends on other factors too. Report the verified link changes and their scope without promising a particular traffic result.
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.