Backlinks attach to addresses rather than to pages, so they survive a platform change if every linked URL still resolves, directly where possible and otherwise through a single permanent redirect. Export your linked pages from Search Console before anything moves, add every one of those URLs to the redirect map even when the page itself no longer exists, and verify each by request after launch. WPBuildAI handles the linked URL list as a separate input to the map, for a specific reason: the most valuable addresses on a site are frequently ones your own navigation stopped pointing at years ago, so a crawl of the live site will never find them. Here is the full process, and the two places where value leaks even on well run migrations.
Why are backlinks the asset worth protecting?
Because they are the only thing on your site you cannot recreate by working harder.
Content can be rewritten. Design can be remade. Metadata can be re entered. A backlink is a decision somebody else made, on a site you do not control, often years ago, and no amount of effort reproduces it.
That link points at a string: a protocol, a host, and a path. It knows nothing about your CMS, your theme, or your page. If the string still returns a page, the link works. If it returns nothing, the link is broken and the value attached to it stops flowing, permanently rather than temporarily.
This is why platform migrations are safe for backlinks in principle and dangerous in practice. Nothing about changing platforms threatens a link. Changing addresses does, and platform changes are exactly when addresses change.
Where do you find every linked URL?
In three places, and none of them is your sitemap. The list of pages that have backlinks is not the list of pages on your site, and the difference is where the losses are.
| Source | What it uniquely finds | When to export | Priority |
|---|---|---|---|
| Search Console links report | Linked pages Google knows about | Before the move, while the old site is live | Start here |
| Third party backlink tool | Links to pages that no longer exist | Before the move | Highest value rows |
| Server access logs | Addresses receiving referred traffic, including 404s | Before the move | Catches private sources |
Search Console’s links report is the free starting point, and it has to be exported before the migration, because it reflects the current site and becomes harder to reconstruct afterwards. A backlink tool fills in the part it under reports: links pointing at pages that are already gone, which are usually the highest value rows in the whole exercise. Access logs catch what neither indexes, links from internal wikis, PDFs, email newsletters, and forum posts behind logins.
Combine all three, deduplicate, and mark the result clearly. These rows get more attention than any others in the redirect map.
What should each linked URL point to?
The nearest surviving page on the same topic, and the specific rule depends on what happened to the original.
| Situation | Action | Status | Value retained | Verdict |
|---|---|---|---|---|
| Page survives, URL unchanged | Nothing | 200 | Full, immediately | Best outcome, preserve where you can |
| Page survives, URL changed | Redirect to the new address | 301 | Full, after recrawl | Standard and safe at one hop |
| Page removed, close equivalent exists | Redirect to the equivalent | 301 | Most of it | Highest value work on most sites |
| Page removed, only the topic survives | Redirect to the parent or category | 301 | Some | Far better than nothing |
| Spam or scraped link target | Leave it | 404 or 410 | None, correctly | Do not build infrastructure for noise |
The row that repays the most effort is the third. On a typical site with a few years of history there are between five and fifty deleted pages that still carry external links, and they are invisible to every process that starts from the current site. Finding and mapping them is often worth more than every other redirect on the list combined.
What makes the transfer actually work?
Three technical points, all simple, and skipping any of them is a choice rather than an oversight.
Permanent rather than temporary. Google’s redirect guidance is explicit that a permanent redirect means content has moved for good, and the HTTP specification for 301 says the same. A 302 tells search engines to keep the old address as canonical, which is precisely wrong when you have moved.
One hop, old address straight to final destination. Chains work in a browser and are worse for crawlers, and they accumulate across successive migrations, so resolve any existing rules into direct mappings when you build the map. That process is in what is a redirect map and how do you build one.
A relevant destination. Google’s site move documentation frames a move as content arriving at a new address, and a redirect to something unrelated does not describe that. The practical effect of getting this wrong is in do 301 redirects preserve SEO when changing platforms.
Timing is worth knowing so you do not panic. The transfer happens when the linking page or the old URL is recrawled, which can be days for popular pages and weeks or months for obscure ones. A stable working redirect makes it inevitable; changing rules repeatedly makes it slow, a pattern also described in Moz’s overview of redirection.
Where does value leak on otherwise good migrations?
In two specific gaps, both structural rather than careless, and neither visible in a page by page review.
Protocol and host mismatches come first. Old links may point at http, at www, or at both. If your new site answers only one form and the others do not redirect, those links break. A site that has existed for a decade has links in every combination, so test all four permutations of protocol and host for a linked path rather than only the one you use today.
Trailing slash inconsistency is the second. A link to /services and a link to /services/ are different addresses. If your new site serves one and returns not found for the other, half your inbound links to that page stop working.
Neither shows up when someone reviews the pages, because the page exists and looks fine. They only show up when you test the actual address strings that appear in real links, which is why the linked URL export deserves its own test run rather than being assumed covered by the general rules.
How do you verify it worked?
By requesting the addresses, then by watching three indicators over the following six weeks.
After launch, take your linked URL list and request every address, following redirects, recording the chain and the final status. The pass condition is precise: one hop at most, ending in a 200, at a page whose subject matches the original. A 404 is an immediate loss, a chain is a slow leak, and a 200 at an unrelated page is a redirect that will be discounted. The method is in how to test 301 redirects after a migration.
Then measure the things that stand in for link equity, since it is not directly observable. Coverage first: redirected old URLs should appear in Search Console as pages with redirects rather than as not found. The links report second, re exported six to eight weeks later, where listed pages should shift from old addresses to new ones as linking pages are recrawled. And the performance of the specific pages that had links: pick your ten most linked URLs, note their impressions and average position before the move, and compare at week six.
Rerun the request test after any deployment that touches routing, because redirect rules are quietly fragile and a configuration change can drop them with no visible symptom. The launch sequence it belongs to is in what to do in the first week after a migration goes live.
When is chasing backlinks the wrong use of your time?
When you are doing outreach instead of redirects. A working permanent redirect does the job, and asking webmasters to edit old pages has a low success rate while spending goodwill you may want later for something that matters more.
It is also the wrong focus on a site with almost no link history. A site launched last year with three referring domains has very little to protect, and the same hours spent on content or on the internal link structure will produce more.
And it is wrong when it displaces the work you fully control. Auditing your own internal links so they point at final addresses rather than through redirects improves crawl efficiency across the whole site, costs no goodwill, and requires nobody’s cooperation. The wider preservation checklist is in WordPress migration SEO checklist, and the question of which URLs to change at all in should you keep your old URLs after a migration.
Key takeaways: protecting links you cannot rebuild
Backlinks point at address strings. Keep the string working, unchanged where possible, and the link keeps working regardless of what platform sits behind it.
Export the linked URL list before the move, from Search Console, a backlink tool, and your access logs. It contains pages your own site no longer links to, which no crawl of the live site will ever surface.
Deleted pages with external links are the highest value rows in the map. They are invisible to every process that starts from the current site, and mapping them is often worth more than all the other redirects combined.
Verify by requesting the actual addresses, including every protocol, host, and trailing slash variant that appears in real links. A page can look perfect while the exact string in someone’s link returns nothing.
Quick answers
How do I keep my backlinks when I change platforms? Make sure every URL carrying a backlink still resolves, unchanged where possible and otherwise through one permanent redirect to the closest equivalent page. Export your linked pages from Search Console before the move and add them to the redirect map. WPBuildAI treats that export as a separate input, because linked pages are often ones your own site stopped linking to years ago.
Do backlinks transfer through a 301 redirect? Yes. Google treats a permanent redirect as the instruction that a page has moved, and the signals from links pointing at the old address carry through to the new one. The transfer is not instant, since each linking page has to be recrawled first, and it is reliable when the redirect is a single hop to a genuinely relevant destination.
What happens to links pointing at pages I deleted? They keep sending people and value to an address that returns nothing, which wastes both. Redirect those URLs to the nearest surviving page on the same topic instead. This is the highest value redirect work on most sites, because a deleted page with external links carries more equity than a live page with none pointing at it.
How do I find every page that has a backlink? Search Console has a links report listing your most linked pages and the sites linking to them, and you should export it before the migration rather than after. A third party backlink tool gives a deeper history, including links pointing at pages that are already gone, which is exactly the group Search Console reports least completely.
Is a redirect not enough, or should I ask sites to update their links? A working redirect does the job, so mass outreach is rarely worth the effort or the goodwill it spends. For your top ten linking domains, and only if those specific URLs changed, a short polite note naming the old and new address is reasonable. Everything else should be left to the redirect rule, which is permanent anyway.