Website Migration SEO: A Step-by-Step Safety Plan

Good website migration SEO comes down to three things. Benchmark everything before you move, redirect every URL that has value, and watch the new site closely for at least 90 days after launch. Get those right and most redesigns, domain changes and replatforming projects keep their rankings. Skip them and you can lose a year of organic growth in a weekend. The plan below is the one I use with clients, organized by phase.

What Is the Safest Way to Handle Website Migration SEO?

The safest approach is to treat the migration as three phases: pre-launch, launch and post-launch. Before launch, you record a full baseline, map every old URL to its new equivalent and test the staging site. At launch, you deploy redirects and verify them immediately. After launch, you monitor crawl data, indexing and rankings daily, then weekly.

That sounds obvious. In practice, most failed migrations skip one phase entirely. Usually it is the first one.

A typical failure looks like this. Design and development run for six months. SEO gets invited two weeks before go-live. By then the URL structure is locked, the CMS generates its own slugs, and nobody exported the old site's crawl data. The team launches, traffic drops 40%, and there is no clean record of what the old URLs even were.

So the first rule is political, not technical: get SEO into the project at the scoping stage. You need a seat when URL patterns, navigation and content consolidation are decided. Those three choices determine most of the risk.

Also agree on one owner for the redirect map. Shared ownership means no ownership.

Finally, set a launch window. Avoid Fridays, holiday weekends and your peak sales season. A Tuesday morning gives you four working days to fix problems while the people who built the site are still at their desks.

Pre-Launch Step 1: Build a Complete Baseline

You cannot protect what you have not measured. The baseline is your evidence file, and it becomes the source list for redirects.

Collect URLs from several sources, because no single source is complete:

• A full crawl of the live site using Screaming Frog, Sitebulb or a similar crawler. Export status codes, titles, meta descriptions, canonicals, H1s and word counts.
• Google Search Console performance data for the last 16 months, exported at page level. The UI caps exports at 1,000 rows, so use the API or a Looker Studio connector for larger sites.
• Analytics landing pages with sessions and conversions for the past year.
• Backlink data from Ahrefs, Semrush or Majestic, filtered to URLs with referring domains.
• XML sitemaps and server log files, if you can get them.

Merge these into one spreadsheet and deduplicate. You will find URLs the crawler never reached: old campaign pages, orphaned PDFs, product pages with no internal links but dozens of backlinks. Those are exactly the pages that get forgotten.

Next, record rankings for your priority keywords and note current Core Web Vitals. Take screenshots of key templates too. Six weeks later, when someone asks whether the product pages used to have FAQ schema, you will have the answer.

If your current reporting stack makes this painful, it may be worth reviewing how to choose an SEO analytics platform that scales before the project starts rather than after.

Pre-Launch Step 2: Map Every Redirect

The redirect map is the single most valuable document in the whole project. Every old URL with traffic, links or conversions needs a 301 (or 308) redirect to its closest new equivalent.

Build the map in a spreadsheet with at least these columns: old URL, new URL, redirect type, traffic, referring domains and notes. Sort by value so the most important pages get checked by a human, not just matched by a script.

Some practical rules I follow:

• Redirect one-to-one wherever possible. A category page should go to the new category page, not the homepage.
• Never mass-redirect to the homepage. Google typically treats irrelevant redirects as soft 404s, so the equity is lost anyway.
• Let genuinely dead pages return 404 or 410. Thin tag archives with no links and no traffic do not need a home.
• Avoid chains. If an old URL already redirects somewhere, point the original straight to the final destination.
• Handle parameters and case variations. Uppercase URLs, trailing slashes and tracking parameters often slip through.

For large ecommerce sites, use pattern-based rules for the bulk and manual mapping for the top few hundred pages. Regex rules are efficient, but they fail quietly. A rule that strips a product ID can send 3,000 products to one page.

Content consolidation needs extra care. If you merge four thin articles into one strong guide, redirect all four to it and make sure the new page actually covers each topic. Otherwise the rankings for those secondary queries simply vanish.

How long should redirects stay live? Google's own documentation recommends keeping them for at least one year. I go further. Keep them indefinitely unless there is a real performance cost, because backlinks to old URLs never stop sending signals.

Pre-Launch Step 3: Test the Staging Site Properly

Staging is where you catch problems cheaply. Once the site is live, every bug costs crawl budget and rankings.

First, block search engines from staging with password protection or IP restriction. A robots.txt disallow alone is weak, and staging sites get indexed more often than people admit.

Then crawl staging and compare it against your baseline. Check that:

• Titles, meta descriptions and H1s carried over for priority pages.
• Canonical tags point to production URLs, not the staging domain.
• Structured data still validates in Google's Rich Results Test.
• Hreflang tags reference the correct new URLs on international sites.
• Internal links point directly to new URLs, not to redirecting old ones.
• Content renders without JavaScript errors, particularly on replatformed sites built on frameworks like React or Next.js.

Run your redirect map against staging too. Most crawlers have a list mode: paste the old URLs, swap the domain for staging, and confirm each returns a single 301 to a 200 page.

This is also the moment for a template-level content check. A structured on-page SEO checklist helps you audit each template type quickly instead of page by page.

Here is the gotcha that catches experienced teams. Developers add a noindex meta tag or an X-Robots-Tag header to staging, and it ships to production. Write "remove staging noindex" on the launch checklist in bold. Then check the HTTP headers, not just the page source, because header-level noindex is invisible when you view the HTML.

Launch Day: The Hours That Matter Most

Launch day is about verification, not heroics. Everything should already be prepared.

A few days before, ask whoever manages DNS to lower the TTL on relevant records to something short, such as 300 seconds. If you need to roll back, changes then propagate in minutes rather than hours.

Once the new site is live, work through this sequence:

• Remove staging protection and confirm robots.txt allows crawling of important sections.
• Check for noindex in both meta tags and headers on key templates.
• Crawl the redirect map against production. Fix any 404s, chains or loops immediately.
• Submit new XML sitemaps in Google Search Console and Bing Webmaster Tools.
• Verify analytics and tag manager are firing, including conversion events.
• Test forms and checkout end to end. Revenue bugs matter more than ranking bugs.

Here is a time-saver few people use. Keep the old XML sitemap submitted for a few weeks alongside the new one. It nudges Google to recrawl the old URLs, discover the redirects and update its index faster. Remove it once most old URLs show as redirected in the Pages report.

Have someone watch server logs during the first few hours. A spike in 5xx errors or Googlebot hitting endless parameter URLs is easier to spot there than anywhere else.

Redesigns, Domain Changes and Replatforming: Different Risks

Not every migration carries the same risk. Knowing which type you are running tells you where to focus.

Redesigns on the same domain and URLs are the lowest risk, but they are not risk-free. The danger is content and internal linking changes. A slimmer navigation can quietly remove links to hundreds of category pages. Designers love collapsing copy into tabs and accordions, which is generally fine, but cutting text entirely is not.

Domain changes carry more risk because every signal must transfer. Use the Change of Address tool in Google Search Console after redirects are live, and keep both properties verified. Reach out to the sites behind your strongest backlinks and ask them to update the URL. Redirects pass signals, but direct links are cleaner.

Replatforming, for example moving from Magento to Shopify or from a custom build to WordPress, is often the riskiest. Platforms impose their own URL structures. Shopify, for instance, forces /products/ and /collections/ paths, so almost every URL changes.

My strong recommendation: do not combine all three in one launch if you can avoid it. Changing domain, platform and design at once makes diagnosis nearly impossible. When traffic drops, you will not know which change caused it. If the business insists on one big bang, at least keep URLs and content as stable as possible so only one major variable moves.

The audit tooling you use matters here as well. If you are reviewing options, this breakdown of how to choose the right SEO platform covers crawlers and monitoring tools worth considering.

How Long Does It Take Rankings to Recover After a Migration?

For a well-executed migration on the same domain, rankings usually stabilize within a few weeks, sometimes days. Domain changes and replatforming commonly take one to three months for signals to consolidate. If traffic is still significantly down after three months, something is broken, and you should investigate rather than wait.

Some fluctuation is normal. Google has to recrawl, process redirects and reassess the new pages. A short dip followed by recovery is expected. A steady decline is not.

Monitor on a schedule:

• Daily for the first two weeks: crawl errors, 404s in Search Console, server errors, indexed page counts and conversions.
• Weekly for the next ten weeks: rankings for priority keywords, organic sessions by page type, and the Pages report in Search Console.
• Monthly after that: backlink health, Core Web Vitals and overall visibility trends.

Compare page-level performance against your baseline, not just sitewide totals. Sitewide numbers can hide a disaster. A 5% overall dip might actually be a 60% loss on your highest-margin category offset by gains elsewhere.

Watch the "Page with redirect" and "Not found (404)" counts in Search Console. Old URLs should gradually move into the redirect bucket. Unexpected 404s with backlinks deserve a redirect the same day.

Annotate everything. Mark the launch date, fixes and any Google core updates in your analytics. A core update landing two weeks after launch can look exactly like a migration problem, and annotations stop the wrong team from being blamed.

If recovery stalls, our piece on proven ways to improve search rankings offers next steps once the technical foundation is confirmed sound.

Common Migration Mistakes I Still See

Most migration disasters come from a short list of repeat offenders. None of them are exotic.

• Launching without a redirect map. Still the number one cause of traffic loss.
• Using 302s instead of 301s. Google has said it handles both, but permanent moves should use permanent redirects. Some platforms default to 302, so check.
• Leaving internal links pointing at old URLs. Redirects work, yet every internal hop wastes crawl effort. Update links in templates and in body content.
• Deleting content during the redesign. "Nobody reads that" often means "it ranks for 400 long-tail queries."
• Removing redirects after six months to tidy the server config.

One subtle mistake deserves its own mention: changing content and URLs simultaneously on top pages. If a high-earning page gets a new URL, keep its copy, title and headings close to the original for the first few weeks. Let Google confirm the move. Then optimize.

Honestly, the teams that avoid these mistakes are not smarter. They simply use a written checklist and stick to it, even when launch pressure builds.

Your Migration Is a Project, Not an Event

Website migration SEO succeeds when it is planned months ahead and monitored months after. Record your baseline. Build a redirect map that a human has reviewed. Test staging like it is production. Verify on launch day, then watch the data on a fixed schedule. Do that, and a redesign or replatform becomes a chance to improve performance, not a threat to it.

Frequently Asked Questions

Should I use 301 or 302 redirects for a website migration?

Use 301 or 308 redirects for any permanent move, which covers almost every migration. They clearly tell search engines the old URL has been replaced. Google says it can process 302s too, but temporary redirects send mixed signals and some tools treat them differently. Check your platform's default, because several CMS plugins and hosting panels create 302s unless you change the setting.

Do I need to use the Change of Address tool for every migration?

No. The Change of Address tool in Google Search Console only applies when you move from one domain to another, such as oldbrand.com to newbrand.com. It does not apply to redesigns, HTTP to HTTPS moves or URL changes on the same domain. Set up your 301 redirects first, verify both properties in Search Console, then submit the change.

How many URLs should be in my redirect map?

Every URL that has organic traffic, backlinks, conversions or appears in your sitemap should be mapped. For a small site that might be a few hundred rows. Large ecommerce sites often have hundreds of thousands, handled with pattern rules plus manual mapping for the most valuable pages. Low-value pages with no links or traffic can safely return a 404 or 410.

Can a website migration improve SEO rankings?

Yes, if it fixes real problems. Moving to a faster platform, cleaning up duplicate URLs, consolidating thin content and improving internal linking can all lift rankings after the initial settling period. The improvement only happens when redirects and content are preserved first. A migration that loses signals in the move will spend months recovering before any gains appear.