A website migration is the only routine project that can wipe out years of search visibility in a single afternoon. Rebuilds, replatforms, domain changes and even a tidy-up of URL structure all carry the same risk, and the damage rarely announces itself on launch day. It shows up two weeks later as a quiet, steady decline that nobody connects to the release.
The good news is that the causes are well understood and almost entirely preventable. In practice, nearly all migration traffic loss traces back to one thing: an incomplete redirect map. Everything else in this guide is secondary to getting that right.
The one rule: Every URL that currently exists and has any value — traffic, backlinks, or indexed status — must resolve to a single permanent redirect pointing at its closest equivalent on the new site. Not the homepage. Not a chain of three hops. One redirect, to the genuinely equivalent page.
You cannot redirect URLs you do not know about, and no single source lists them all. Pull from four and merge.
A full crawl of the existing site. This gives you everything reachable by following links, which is the majority but never the whole picture.
Search Console data. Export every URL that has received impressions or clicks. This catches pages that earn traffic but nothing links to internally, which is more common than people expect.
Server access logs. These show what is actually being requested, including old URLs that no longer appear anywhere on the site but still receive traffic from bookmarks, emails and external links.
Your backlink data. Any URL that other sites link to carries value you will lose if it stops resolving. These are the highest-priority redirects in the whole exercise, because the link equity is not recoverable by other means.
Merge those four into one list, deduplicate, and you have the real surface area of your site. On a mature site it will be considerably larger than anyone estimated, and that number alone often changes the project plan.
Map every URL to its closest equivalent. Where a page has a direct replacement, that is easy. Where content has been consolidated, point to the page that now covers the topic. Where content has genuinely gone and has no successor, allow it to return a 404 or 410 rather than redirecting it somewhere irrelevant.
Resist the temptation to redirect everything to the homepage. Search engines treat a redirect to an unrelated page as a soft 404, so it passes nothing on and produces a poor experience for anyone following an old link. A deliberate 404 on genuinely removed content is a better outcome than a misleading redirect.
Use permanent redirects, and make sure they are single hops. Redirect chains, where the old URL points to a second URL which points to a third, are common after a site has been migrated more than once. Each hop adds latency and dilutes the signal, so always map to the final destination, not to whatever the previous migration left behind.
Watch the details that are easy to miss: trailing slashes, uppercase characters, query-string parameters that produce distinct indexed URLs, and the protocol and subdomain. A migration that fixes the pages but leaves http and www variants unhandled has doubled its problems.
Canonical tags and hreflang. After migration, canonicals must point at the new URLs. Stale canonicals pointing to the old domain are a genuinely effective way to prevent the new site being indexed at all. If you run multiple languages, every hreflang cluster has to be updated in step, since a mismatch invalidates the whole set.
Structured data. Any schema on the old pages should carry across, including URLs inside it. It is easy to migrate the visible content and lose the markup, which quietly removes eligibility for rich results.
Metadata. Titles and descriptions should transfer deliberately rather than being regenerated by the new platform's defaults. A rebuild that replaces well-tuned titles with a template pattern will lose clicks even if rankings hold.
Page speed. A new site is often heavier than the one it replaced. Since Core Web Vitals are assessed on field data collected over a rolling period, a slower site takes weeks to show its full effect, by which time the cause is easy to misattribute. Our guide to Core Web Vitals covers what the thresholds actually require.
Before going live, test the redirect map against the full inventory on a staging environment. Automate it: request every old URL, assert a single 301 and the expected destination. Doing this by hand on a sample will miss the pattern that breaks a thousand URLs.