How to Handle Links During a Site Migration

My first site migration — truly managed, not just watched from the sidelines — was a disaster. No exaggeration. It was the kind of project that keeps you up at night, that makes you check Google Search Console before you've even made coffee, that turns your Slack notifications into a source of dread. A B2B software company had hired us to migrate from an old custom CMS to WordPress, changing their domain from a .net to a .com in the process. We'd planned for three months. Spreadsheets were built. Checklists existed. A staging environment was running. And within 48 hours of going live, organic traffic had dropped by 60%.

Key Takeaways

• Why Migrations Are So Dangerous for Links
• Building the Redirect Map: The Single Most Important Step
• The Redirect Implementation Itself
• Redirect Chains and Loops: The Silent Killers
• What Happens to Your Links in Google's Eyes
• The Tools That Make This Survivable

Here's what stung most: the technical migration itself went fine. Pages loaded. Design looked great. Content was all there, and the CMS actually worked. What we'd botched was link preservation. So focused on making the new site functional, we hadn't given enough attention to the thousands of backlinks pointing at the old domain. Redirect mapping was incomplete. Some redirects pointed to the wrong pages. Others were missing entirely. A chunk of the old URLs returned 404 errors instead of redirecting anywhere at all. Every one of those broken links represented equity we'd lost — some of it from links the client had spent years building.

Six years have passed since then. I've managed a lot of migrations in that time, and I'd like to say they've all gone smoothly. They haven't. Progressively less catastrophic, though, mostly because I've learned — painfully, repeatedly — where the land mines are. Facing a site migration and worried about your links? Good. You should be worried. That worry might save you.

Why Migrations Are So Dangerous for Links

At its core, a site migration is any significant change to a website that affects its URLs, structure, or domain. Switching domains, moving from HTTP to HTTPS, changing your URL structure, replatforming to a new CMS, merging multiple sites into one — any of these qualifies. Sometimes it's all of these at once, which is — and I can't stress this enough — a terrible idea. Change one thing at a time if you have any choice in the matter. Business decisions don't always accommodate SEO best practices, though, so sometimes you're changing everything simultaneously and just trying to survive.

Why are links so vulnerable during this process? It boils down to one thing: URLs change, but backlinks pointing to your old URLs don't update themselves. A blog that linked to your site three years ago isn't going to go back and edit their post to use your new URL. Why would they? Most don't even know you migrated. So those links just point at URLs that no longer exist. Without proper redirects, that link equity evaporates. What was once a valuable referring link becomes a dead end. Google's crawler follows it, hits a 404, and the value that link was passing? Gone. Not transferred. Not preserved. Just gone. You might also find Internal Linking Audit: A Step-by-Step Guide useful here.

Individual links are only part of the picture, though. Your domain authority — or whatever you want to call the aggregate link equity your entire domain has accumulated — faces serious risk during a domain change. Moving from olddomain.com to newdomain.com means Google has to understand that these are the same entity, that all the trust, authority, and link signals from the old domain should transfer to the new one. Nothing about this transfer happens automatically just because you want it to. Proper redirect implementation, Search Console settings, and patience are what make it work.

Building the Redirect Map: The Single Most Important Step

Picking one thing that determines whether a migration succeeds or fails from an SEO perspective? It's the redirect map. Every time. A document — usually a spreadsheet, sometimes a CSV file — maps every old URL to its corresponding new URL. Every. Single. One. Not just the important pages. Not just the ones you remember. Every URL that has ever been indexed or received a backlink needs to map somewhere.

Here's how I build one these days. Start by getting a complete list of old URLs from multiple sources, because no single source gives you everything.

Crawling the existing site with Screaming Frog comes first. Set it to crawl all pages, resources, everything. Export the full URL list. For a site with 5,000 pages this might take thirty minutes. Half a million pages? You're looking at hours, and you'll need to configure Screaming Frog's memory settings to handle it. Default allocation won't cut it for large sites.

Next, pull URL data from Google Search Console. Performance reports show which URLs have received impressions and clicks. Coverage reports reveal which URLs Google has indexed, tried to index, or excluded. Export all of it. Certain URLs in Search Console won't appear in your Screaming Frog crawl — pages that have been deindexed or removed from the site's navigation but that Google still knows about.

Now for the step people skip, which drives me crazy — pull backlink data from Ahrefs or a similar tool. Export all backlinks, extract unique target URLs, and add those to the list. External sites are actually linking to these URLs. When a URL has backlinks but doesn't show up in your crawl or Search Console data, it might be an old page that was deleted years ago but still has live links pointing to it. Redirecting that URL matters because that's where the link equity lives.

Check your XML sitemaps too. Sometimes sitemaps contain URLs that aren't discoverable through crawling, especially on sites where the sitemap has been manually maintained rather than auto-generated.

Last — and this one's a bit tedious — visit the Wayback Machine. For sites with a long history, old URLs might no longer exist anywhere on the current site but still have backlinks from years ago. Archived snapshots can show you what those pages used to contain, which helps you decide where to redirect them. For a deeper look at this topic, see our guide on How to Fix Orphan Pages with Internal Links.

Once you've compiled all these URLs into a single deduplicated list, actual mapping begins. For every old URL, identify the best corresponding page on the new site. Ideally, it's an exact match — the same content at a new URL. In practice, though, site migrations often involve content restructuring. Pages get merged. Sections get reorganized. Product categories change. Blog posts get consolidated. A perfect 1:1 match on the new site won't always exist.

When there's no exact match, redirect to the next most relevant page. An old product page for a discontinued product might redirect to the parent category page. A merged blog post redirects to the longer guide it became. Topical relevance is the key principle here. Redirecting everything to the homepage is basically a soft 404 in Google's eyes, and you'll lose most of the link equity. Redirects should make sense to a user who follows them. Someone clicking a link and expecting an article about email marketing best practices shouldn't land on your homepage — that's a bad experience, and Google knows it.

My redirect map spreadsheets use these columns: Old URL, New URL, Status Code (almost always 301 for permanent redirects), Number of Backlinks (from Ahrefs), Referring Domains, and Notes. Backlink data columns help me prioritize. A URL with 47 referring domains linking to it? That redirect absolutely must be correct. Zero backlinks and no organic traffic? Still worth redirecting, but a mistake there won't keep me up at night.

The Redirect Implementation Itself

With the map built, implementation on the server comes next. How you do this depends on your setup. Apache servers typically mean working with the .htaccess file. Nginx uses server configuration files. Cloudflare or another CDN? Their redirect rules might be the right tool. Some CMS platforms have built-in redirect managers — WordPress has plugins like Redirection or Yoast's premium redirect feature. For large-scale migrations, I've sometimes used a combination: a plugin for content-level redirects and server-level rules for pattern-based redirects.

Pattern-based redirects become your best friend on large sites. When your URL structure is changing predictably — say, from /blog/2024/post-title to /articles/post-title — a regex-based redirect rule handles all of those at once instead of creating individual redirects for each post. Something like:

RewriteRule ^blog/\d{4}/(.*)$ /articles/$1 [R=301,L]

Careful with regex redirects, though. Test them thoroughly. Once, I wrote a pattern-based redirect that seemed correct in testing but had an unintended match catching a bunch of non-blog URLs, sending them to the wrong place. Three days passed before we noticed, because the affected pages weren't high-traffic. By then, Googlebot had already crawled the broken redirects and started deindexing the pages. Full recovery took weeks.

After implementation, testing is non-negotiable. My process runs in three waves. First, a manual spot-check of the 50 or 100 most important URLs — those with the most backlinks and the most organic traffic. Just type the old URL into a browser and make sure it lands on the right page. Second, upload the full redirect map into Screaming Frog's list mode and crawl all old URLs to verify they return 301 status codes and resolve to the correct new URLs. Screaming Frog makes this pretty painless — you can see the redirect chain, the final destination, and the status code for each URL. Third, after launch, check Google Search Console's coverage report daily for the first two weeks, watching for spikes in 404 errors or unexpected crawl issues.

Redirect Chains and Loops: The Silent Killers

Something that bites people on sites that have migrated more than once: redirect chains. Picture URL A redirecting to URL B, which redirects to URL C, which maybe redirects to URL D. Each hop in the chain dilutes a little bit of link equity. Google says they'll follow up to about five redirects in a chain, but that doesn't mean you should have five. Best practice is updating old redirects so they point directly to the final destination. Migrated from domain-a.com to domain-b.com three years ago, and now moving from domain-b.com to domain-c.com? Update the old domain-a.com redirects to point directly to domain-c.com. Leaving the three-hop chain in place is asking for trouble. For the full picture, read 301 vs 302 Redirects: Impact on Link Equity.

Redirect loops are worse. URL A redirects to URL B, which redirects back to URL A. Browsers spin forever. Users see an error. Crawlers give up. Any link equity pointing at either URL is effectively lost. I've seen redirect loops created accidentally during migrations when someone sets up redirects from old URLs to new URLs on the new server while the old server still has redirects in place pointing to... the old URLs. A circle forms. Always check for loops in your testing phase. Screaming Frog will flag them.

What Happens to Your Links in Google's Eyes

Setting up a proper 301 redirect means Google passes the vast majority of link equity from the old URL to the new one. Years ago, Google confirmed that 301 redirects no longer result in any PageRank loss — they pass full link value. Earlier claims suggested that 301s lost about 15% of equity. Whether or not that was ever true, Google's current position is that 301s pass full value. Temporary 302 redirects also pass link equity now, according to Google, though I still recommend 301s for permanent moves because the semantics are correct and it removes any ambiguity.

Here's the catch with domain migrations specifically. Even with perfect redirects, Google needs time to transfer authority from one domain to another. In my experience, there's almost always a traffic dip after a domain migration — even a well-executed one. Duration varies: anywhere from a few weeks to several months, depending on the site's size and the competitiveness of its keywords. I've seen sites recover to pre-migration levels in three weeks. Others have taken six months to fully recover. Longer recoveries usually involve some redirect issues discovered late, or content changes that happened simultaneously with the migration.

Keeping the old domain's redirects active for as long as possible helps considerably. Don't let the old domain registration lapse. Don't turn off the old server after a month. Keep those 301 redirects running for at least a year, ideally indefinitely. Google will eventually update its index and old URLs will fade away, but you can't control when individual external sites update their links (most won't), and you want those links to keep passing value through the redirects for as long as they exist.

The Tools That Make This Survivable

Screaming Frog has come up a few times already, and there's a reason — it's probably the most important tool for managing a migration. Crawling a full site before and after, comparing the two crawls, checking redirect chains, validating status codes, verifying that important pages are still accessible — all of that in one tool. Particularly valuable is the comparison feature, where you crawl the old site, save the crawl data, then crawl the new site and compare URL structures. Every migration I manage uses it.

Google Search Console is equally critical. Before the migration, verify both the old and new domains (or URL prefixes, for structural changes on the same domain). After the migration, use the Change of Address tool when moving domains — it tells Google directly that you've moved and to transfer signals from the old property to the new one. Watch the Index Coverage report like a hawk for the first few weeks. Look for increases in "Not found (404)" errors, drops in valid indexed pages, and any pages stuck in "Crawled – currently not indexed."

Ahrefs or a similar backlink tool rounds out the triad. Before the migration, export your complete backlink profile and note which pages have the most link equity. After the migration, monitor for broken backlinks — Ahrefs has a "Broken backlinks" report that shows external links pointing at your URLs that return errors. Backlinks that should be redirecting but aren't indicate a gap in your redirect map that needs fixing immediately.

I also keep a custom spreadsheet that I update daily for the first month post-migration. It tracks organic traffic (from Google Analytics or whatever analytics platform you use), indexed pages (from Search Console), referring domains (from Ahrefs), and any 404 errors discovered. Plotting these on a timeline helps you see whether the migration is settling in or whether something is going wrong. Traffic dips are normal. Falling off a cliff and not recovering after two weeks? Something broke. We wrote an entire guide on this: Canonical Tags and Their Effect on Links.

The Mistakes I Keep Seeing

After doing this enough times, patterns emerge. Below are the mistakes that come up over and over, on sites of all sizes, with teams of varying experience levels.

Starting too late. Redirect mapping for a large site takes weeks. Not hours. Weeks. Three days from launch with no redirect map started? You're in trouble. My process begins at least six weeks before the planned migration date for any site over a few hundred pages.

Only redirecting "important" pages. Every indexed URL with any backlinks or any historical traffic needs a redirect. Collectively, those "unimportant" pages might have more link equity than your top ten pages combined. Content-heavy sites where hundreds of older blog posts each have a few referring domains prove this point — individually they're nothing, but combined, they represent a significant chunk of the site's total authority.

Changing content and URLs at the same time. Rewriting product descriptions, redesigning templates, restructuring site architecture, AND changing your domain gives Google too many variables to process simultaneously. When traffic drops (and it will), you won't know which change caused which effect. Whenever possible, migrate first and make content changes later. Or make content changes first, let them settle, then migrate. Stacking everything into one launch is a recipe for confusion.

Overlooking internal links. Subtle, this one. You migrate your site, set up all your external redirects, and feel good. But internal links within your content — from one blog post to another, from product pages to category pages, from your about page to your service pages — might still reference the old URL structure. Instead of linking directly to new URLs, they're linking to old URLs that redirect. Unnecessary redirect chains within your own site result from this. Update all internal links to point to new URLs directly. Find-and-replace on your database or a bulk update through your CMS can handle this, but it needs to be part of the migration plan.

Failing to communicate with link partners. Significant link building relationships — sites that regularly link to you, partners, affiliates — deserve a heads-up. Let them know you're migrating and give them the new URLs. Most won't update their links (honestly), but some will, and every link that points directly to the new URL instead of going through a redirect is one less thing that can break down the road.

A Real Migration Timeline

For context, here's roughly what a migration timeline looks like for a mid-size site (5,000–20,000 pages) when things are done properly. Six weeks before launch: begin URL inventory and redirect mapping. Four weeks out: finalize the redirect map, set up the new site on a staging environment, and start testing. Two weeks out: implement redirects on the staging server and run a full validation crawl. One week out: final testing, set up monitoring dashboards, notify key link partners. Launch day: flip the switch, verify redirects are live, submit the change of address in Search Console, monitor in real time. Weeks one through four post-launch: daily monitoring of Search Console, analytics, and backlink tools. Fix issues as they surface. Months two and three: weekly monitoring, looking for full recovery of organic traffic and indexed page counts.

That timeline assumes a domain change with URL restructuring. Just changing URL patterns within the same domain? Compress it. Migrating a site with hundreds of thousands of pages? Extend it significantly. See also our post on Rel Attributes Explained: nofollow, sponsored, ugc for more on this.

Even with all that preparation, something will go wrong. I don't say that to be pessimistic — I say it because in every single migration I've been involved with, every one, something unexpected came up. A batch of URLs that weren't in any of our data sources. A redirect rule that conflicted with another rule. A server configuration that handled trailing slashes differently than expected. An old subdomain that nobody remembered existed until someone's links started 404-ing. Always something.

So the real question isn't whether your migration will go perfectly. It won't. What matters is whether you've built enough structure and monitoring into the process to catch problems quickly and fix them before they cause lasting damage to your link equity. Between a migration that loses 5% of organic traffic for two weeks and one that loses 60% for six months, the difference usually isn't the plan — it's the response. How fast did you find the broken redirects? How quickly did you patch the gaps? Were you watching closely enough to notice?

Honestly, I still wonder whether it's possible for a large-scale migration to go completely smoothly. No traffic dip. No lost links. No redirect errors discovered three weeks after launch. Maybe somewhere, someone has pulled it off. Haven't seen it yet, though, and I'm not sure I ever will.