Link Reclamation: How to Find Lost Backlinks and Decide Which to Recover

Link reclamation is the recovery of backlinks you already earned and then lost: you find the links that no longer work, work out what changed, and decide what to do about each one. It is not outreach for new links, and it is not repairing someone else's dead resource. The causes split into things that changed on your side and things that changed on theirs, and that split decides whether you can fix a link yourself or have to ask. Two kinds of reader arrive here: one whose referring-domain count just dropped, and one whose B2B software company is weeks away from a replatform and would rather not join the first group. This guide covers how to find the losses, how to tell a real one from a reporting artifact, and how to choose between restoring the page, redirecting it, and letting it go.

The short version

• Finding the lost links is the easy half. Deciding what to do with each one is where the value sits, and it is a different job entirely.
• Two different problems wear the same label. Either your target URL stopped working, or the linking page changed. Only the first can be fixed without asking anyone.
• Restoring a page, redirecting it, and leaving it are three answers with three different results in search. Google's documentation states that permanent redirects "Show the new redirect target in search results" and temporary redirects "Show the source page in search results."
• Migrations, replatforms and redesigns lose links in batches, which is why this work belongs next to your redirect map rather than next to your outreach list.
• A lost-links report is a sample, not a ledger. Search Console's own documentation says the Links report "isn't a comprehensive list of every link on your site."

What is link reclamation, and what is it not?

Recovering links you already had. Somebody made an editorial decision to cite you, that link stopped resolving or stopped existing, and reclamation is everything you do after noticing. Noticing is the cheap part.

Three tactics all end in a link you did not have this morning, and they are separated by one question: whose page is broken?

• Link reclamation: your page is broken, missing or moved, and someone is still linking to where it used to be. Most of the work is on your own server.
• Broken link building: somebody else's resource is dead, and you are proposing yours in its place. Qualifying one of those before it costs you an email is its own job, and our guide to broken link building works through it.
• Unlinked mentions: nothing is broken at all. Your brand was named without a link, so there is no link to reclaim, only one to ask for. Our guide to link building holds the full tactic inventory and routes that decision to the right place.

Why do backlinks disappear in the first place?

Because something changed, either on your side or on theirs. The causes sort cleanly into those two buckets, and the middle column below is the one worth reading first.

Cause	Whose side	What it looks like in a report
A page was deleted in a content cleanup	Yours	The linked URL returns 404
URLs changed in a migration or replatform	Yours	Old URLs 404, or resolve through a chain nobody finished
A redesign consolidated pages into hubs	Yours	The old URL lands on a generic page that does not answer the citation
A page was set to noindex or pointed at a different canonical	Yours	The link resolves, but the target stops being the indexed URL
The publisher refreshed the article and dropped the link	Theirs	Linking page is live, your link is gone from it
The linking page was deleted or moved	Theirs	The referring URL 404s or redirects elsewhere
The backlink index could not crawl the referring page	Neither	A loss is recorded while the link sits untouched on the page

Migrations and redesigns show up as a cliff rather than a drift. A cleanup removes pages one at a time; a replatform changes every URL at once, and any URL you did not map goes from a working target to a 404 on the same afternoon. Our site migration checklist covers the redirect map that is supposed to prevent that, and it is the control that decides how much of this article you will ever need.

How do you find the links you have already lost?

With two sources, because neither one is complete on its own. A backlink index gives you volume and a loss reason; Search Console gives you what Google itself recorded.

Step 1. Pull the lost-links view from a backlink index: the major indexes all have one, and where yours reports a loss reason alongside the link, that reason is the first thing to read. Filter before you read a single row, because a raw export mixes real losses with rows where nothing actually changed.

Step 2. Cross-check against Search Console: the Links report is the only view built from Google's own crawl rather than a third-party one, and it is worth reading with its caveat attached. Google's documentation for the Links report says it "isn't a comprehensive list of every link on your site. It shows a sample of internal and external links to help you understand your site's overall link profile." Use it to confirm, never to count.

Step 3. Crawl your own target URLs: take the linked-to URLs from both exports and run them through a crawler as a list. This turns a link report into a fix list, because it tells you which of your own URLs are 404ing, redirecting, chaining or serving a noindex. Everything in that column is yours to fix without contacting anyone.

Step 4. Open the linking pages that still exist: a status code tells you the page loads. It does not tell you whether your link is still in the markup, whether it survived a content refresh, or what rel attribute it now carries. Somebody has to look.

How do you tell a real loss from a reporting artifact?

By checking whether anything actually changed on either page. Ahrefs, for example, records a lost link when its own crawl of the referring page fails, which is a database event rather than a link event, and those rows quietly inflate whatever you build on top of them.

Google flags a related limitation in its own data. The Links report "includes links that Google has found over time. These links may have since been removed, or a page may no longer exist," and the report "doesn't specify if a link is marked as nofollow." Neither source is describing the present tense with precision.

Three classes to strip out before you treat the list as a work queue:

• Crawl failures: the index could not reach the referring page on its last attempt. That says something about the crawl, not about the link, and the row clears when the next crawl succeeds.
• Index drops: the referring page was removed from the tool's database, not from the web. Nothing happened to your link.
• Normalization changes: the referring page moved to HTTPS, gained or lost a trailing slash, or was consolidated under a different canonical, and the link came with it.

Ahrefs' guide to link reclamation, read on 2026-09-19, labels both its "crawl error" and its "dropped" category "Not worth pursuing", for the same reason.

Restore, redirect, or let it go?

Redirect when an equivalent page already exists. Restore when the citation was about that specific page and nothing else does its job. Let it go when neither is true.

Ahrefs' guide to link reclamation, read on 2026-09-19, sorts lost links into eight reason codes and gives each one a worth-pursuing verdict. It does not set out a rule for choosing between restoring the page, redirecting it, and leaving it, and the words migration, redesign and replatform do not appear on it. Where it does cover a URL you moved deliberately, it reads the resulting lost link as expected rather than as something to fix. Every observation here is bounded to that one page as it read on 2026-09-19. The table below is the half we found missing.

The situation	The move	What follows
Your URL 404s and a page doing the same job already exists	Permanent redirect to that page	Google: permanent redirects "Show the new redirect target in search results"
Your URL 404s, the citation is about that specific resource, and nothing replaces it	Restore the page at its original URL	The link resolves again with no hop, and the referring sentence stays accurate
Your URL changed in a migration and was never mapped	Add the missing permanent redirect, old to new, one hop	Signals consolidate on the new URL over the next crawl cycles
The old URL redirects, but through a chain or into a generic hub	Repoint the first hop at the real destination	Google's site move guidance advises redirecting to the final destination directly
Your page is up but carries noindex or points its canonical elsewhere	Decide which URL should be indexed, then make the directives agree	The link was never lost. Its target was withdrawn from the index
Your page is temporarily down while you rebuild it	Temporary redirect, and put it back	Google: temporary redirects "Show the source page in search results"
Your page was removed on purpose and has no equivalent	Let it go	Sending it to the homepage is not a fix, and our 301 and 302 redirect guide explains the reason
Your page is fine and the publisher removed the link	Nothing on your side. Outreach or accept it	This is the only row where an email is the whole remedy

The permanent and temporary redirect consequences in the third column come from Google's documentation on redirects and Google Search, which repays a full read before anyone touches a redirect map.

Based on my experience, the restore-versus-redirect call comes down to a single question: was the link about that page, or about the topic? If a writer cited a specific teardown, benchmark or comparison, redirecting them to a category hub breaks the citation while returning a perfectly clean 200, which is why no status-code report will ever flag it. If the link was a general reference on the subject, the nearest equivalent page is a fair destination and a redirect is the cheaper answer.

Restoring has a cost worth naming. You are putting a page back into your index that you removed for a reason, and it will need an owner, a refresh cycle and a place in the internal link graph like any other page. Restore when the links justify it. Do not restore a page you will orphan again in six months.

When do you actually have to email someone?

When the change happened on their side. Every row in the table above that a redirect can fix should be fixed with a redirect, because it is faster, it cannot be declined, and it does not spend goodwill you may want for a real campaign later.

Three cases genuinely need a message:

• The publisher removed or replaced your link: the page is live and working, so there is nothing technical to repair. Worth a note only if the page still warrants the link on the merits.
• They link to an old URL and you would rather not rely on a redirect forever: Google's guidance on moving a site tells you to "Try to contact the sites in the saved list of sites linking to your current content, asking them to update their links to your new site."
• The linking page itself now returns a 404: a short message asking whether the deletion was intended costs nothing, and is worth sending when the page carries a lot of links of its own.

Google's same page gives the prioritization rule: "Consider prioritizing your efforts by the number of inbound visits for each link." That is a better sort order than referring-domain count, because it reflects whether anyone is walking through the door. Winning that coverage to begin with takes a different set of skills, which is the territory our Digital PR practice covers.

Which lost links are not worth chasing?

The ones where nothing actually changed, and the ones you would not want back. Deleting those rows before they become a to-do list is most of the discipline here.

• Crawl errors and index drops: nothing happened. Filter them out at the export stage rather than investigating them one by one.
• Links from pages that are no longer indexed: the link is intact. What changed is whether search engines count the page carrying it, and that is the publisher's decision to reverse, not yours.
• Pages you deleted on purpose: a thin post, an outdated announcement, a duplicate. If the page was wrong to have, it is still wrong to have with a link pointing at it.
• Referring pages that changed subject: the article that cited you is now about something else. Asking for the link back is asking a stranger to make their page worse.
• Links you would decline if they were offered today: if you would not want it now, losing it is not a loss.

We are not publishing a recovery rate for reclamation outreach, because we do not have one we can stand behind. It would not change the plan in any case. Treat the redirect half of this work as required and the outreach half as optional, and the arithmetic stops mattering.

How do you stop losing them on the next launch?

By making the linked URLs a launch blocker rather than a post-launch discovery. Writing a redirect map entry in advance is cheaper than finding the loss, diagnosing it and fixing it afterwards. Four steps, in order.

Export the linked URLs first: before anything is renamed, pull the list of your own URLs that have external links pointing at them. Do this from the backlink index and from Search Console, then merge.

Map every one of them explicitly: the redirect map has to name each linked URL and its destination, individually. A pattern rule that covers "most" of a directory is how a page with nine referring domains ends up on a generic hub.

Test the map against the export, not the sitemap: the sitemap lists URLs you still have. The export lists URLs other people still point at, and those are not the same set.

Keep the redirects in place: Google's site-move guidance says to "Keep the redirects for as long as possible, generally at least 1 year. This timeframe allows Google to transfer all signals to the new URLs, including recrawling and reassigning links on other sites that point to your old URLs."

In our implementation work, the export that matters is the list of URLs that have links, not the list that has traffic. A page with no sessions and nine referring domains is exactly the kind a content cleanup deletes, and the redirect map is the only place that decision gets caught before it ships.

How often should you run this?

On events, not on a calendar. A recurring reminder produces a report; a trigger tied to a release produces a fix.

• Every release that changes a URL: check the linked URLs in the diff before the deploy, not after.
• Around a redesign or replatform: once to build the map, once at launch, and once a week later to catch what the map missed.
• After a content cleanup: deleting pages is the cause easiest to forget, because nothing breaks on the day.
• Once a quarter for everything else: enough to catch publisher-side changes while the article is recent enough for a message to make sense.
• Twelve months after a migration: the point Google's guidance names for signals to have transferred, and a point to check rather than assume.

One rule does most of the work here, and it is smaller than any schedule: nothing ships that changes a URL until the linked URLs are on the redirect map. Hold that line and there is very little left to reclaim, because the URL never breaks to begin with.

This week, pull your lost-links export, keep only the rows where the broken URL is one of yours, and sort by referring domains. Work the top ten against the decision table above. Every one of those is a fix you can make on your own server, without sending a single email.