What is a broken backlink?
A backlink is an incoming reference from another website. A broken backlink usually means that following that reference no longer reaches the intended resource. The failure can be at the destination, inside a redirect chain or on the source page itself. These are different repair jobs. An internal link between your own pages is a separate case, even if the destination error looks identical.
Start with one exact source-to-target pair. “This domain has broken links” is too broad to assign a repair. Preserve the original href, including meaningful parameters and fragments, and explain what a visitor expected to find. A removed link is not a target 404: once the reference is absent, changing the target server cannot put it back on the publisher’s page.
Build an evidence record before changing anything
Record the source URL, original linked URL, observation date, request method, response and visible context. If the target redirects, record each hop and the final URL rather than replacing the original address in your notes. Keep a report’s discovery date separate from your own observation. A browser result and a server-side check can differ, so record which one you used.
A backlink export is a starting list. Google’s Links report contains sampled and historical data, so revisit the actual source before assigning a repair. When evidence is missing, retain “unknown.” Do not turn an inaccessible source into a confirmed removal or invent a date to make a record appear current.
Locate the failure: source, reference or destination
First check whether the source page is available. If it is, inspect the exact reference and nearby text. If the link is absent, review the page version and rendering conditions; the publisher controls that reference. If it is present, follow the target path. An unresolved loop, access denial, rate limit, server error or timeout needs investigation before it becomes a deletion claim.
A final 404 or 410 supports investigating an unavailable destination. A final 200 still requires a content check: an error message, empty page or unrelated landing page does not fulfil the source’s promise. Google’s status-code documentation also distinguishes a successful response from indexing. The planner records your selected response and content judgment separately; it does not claim to reproduce a search engine’s classification.
Choose a repair that preserves the reference’s purpose
If you control the failing destination, compare three options. Restore useful original content at its expected address; map a genuinely moved resource to a reviewed equivalent; or keep an intentional missing-page response when no suitable resource should exist. Ownership is about the affected site or redirect, not possession of a backlink report. If you lack control, prepare an evidence handoff for the responsible owner.
For a permanent move, consider a direct 301 or 308 to the equivalent resource. Temporary moves need a different plan. Google’s site-move guidance warns against irrelevant mass redirects. An old soil-sampling worksheet should not be mapped to a generic shop simply because both pages mention gardening. Compare the task, audience, format and needed detail before proposing a destination; never redirect a failing URL back to itself.
Work through five distinct cases
The moved-guide example has a visible source reference and an old destination returning 404. A reviewed soil-sampling guide is available elsewhere on the same example site. The proposed mapping remains a task to test, not a completed fix. In the access-denied example, the target returns 403; the next step is to investigate access, not declare the page deleted.
The removed-reference example records an absent source link while the target itself works. A redirect cannot repair that source change. The retired-page example has a 410 and no suitable replacement, so restoration or intentional absence needs a decision. The final example returns 200 with an error page; the content mismatch keeps it in review. All five are authored scenarios on reserved domains, not customer or publisher observations.
Verify the visitor path and keep the before-and-after evidence
Assign an owner, a proposed change and an acceptance check before implementation. After the actual change, revisit the exact source link and walk the path again. Record the original URL, all observed redirects, final response and whether the expected content is usable. Check for loops, accidental self-redirects and a destination that is technically live but irrelevant. Keep the earlier evidence rather than overwriting it.
Close a repair only against the recorded acceptance check. An implemented server rule is not proof that a publisher changed its page, and a successful visit is not proof that search rankings recovered. Track referral behaviour and search outcomes separately when you have data. If a check remains blocked, leave the verification open with a responsible person and a concrete next check.
Use the planner for a handoff, then monitor the real reference
Enter your own URLs and observations above, or load a fictional example. The planner prioritizes source evidence, then the exact reference, then target response and content, and finally ownership and replacement suitability. Its recommendation changes when your entries change. Missing evidence remains unknown, and a replacement matching the failing URL is sent back for comparison.
Download the current record as TXT, CSV or printable offline HTML. Notes, original URLs and uncertainty travel with the proposed action. This is a local draft: reloading clears edits, and downloads do not configure a redirect or create account records. For continuing observation, use the existing backlink-monitor workflow for supplied references. For proposing your resource as an alternative on somebody else’s page, read the separate broken-link-building guide; that outreach task is not repair of your own incoming link.