Website migration SEO: move without losing traffic

A successful website migration SEO process holds on to the rankings and links you already earned while you change the address, the platform, or the structure underneath them. Google's own site move documentation is blunt about it: with permanent redirects and a clean URL map, signals transfer and rankings recover. The danger is in the details you skip. This guide walks through the pre-migration baseline, redirect mapping, staging tests, and the 30, 60, and 90 day monitoring windows that decide whether your move is invisible to users or a months-long traffic hole.

What counts as a website migration for SEO?

A migration is any change that alters the URLs, hosting, or rendering that search engines and the AI engines depend on to find and understand your pages. It is broader than most people assume.

The common types are a domain change (moving to a new brand or top-level domain), an HTTPS switch, a replatform (for example moving to a new CMS or e-commerce system), a URL structure change, a site redesign that changes on-page content and internal links, and a content consolidation that merges or removes pages. Each one touches different ranking signals. A protocol switch mostly affects canonicals and mixed content, while a redesign affects content relevance and internal linking. Naming exactly which type you are running is the first strategic decision, because it tells you which signals are at risk and what to test before launch.

Why do so many migrations lose organic traffic?

Because migrations are executed under deadline pressure and the SEO layer is treated as a launch-day afterthought. The losses are rarely caused by the move itself.

A study by SALT.agency of 1,052 domain migrations found the median time for organic traffic to fully recover was 304 days, with a mean of 489 days, and 13.9% of sites never regained their prior traffic even after three years (SALT.agency). Those numbers describe domain migrations specifically, the highest-risk category, but they show how expensive a botched move can be. The recurring culprits are missing or wrong redirects, pages quietly left on noindex from the staging environment, changed URLs with no mapping, lost title tags and headings, and broken structured data. None of these are mysteries. They are checklist items nobody owned.

Which migration types are riskiest to combine?

The riskiest thing you can do in SEO is change your domain, replatform, and redesign in a single release, because if traffic drops you cannot isolate which variable caused it. Separating changes into phases is the single most valuable planning decision most teams never make, and it is the information-gain element generic checklists skip: they list steps without telling you what not to combine.

If you must combine changes, sequence them so that a single variable moves at a time, then measure for a few weeks before the next phase. That way a ranking dip has one obvious suspect instead of five.

How do you build a pre-migration baseline?

Before anything moves, document exactly what Google currently rewards you for, so you have a fixed reference to measure against after launch. Skip this and you are flying blind when something drops.

Export your top landing pages by organic traffic and their target keywords, record current positions and monthly sessions, and pull the full backlink profile so you know which URLs carry the most external equity. Then crawl the entire live site to capture every indexable URL, its status code, title, meta description, and canonical. This crawl becomes the source list for your redirect map. Cross-check it against Google Search Console and your server logs so you also catch URLs that still receive Google traffic but are not linked internally. A page can be an orphan in your navigation yet still rank and convert, and those are exactly the ones teams forget to redirect.

How should you map and implement redirects?

Create a one-to-one map from every valuable old URL to its closest equivalent new URL, then implement each as a server-side 301 redirect. Redirecting everything to the homepage is a common shortcut that tells Google the original content is gone, so relevance and rankings evaporate.

Google confirms that permanent redirects using 301 or 308 status codes transfer signals and do not cause a loss of PageRank (Google Search Central). Use the right tool for each case, and read our deeper 301 redirects guide for edge cases.

• 301 permanent redirect: the default for any URL that has genuinely moved. Passes equity.
• 302 temporary redirect: only for genuinely temporary situations, not migrations. Signals the old URL will return.
• Canonical tag: for near-duplicate content that must both stay live. See our canonical tags guide.

Avoid redirect chains longer than a few hops, keep the new URLs self-referencing with a canonical tag, and update every internal link to point directly at the new URL rather than routing through a redirect. Clean URL structure on the new site makes this mapping far easier to reason about.

What do you test on the staging site before launch?

Validate the new site in a staging environment that Google cannot index, then run a full technical pass so launch day is a switch, not an experiment. The most damaging single error is shipping a site that carries the staging noindex tag or a Disallow: / in robots into production.

Work through this pre-launch checklist:

• Confirm the staging noindex and robots blocks are removed before go-live, and only then.
• Verify titles, meta descriptions, H1s, and alt text carried over for every template.
• Test that structured data still validates and that technical SEO basics like canonicals and hreflang resolve correctly.
• Spot-check redirects against your map, including a sample of your highest-traffic and highest-backlink URLs.
• Confirm page speed did not regress, since a replatform often reintroduces Core Web Vitals problems.
• Prepare the updated XML sitemap so it is ready to submit the moment the site is live.

Launch during a low-traffic window so any rollback affects the fewest users.

How long should you keep redirects and expect recovery?

Keep every redirect live for at least one year, and expect Google to take weeks, not hours, to fully reprocess the move. Google's guidance is explicit: keep redirects for as long as possible, generally at least one year, because that window is what lets Google transfer all signals to the new URLs (Google Search Central).

Indexing is not instant. Google notes that a small to medium site can take a few weeks for most pages to move in its index, and larger sites take longer. During that window, temporary ranking fluctuation is normal and not a reason to panic or start reverting changes. What matters is that the trend is stabilizing and recovering rather than sliding. For a domain change, also file the Change of Address request in Search Console, which tells Google to prefer the new site as canonical. Skip that tool for a plain HTTP-to-HTTPS switch, where it does not apply.

How do you monitor and recover after launch?

Monitor daily for the first 30 days, then review at 60 and 90 days, watching indexation, crawl errors, rankings, and organic sessions against your baseline. The first month decides the recovery curve, so this is not the phase to disappear.

Submit the new XML sitemap immediately and watch coverage in your sitemap reports. In the first days, check that redirects still resolve with a single 301 and no chains, that no important page returns a 404 or a soft 404, and that Google is discovering and indexing new URLs. Use the index coverage report to catch pages stuck in Discovered or Crawled but not indexed states. Semrush's migration guidance recommends setting calendar checkpoints at 30, 60, and 90 days so long-term issues do not slip past the launch adrenaline (Semrush). If a specific cluster of pages loses rankings, compare their old and new versions for lost content, missing internal links, or a broken redirect before assuming a broader algorithmic cause. For large sites, watch how bots spend crawl budget so the new URLs get discovered fast.

Does a migration affect AI visibility too?

Yes. The same broken redirects and lost content that hurt Google rankings also cut you out of the AI engines that cite web pages, since they crawl and retrieve the same URLs. A migration that scatters 404s across your best content removes the exact passages those systems were quoting.

Protect AI visibility the same way you protect rankings: preserve the URLs and passages that already earn citations, keep your structured data and entity signals consistent across the move, and avoid changing your brand name and core facts in the same release as the technical migration, so cross-source consensus about who you are stays intact. If your move includes a domain or brand change, expect a lag before the AI engines fully re-associate your content with the new domain, and update third-party profiles and citations to point at the new URLs. Disclosure: this guide is written by the team behind Sorank, and preserving citable passages through a move is exactly what we watch for. Treat AI retrieval as one more surface that depends on clean redirects rather than a separate project.

Frequently asked questions

Related guides