SEOAny

Migrating a Website Without Losing Search Visibility

Migrations lose traffic for predictable, preventable reasons. Here is the sequence that avoids them.

This is an implementation example, not a client case study. It describes how this work is actually carried out — the method, the sequence and the reasoning. No client is named and no result is claimed, because inventing either would make it worthless as evidence.

Website migration sequence preserving URLs and search visibility

Migration traffic loss is almost never caused by the new site being worse. It is caused by URLs changing without redirects, redirects chaining, internal links pointing at old addresses, and nobody noticing for six weeks because tracking was reinstalled on launch day.

Project type
Platform migration or rebuild with existing search visibility
Sector
Any

The challenge

Everything that carries search equity — URLs, content, internal links, structured data — is easy to lose during a rebuild, and the loss shows up weeks later when it is hard to attribute and expensive to reverse.

The objective

Land the new site with search visibility intact, and be able to prove it either way from data captured before the move.

Approach

Treat the old site as a specification. Everything it does well is a constraint on the new one. Capture the baseline first, because without it a post-launch dip cannot be distinguished from normal fluctuation.

Implementation

Before

  1. Export every URL. Crawl the live site; do not trust the sitemap to be complete.
  2. Export Search Console performance by page, twelve months.
  3. Record Core Web Vitals field data.
  4. Note pages with external links — those are the ones where a broken redirect costs most.
  5. Screenshot analytics, so a genuine before exists.

Mapping

Every old URL maps to exactly one new URL.

  • Keep the URL wherever possible. Always better than redirecting it.
  • Where it must change, a single 301. Never a chain.
  • Never redirect en masse to the homepage — Google treats that as a soft 404 and the equity does not transfer.
  • A page with no equivalent should 404 honestly rather than redirect somewhere irrelevant.

Carry across

  • Content that is performing, unchanged rather than "refreshed" into something different
  • Title tags and descriptions for pages that already rank
  • Structured data
  • Internal links, updated to point at final URLs rather than through redirects

Launch day

  • Redirects live before DNS switches
  • Sitemap updated and submitted
  • Search Console and analytics continuous — not reinstalled
  • robots.txt checked; staging often blocks everything and that setting travels
  • Nothing accidentally left on noindex

After

  • Week 1: watch Search Console for a 404 spike, which means a mapping was missed. Test a sample of redirects manually.
  • Week 2–4: watch the Pages report for indexing of the new URLs.
  • Week 4+: compare Core Web Vitals field data, which needs time to accumulate.
  • Week 6–8: compare Search Console performance against the baseline. Some fluctuation is normal; a sustained decline is not.

Technology

  • Screaming Frog
  • Google Search Console
  • 301 redirects
  • Analytics

Decisions worth explaining

Keep existing URLs unless there is a real reason to change

A tidier URL structure is almost never worth the redirect risk on pages that already rank.

Redirects deployed before the DNS switch

A window where old URLs 404 is a window where Google recrawls and records them as gone.

Tracking kept continuous through launch

Reinstalling analytics on launch day destroys the before-and-after, which is the only evidence either way.

What it produces

A migrated site with URLs preserved or mapped one-to-one, single-hop redirects verified, and a measured baseline to compare against — so the effect of the migration is knowable rather than argued about.

What it teaches

  • The crawl, not the sitemap, is the authoritative list of what exists.
  • Redirect chains waste crawl budget and lose a little equity at each hop.
  • A mass redirect to the homepage transfers nothing.
  • Without a baseline you cannot tell a migration problem from ordinary fluctuation.

Related services

Related guides

Worked examples

All case studies