How to Recover Useful Links After Pages or URLs Change

When a page on your site moves, other websites may still link to its old URL. Link reclamation means making those links useful again. You can send visitors from the old URL to the right current page. You can also update links you control or ask the other publisher to fix a broken link.

Start by finding out what changed. If a moved page has a relevant replacement, use a permanent redirect. This server response sends visitors and search crawlers from the old URL to the new one and marks the move as permanent. If a deleted page has no suitable replacement, return a clear error. A mention without a link is a separate case. You can ask the publisher to add a link if it would help readers, but the mention does not prove that a link was removed or guarantee that the publisher will add one.

Find out what happened to the link

Check the old URL and, when possible, the page that links to it. The old page may have moved, disappeared, or still be live under a different URL. The external publisher may have removed the link, or may mention your site without ever linking to it. Each case calls for a different fix.

Search Console’s Links report can help you find pages that link to your site, but Google says the report shows only a sample and has reporting limits. Use it to find leads; the report does not cover every current or past backlink. Check the reported page and link directly when possible, and compare the results with migration records, site logs, or other link reports.

For each old URL, record the response the server returns and where it redirects. If you know which page links to it, include that information. Note whether a current page truly replaces the old content. That record helps you avoid sending unrelated URLs to one convenient destination.

Redirect moved pages to their relevant replacements

A redirect sends a browser or crawler to a different URL. When a page has moved permanently, Google recommends a server-side permanent redirect, such as HTTP 301 or 308. Google uses permanent redirects as a signal that the destination should be treated as the canonical URL, meaning the preferred version of the page in search.

Send each old URL to the closest relevant replacement. For example, if an article moved to a new URL but still covers the same subject, redirect the old article URL to the new one. If several pages were combined into one page that covers their material, a redirect to that consolidated page can make sense. Sending every old URL to the homepage gives visitors a destination that may not answer the question they followed the link to resolve. Google warns that irrelevant redirects can confuse visitors and be treated as soft 404s.

If no relevant replacement exists, return a real 404 or 410 response. A helpful error page can suggest other content, but the server should still return an error status so the response does not suggest the missing page exists. A 200 response alone does not prove the page works: Google may treat a page that appears empty or says its content is missing as a soft 404.

Google says permanent redirects do not cause a loss of PageRank, Google's measure of link value. That guidance supports using a redirect for a permanent move; it does not promise that a page will regain its former rankings, traffic, or conversions. Google also notes that rankings can fluctuate while it recrawls and reindexes pages after a site move. See its guidance on redirects and Google Search and site moves with URL changes.

Fix the links and check the route

Once the redirect works, update links you control so they point straight to the current URL. This includes links in your own content and URLs in your sitemap, a file that lists URLs on your site. A redirect keeps an external link useful when its publisher has not updated it; a direct link avoids sending your own visitors through an extra step. Google recommends updating internal links during a site move and using crawlable links with descriptive text.

Test the complete route from the old URL to the final page. Confirm that the old URL returns the intended response, the redirect reaches the right destination, and the destination loads the expected content. Check for redirect chains, where one URL redirects through several others, and loops, where URLs send requests back and forth without reaching a page. Google says its crawler can follow up to 10 redirect hops, but recommends keeping chains to three or fewer where possible. A crawler’s ability to follow a chain does not make a long chain useful to visitors.

After you put the changes live, revisit the old URL and the destination. Check your internal links and sitemap too. If you contact an external publisher, check the page again later to see whether the link changed. That confirms the technical or editorial change; it does not by itself show that rankings or traffic improved.

Read backlink evidence carefully

Search Console and third-party tools that report links to your site can help you find links to investigate. Their reports do not establish that every listed link is still live, or that every unlisted link never existed. Google says its Links report can omit data. It can also combine duplicate links or limit how many rows it displays. A missing entry is therefore not proof that a publisher removed a link.

Likewise, seeing a redirect in a browser confirms that the route works for that request. It does not prove that Google has recrawled the old URL, selected the new page as canonical, or restored the old page’s search performance. Track the status of the URLs and compare Search Console data over time, while allowing for other changes that can affect search traffic. Google’s published guidance does not provide a standard ranking increase or traffic gain for fixing an individual backlink.

Ask for an unlinked mention when a link would help readers

A mention without a link is worth contacting the publisher about when a direct link would help readers verify a claim, open a cited resource, or find relevant information. Suggest a specific, current destination that supports the existing text. A link to a primary study or useful explanation may serve readers better than a link to a homepage.

Keep the request polite and let the publisher decide whether the link fits. Do not demand keyword-rich anchor text, payment for ranking credit, or a reciprocal link. Google’s link guidance emphasizes useful context, and its spam policies prohibit link schemes intended to manipulate rankings. You can request an editorial link after an unlinked mention; the mention creates no entitlement to one. The available guidance does not establish a standard success rate or ranking benefit for these requests.

What URL updates mean for AI search

Bing’s webmaster guidance says timely URL-change notifications help refresh outdated references that Copilot uses to support its answers. Bing also recommends IndexNow for notifying participating search engines about added, updated, or removed URLs. These tools help keep URL information current, but they do not guarantee crawling, indexing, rankings, or a citation in an AI answer. This evidence applies to Bing’s stated services and should not be generalized to every AI search product.

Key Takeaways

• Match each old URL to its real replacement: Use a permanent redirect for a moved page when a relevant destination exists.
• Return an error for content with no replacement: A genuine 404 or 410 is clearer than redirecting visitors to an unrelated page.
• Update links you control: Point internal links and sitemap entries directly to current URLs, then test the full redirect route.
• Treat link reports as leads: Search Console’s Links report is not a complete inventory, and a working redirect does not prove a ranking recovery.
• Request an unlinked mention selectively: Ask for a link when it gives readers a useful route to supporting information, and leave the editorial decision to the publisher.

What I'm building

Delegate tasks. Get software.

Give Vroni a GitHub issue, bug report, spec, or rough idea. It reads the repo, plans the change, writes code, runs checks, and works toward a review-ready pull request.

Take a look at vroni.com