How to Protect Link Equity Transfer After Migration

Link equity transfers after a migration when every old URL that earns links answers with one permanent redirect (a 301) to the closest equivalent page on the new site, and when the new site stops pointing back at the old one. The rest of this guide is the order to do that in, and how to check each step worked.

What you need before you start, and what you will have at the end

You need four things: access to wherever redirects are configured (server, CDN or CMS), Search Console access for the old site, a backlink export, and a crawler that can read a staging site. The free Links report in Search Console is enough for the backlink export. A paid backlink tool will show more, but the list of your most-linked pages is usually similar.

At the end you will have a redirect map checked against your most valuable URLs, a launch-day test routine, and a monitoring routine that tells you within days whether equity is moving or leaking.

Throughout, take a company with 40 people that sells invoice-approval software. Say you are moving it from oldbrand.com to newbrand.com after a rebrand, and the blog is moving from /resources/ to /blog/. About 300 URLs are indexed. A few dozen of them hold nearly all the inbound links.

Build the inventory of URLs that have value

Start with the old site, not the new one. Crawl it and export every indexable URL. Then add every URL from three other sources: the Search Console Pages and Performance reports, your backlink export, and your analytics landing pages. Crawlers miss orphaned pages, old campaign URLs and PDFs, and those are often the ones other sites link to.

Merge the lists into one sheet with a column for linking domains per URL and a column for organic clicks. Sort by linking domains. In the example, the top of that sheet might be a 2019 integration announcement, a pricing page, a template download and a handful of blog posts. Those are the rows you will verify by hand later.

You have done this step right when no URL in your backlink export is missing from the sheet. If one is, you found a page that would have 404ed at launch.

Map every old URL to its closest equivalent

For each row, write the single new URL a person would expect to land on. Closest equivalent means the same topic and intent, not the same navigation slot. The old /resources/invoice-approval-checklist should go to /blog/invoice-approval-checklist, not to the new blog index.

Use pattern rules for the bulk. The whole /resources/ folder moving to /blog/ is one rule, not 200 lines. But review the top-linked rows by hand, because a rule will happily send a retired page to a page that no longer matches it.

Decide up front what to do with pages that have no equivalent. Our rule is this: if the page has links, redirect it to the nearest parent topic page, and if it has no links and no traffic, let it return a 404 or 410. Sending everything to the homepage is the common shortcut, and search engines tend to treat mass redirects to an irrelevant page as a soft 404, so the equity is not reliably carried.

Fix the signals on the new site before it goes live

Photo by Kanchanara on Unsplash

Redirects carry equity, but the new site has to agree with them. On staging, check that canonical tags point to the new URLs, not the old ones. Check that internal links use final URLs, so no click passes through a redirect. Check that hreflang tags, if you have them, reference the new domain, and that the XML sitemap lists only new, indexable, 200-status URLs. The guide to what belongs in a sitemap and robots file covers the rules for that file.

Also check the staging site is not blocking crawlers with a leftover noindex tag or a robots.txt disallow. This happens often enough that it deserves its own line on the launch checklist. The test is simple: crawl staging with a crawler set to respect robots rules, and confirm it can reach the pages.

In the example, the 40-person team finds that the blog template still hardcodes oldbrand.com in its canonical tag. Left alone, that tells search engines the old page is the preferred version, which works against the redirect.

Test the redirects before launch day

Take the full list of old URLs and run it through a crawler in list mode against the staging redirect rules, or against production with the rules deployed but DNS not yet switched, if your setup allows it. For each URL you want three results: a 301 or 308 status, exactly one hop, and a final destination returning 200 that matches your map.

Chains are the most common defect. A rule that sends http to https, then old domain to new domain, then /resources/ to /blog/ makes three hops. Collapse them so each old URL goes straight to its final address. If a test run throws a loop error, the fix for too many redirects walks through finding the conflicting rules.

You have passed this step when the crawl report shows zero chains, zero loops and zero redirects landing on a 404, and your hand-checked top-linked pages each land on the page you intended.

Launch with the right sequence

For a domain change, verify the new domain in Search Console first, using a Domain property so you see every subdomain and protocol. Then deploy the redirects, switch DNS, and use the Change of Address tool in the old property's settings. That tool applies to domain moves only. A path change inside the same domain, like /resources/ to /blog/, has no equivalent tool, so the redirects and the sitemap do the work.

Submit the new sitemap. If you want the old URLs recrawled sooner, also keep an old-URL sitemap live on the old domain for a while, so crawlers find the redirects quickly. Leave the old domain registered and its redirects running. Let go of neither on a schedule tied to the launch date.

The same day, spot-check the 30 or so most-linked URLs by hand in a browser and with a header checker. Automation covers volume, but a person should look at the pages that carry the links, because that is where a wrong mapping costs the most. At Comppound, migrations run through a documented checklist like this one, with one person accountable for the redirect map.

Monitor whether the equity moved

Watch the move for as long as it takes the new site to settle, and expect movement in both directions for a while. What you are looking for is a clear handover: impressions and clicks falling on the old property while the new one rises, without a net hole.

Check these on a fixed schedule, daily in the first week and then weekly:

• The Pages report in the new property, for "Not found (404)" and "Page with redirect" entries that point to URLs you expected to be live.
• The old property's crawl stats and your server logs, for search engine requests hitting old URLs that return anything other than a 301.
• A crawl of your top-linked old URLs, to confirm they still redirect in one hop to the intended page.
• Your top ten organic landing pages from before the move, compared with the same pages on the new domain.

Compare against your own pre-launch baseline from analytics and Search Console, not against a number someone quoted you. If you also want to review who links to you and whether those links are healthy, a link audit is a good follow-up once the dust settles. And for the broader launch sequence across rebrands and platform changes, the website migration SEO checklist goes through the non-redirect tasks.

What usually goes wrong, and how to recognise it

Each failure leaves a distinct symptom, so match what you see to the cause.

When the new property shows many 404s for URLs that used to be linked, the inventory missed pages. Pull the 404 list, match it against the backlink export, and add redirects for any URL with links. When a page you care about ranks in a different position than before, check whether the redirect target is really the same intent. A page redirected to a looser topic often loses its position because the match is weaker.

When Search Console reports the old URL as indexed long after launch and the new one isn't, look for a canonical on the new page that points back to the old URL, or a noindex left over from staging. When both old and new domains appear in results for the same query, redirects are probably returning a 302 (temporary) on some rules, or only some paths are redirecting. Fix the status code and the missing paths, then resubmit the sitemap. If you find near-identical pages on the new site competing with each other after merging content, the guide to fixing duplicate pages shows how to consolidate them.

Last, if your whole organic line drops and stays low well after the launch while the redirect checks are clean, the cause is usually outside redirects: lost content, changed page templates, slower pages or removed internal links. Redirects preserve the link signal. They do not preserve a page you rewrote into something else.

Want a migration run from a documented system, with one person answerable for the redirect map? See how Comppound approaches SEO for B2B SaaS.

If you are still deciding whether the blog should sit on a subdomain or a path as part of the move, settle that first with the subdomain vs subdirectory comparison, because changing it later means a second migration.