Site Migrations: How to Change Platforms or Domains Without Losing Your SEO

A site migration is one of the few projects where doing nothing wrong still isn’t enough — you can execute every visible part flawlessly and still watch organic traffic fall 40% in the weeks after launch, because the damage happens in places nobody demos in a stakeholder review. Search engines don’t see your new site as an upgrade to the old one by default. They see a different set of URLs and have to be told, explicitly and completely, how the old ones map to the new ones. Skip that, even partially, and years of accumulated ranking signal gets treated as gone rather than moved.

This comes up constantly: a rebrand that moves domains, a replatform from a legacy CMS to something modern, a redesign that “cleans up” the URL structure along the way. All three are good reasons to migrate. None of them are exempt from the mechanics below.

Map Every URL Before You Touch the Old Site

The single most common failure is starting the migration checklist after the old site is already gone. You need a complete list of every indexed URL on the current site — pull it from Google Search Console’s coverage report, your XML sitemap, server logs, and a crawl (Screaming Frog or similar), because no single source is complete on its own. For every URL on that list, decide where it goes on the new site before launch, not after someone notices a spike in 404s.

Old URLs that no longer have a direct equivalent still need a destination — the next most relevant page, not the homepage by default. A blanket redirect-everything-to-home pattern preserves almost none of the original ranking value and reads to search engines as a soft-404 pattern across your whole site.

Redirect With 301s, Not Meta Refreshes or JavaScript

A permanent 301 redirect is the only mechanism that reliably passes ranking signal from the old URL to the new one. Client-side redirects — a meta refresh tag, a JavaScript location.href change — get discovered late by crawlers, sometimes not at all, and pass along little to none of the original page’s authority. If your new stack makes server-level redirects awkward (some static-site setups do), solve that at the hosting or CDN layer rather than shipping a JS redirect and hoping.

Redirect chains are the second-most common mistake: URL A redirects to B, which redirects to C, because two migrations happened two years apart and nobody cleaned up the first set. Each hop in a chain leaks a little authority and adds latency; audit your redirect map periodically and collapse chains down to a single hop from the original URL straight to the current one.

Match Content, Not Just URL Structure

A redirect maps a URL to a URL, but what actually preserves rankings is topical relevance surviving the move. If /services/web-design becomes /what-we-do/design and the destination page covers a materially different scope, the redirect is technically correct and practically useless — search engines re-evaluate relevance on the new page’s actual content, not on the redirect’s existence. When a migration is also a content overhaul, do the content mapping exercise explicitly: which old page’s audience, keywords, and intent does this new page actually serve. If the answer is “none, closely,” that old ranking isn’t transferring regardless of what the redirect map says.

Update Internal Links, Don’t Just Rely on Redirects

Redirects are a safety net for external links and old bookmarks you don’t control. Internal links are yours to fix directly, and leaving them pointing at old URLs — even ones that redirect correctly — adds an unnecessary hop to every internal crawl path and dilutes the link equity that would otherwise flow straight to the destination page. Before launch, crawl the new site and confirm internal navigation, footer links, and in-content links point at final URLs, not redirect sources.

Resubmit, Don’t Assume

Once the new site is live: submit the new XML sitemap in Search Console, and if the domain changed, use the Change of Address tool rather than waiting for organic re-discovery. Keep the old domain’s Search Console property active and monitoring — you need it to confirm the redirects are being crawled and followed, and to catch crawl errors on URLs you didn’t know existed. Expect a temporary dip in rankings even on a clean migration; search engines need time to re-crawl and re-evaluate the full URL set, and that lag is normal, not a sign something broke. What should not happen is a dip that fails to recover after four to six weeks — that’s the signal something in the mapping was wrong, and it’s worth a full crawl comparison against your pre-migration URL list rather than waiting it out.

Treat It as a Project With a Gate, Not a Deploy

The teams that come out of a migration with traffic intact treat the URL map as a deliverable with a review step, the same way they’d review a database migration script — because that’s functionally what it is. The teams that lose traffic treat redirects as a cleanup task somebody gets to after launch. By then the old site is gone, the URL list is reconstructed from memory and analytics gaps, and the fixes are happening after the damage is already visible in the rankings instead of before it ever occurs.

PNK WORKS has run replatforms and domain migrations without the traffic dip that usually comes with them. Start a project.