Your Migration Also Affects Acquired Links: A Protocol to Protect Their Context and Destination
Include editorial links in your migration plan: inventory the URLs receiving links, assign relevant destinations, and check redirects, context, and issues after launch.
Why acquired links should be part of the plan from the start
A migration does not just change templates, content, or internal paths. It can also change the URL that links published in media outlets, blogs, and other external pages lead to. If a linked address disappears, returns an error, or redirects to content that no longer meets the same need, the user experience suffers and an editorial relationship worth reviewing is lost. That is why existing backlinks should be part of your inventory and architecture decisions before the new website goes live. Exporting the site’s URLs and applying a general redirect rule is not enough. Each link points to a specific page and appears in a specific context: a news story, guide, listing, or mention whose meaning may depend on its destination.
- The destination URL that changes is on your website; you normally do not control the external page containing the link.
- A correctly assigned permanent redirect can lead users and crawlers to the new URL, but it does not guarantee that rankings, traffic, or other signals will be preserved.
- The goal is to maintain a useful match between the linked page and its new destination, not to preserve every link at any cost.
How to inventory the URLs receiving links and record their context
Start by creating a list of old URLs with inbound links that are relevant to the project. Combine the available sources: backlink analysis tools, crawl data, analytics or site logs, and, where appropriate, information from Search Console. No single source necessarily provides complete coverage; keep track of where each data point came from, and do not treat an isolated metric as absolute truth. For each URL, record at least the old address, its current status, the source URL of the link, the anchor text, a brief description of the context, and the page’s practical importance. Also note whether the page has traffic or conversions you want to protect and whether the link appears to still be published. If you cannot verify the source page, mark the data as pending rather than treating it as confirmed.
- Include URL variants that appear in your data, such as with or without a trailing slash, capitalization, parameters, or protocols.
- Record the extraction date and tool so you can compare reviews and understand discrepancies.
- Separate third-party metrics from verifiable facts, such as whether the page exists, where the link points, and its response code.
Choose a destination for each URL: keep, redirect, or remove
Assign a decision to each old URL before launch. If the page can remain at a stable address and is still useful, keeping it avoids unnecessary changes. If its URL is changing, find the new page that most directly covers the same topic or need. When the content has been incorporated into a broader page, check that the new page really includes the information the link pointed to. If there is no relevant replacement, do not force a redirect to the homepage, a generic category, or a page that shares only a keyword. It may be more honest to remove the content and return a not-found or permanently removed status, as appropriate. Document the decision and the reason for it, so it can be reviewed without turning reasoned exceptions into automatic rules.
- Keep: the URL is still valid, accessible, and serves the same purpose.
- Redirect: a new destination meets a comparable intent and context.
- Remove: the content no longer exists and there is no useful replacement; confirm that the response status is appropriate.
- Avoid redirect chains and loops; each old URL should lead directly to its intended destination.
Check that each redirect preserves a relevant match
The mapping table should connect each old URL to its final destination and explain why that choice best preserves the page’s purpose. Review the most important matches manually and sample the rest. Similarity between terms is not enough: compare the topic, content type, and information the link appears to recommend. During testing, verify that permanent redirects are intentional—for example, 301 or 308 where appropriate—that the destination responds correctly, and that there are no avoidable intermediate hops. Also check that the rules do not accidentally affect parameters, languages, sections, or paths that need to remain distinct. The redirect plan is a mapping guide, not a guarantee that all signals or outcomes will remain unchanged.
- Test the response code for the old URL and the final URL.
- Confirm that the destination does not redirect again to another URL or end on an error page.
- Compare the old and new content: the destination should make sense to someone who followed the link.
- Validate the rules in a test environment and keep the approved table for implementation and auditing.
What to check in links and their destinations after launch
After launch, do not consider the review complete just because the site appears to load normally. Run the set of old URLs and check response codes, redirect chains, and destination content. Also crawl the new pages to find internal links that still point to old addresses, canonicals pointing to an incorrect URL, or pages that have been blocked or left out of the index by an accidental configuration. On external pages containing links, check whether the mention is still published and which address it points to. It will not always be possible to verify every source, and some links may change for editorial reasons unrelated to the migration. Record what was checked, when, and with what result. Search engine and third-party link reports can help identify changes, but they are not necessarily a complete inventory and do not all update at the same pace.
- Check HTTP responses, final destinations, canonicals, indexability, and internal links.
- Review the sitemap and crawling directives to ensure they reflect the new architecture.
- Monitor crawl errors, referral traffic, and the performance of affected pages, comparing periods with care.
- Distinguish links that could not be verified from those confirmed as broken or changed.
When to ask a publication to update a link
Contacting the publication may be reasonable if the link is still active but points to an old address, if a redirect is not viable, or if there is a clear editorial reason for the destination to reflect an update. Make the request easy to verify: provide the article URL, the affected link, and the new address, and briefly explain why that URL is the right reference. You do not have to request changes to every link: a relevant redirect may solve the access issue without involving the editor. Prioritize pages that are most relevant to the business or present a real problem for users. If the original collaboration was paid or sponsored, be transparent and preserve the appropriate link qualification, such as sponsored or nofollow, depending on the case. Do not ask for those attributes to be removed in an attempt to change how a paid link is interpreted.
- Prioritize requests based on reader usefulness and operational impact, not just an external metric.
- Make a specific, respectful request; the publication retains editorial control over its page.
- Record the date, response, and outcome without assuming that the change will be made.
Document issues and distinguish technical errors from editorial changes
An issue does not always mean that the migration broke a link. It may be caused by an incorrect rule, an external page that removed or changed its article, a temporary crawling variation, or a discrepancy between tools. Classifying the cause helps prevent fixes that do not solve the problem and makes it easier to escalate failures that do depend on the site. Keep a log with the old URL, expected destination, observed destination, source page if known, detection date, evidence, and person responsible. Add a status and resolution so teams can close the follow-up. Repeat the checks after correcting rules and at the end of the main migration stages. This history also helps distinguish technical effects from later editorial changes, without automatically attributing every change in visibility to a single cause.
- Technical error: missing or incorrect redirect, loop, avoidable chain, incorrect response, or destination made non-indexable by configuration.
- Editorial change: the source site changes, removes, or redirects the article containing the link.
- Uncertain data: the available source does not confirm whether the link exists or which URL version it uses.
- Close each issue with verifiable evidence and an action, or document why no intervention is needed.
Frequently asked questions
Does a 301 redirect preserve the value of a backlink?+
A permanent redirect can help lead users and crawlers from the old URL to a new one, but it does not guarantee that rankings, traffic, or all signals will be preserved. The relationship between the two pages, the quality of the destination, and other factors also matter.
Should I redirect every old URL to the homepage?+
No. If the homepage does not replace the linked content, the redirect may not be useful. Look for a destination that meets an equivalent need; if none exists, consider removing the URL with the appropriate status.
Do I have to ask every publication to update its link?+
Not necessarily. If the old URL redirects correctly to a relevant page, there may be no need to get in touch. An update may make sense when it offers an editorial improvement or prevents an access problem, bearing in mind that the publication makes the final decision.
What if a link disappears after the migration?+
Check the source page and the destination separately, and record the date and evidence. If the publication removed or changed the link, that is an external change; if your destination URL fails, review your rules and the page status on your site.
How should I handle links from paid collaborations?+
Paid collaborations should be transparent, and links should be qualified as appropriate for the case, for example with sponsored or nofollow. A migration is not a reason to hide the nature of the collaboration or ask for the qualification to be removed.
Sources and references
- Google Search Essentials — Google Search Central
- Spam policies for Google web search — Google Search Central
- Qualify outbound links — Google Search Central