The checks that make or break your next website migration

Website migrations have a well-earned reputation for going wrong, with even well-planned migrations leading to rankings slipping, traffic dropping, or tracking breaking. But most migration problems come from small oversights rather than complex technical failures.

You can reduce your risk with a staged approach. The checks you complete during staging, on launch day, and in the first few weeks after go-live often determine whether a migration stabilizes quickly or becomes a long recovery project.

Before launch: Catch issues on staging 

Most migration problems should be found and fixed on the staging site. If issues reach the live site, recovery is slower and more uncertain. Set yourself up for success with the following tips:

Keep the staging site private (even from crawlers) 

One common mistake is leaving the staging site publicly indexable. When Google crawls a staging environment, duplicate content can sometimes end up in search results. Rankings can fluctuate, and unfinished pages may end up indexed.

Make sure you have blocked crawlers from staging site or protected it with a password so it remains invisible to search engines until the live launch. 

It’s not just crawlers, either. I’ve seen this happen with ecommerce sites.

Customers found the staging site, tried to place orders, and the process didn’t work. This confused customer service teams, frustrated buyers, and created avoidable pressure internally. 

Take benchmarks 

You want a baseline to help you identify real problems rather than reacting to normal short-term movement.

Record organic sessions, rankings, top landing pages, indexed pages, conversions, and site speed before transitioning to the new site to define the “normal” you will compare the new site to. 

Identify priority pages 

Focus on pages that drive traffic, revenue, or attract links. These pages need extra care during redirect mapping, content review, and testing.

Pay extra attention to internal links, redirects, and URL rules for these pages.

Dig deeper: Website migrations: a plan to keep your traffic and SEO safe

Review templates and content continuity 

Templates control titles, headings, metadata, canonical tags, structured data, copy, and media. If templates break, problems repeat across hundreds of pages. 

Check that:

• Titles and headings are present and accurate. 
• Canonical tags use full URLs and point to live pages. 
• Structured data has transferred correctly. 
• Copy, images, and internal links are intact.

This step protects more than rankings. It ensures the site still meets user needs and supports conversions.

Make sure canonical tags use full URLs and point to live pages, as explained in Google’s guide on canonical URLs. This simple step can prevent bigger headaches later. 

Be intentional about URL changes

Unnecessary URL changes are a common source of hidden damage. Changes made for design or CMS convenience often introduce risk without a clear benefit. 

Typical issues include: 

• Adding or removing trailing slashes without a clear rule. 
• Changing folder structures without reason.
• Inconsistent use of uppercase and lowercase URLs.

One of the most common causes of duplicate URLs during migrations is inconsistent handling of trailing slashes. URLs with and without a trailing slash are treated as different URLs. Allowing both to resolve can create duplicate content, dilute signals, and complicate crawling. 

It doesn’t usually matter which version you choose, as long as the rule is consistent across the site. During a migration, avoid unintentionally switching between formats without a clear plan and proper redirects in place. 

The same goes for folder structures and capitalization. Don’t change what you don’t need to, and be consistent wherever possible.

In one migration where we were brought in to rescue a site after go-live, every URL gained a trailing slash. Canonical tags only contained paths rather than full URLs, and internal links relied on redirects instead of pointing directly to final URLs. None of the changes were necessary, yet together they slowed crawling, caused confusion, and delayed recovery. 

Map redirects and compile existing ones 

Redirect mapping is one of the highest-risk areas of any migration. Existing redirects should be pulled from the CMS, CDN, Google Search Console, analytics platforms, and backlink tools so nothing is missed. Every legacy URL needs a clear, intentional destination. 

If pages are removed, redirect to the closest relevant alternative. If no equivalent exists, return a 404 or 410. Avoid sending everything to the homepage or top-level categories. 

Aleyda Solis’ guide to SEO for web migrations provides a strong framework for this stage.

Decide what to remove and what to create

Migrations are often seen as a good time to refresh all the content on a site. This can be done if all the stakeholders align, but it should be done methodically.

Remove outdated content carefully. Where gaps exist in the new structure, plan new pages in advance and make sure they are ready to go live when the new site is. This planning avoids lost coverage or weak redirect decisions later. 

Verify Search Console access and settings 

Ensure the site can be verified after launch and that any international or country settings are correct. 

Align stakeholders early 

Pre-launch is also about people. Developers, designers, SEO, and analytics teams need clarity on responsibilities and deadlines. Many migration issues happen through missed handovers rather than a lack of skill. 

In my experience, most migration failures are preventable before launch, when fixes are safer and faster. 

I worked on one migration where SEO was brought after launch. The site launched with broken internal links, missing redirects for high-traffic pages, and inconsistent URL rules. Organic traffic dropped by almost 40% within two weeks, and several priority pages disappeared from search results. All of these issues were visible on the staging site but weren’t reviewed before launch. 

Make the case for SEO to be part of the planning process. It saves time, money, and headaches.

Dig deeper: Website migration checklist: 11 steps for success

---

Launch day: Verify everything works on the live site

Launch day is where preparation meets reality, and all teams, including SEO, developers, designers, and analytics, see the results of their planning. What worked on staging must now work on the live site. Even small oversights can immediately affect rankings, traffic, conversions, user experience, and reporting. 

Calm, thorough verification ensures the migration pays off and prevents small errors from becoming lasting issues. Use this list as a starting point:

Test redirects at scale

Spot-checking isn’t enough. Every mapped URL should redirect once and resolve cleanly. Avoid redirect chains and loops. They slow down crawling and delay signal consolidation. 

In another migration we were called in to fix, only the top 50 pages had correct redirects. Thousands of other URLs redirected to the homepage. Rankings dipped, and recovery took months longer than expected. 

Crawl the live site 

Run a full crawl as soon as the site is live. Compare results with the staging crawl to identify differences. 

Look for:

• Broken links.
• Redirected internal links.
• Missing pages. 
• Server errors.

Check internal links and navigation 

Menus, breadcrumbs, and in-content links should point directly to live URLs. Leaving internal links to rely on redirects increases load and risk. 

Verify on-page SEO and content 

Canonicals or hreflang pointing to staging URLs are a common launch issue. Confirm titles, headings, canonical tags, hreflang, copy, and media all reference the live site. 

Dig deeper: How to run a successful site migration from start to finish

Confirm tracking continuity 

GA4, paid media tags, and social pixels should already be in place before launch. This ensures tracking fires correctly, conversions are measured accurately, and historical data remains intact when the live site goes public. Remember, the staging site should be blocked from crawling or be protected behind a password to prevent test traffic from polluting reporting. 

In one migration, we were asked to review after launch. The domain stayed the same, but a new GA4 property was created during the redesign. Historical data remained in the original property, while new data was collected in the new one, making post-launch comparisons difficult. 

Keeping the same GA4 property preserves reporting continuity, supports confident decision-making, and avoids unnecessary uncertainty at a critical point in the migration. 

Check robots.txt and index controls 

Ensure pages meant to be indexed are accessible and that noindex tags are only used where intended. If you use services like Cloudflare, it’s also important to check that your robots.txt and content signals are configured correctly. 

For example, Cloudflare’s default setting may block AI training access while allowing search indexing. If this isn’t adjusted intentionally, AI models might pull content from third-party sources rather than your site, affecting how your brand is represented in generative AI outputs. 

Submit the XML sitemap 

Submit the live sitemap to Google Search Console to support the discovery of new URLs. 

Review site speed 

Check Core Web Vitals and page performance. A redesigned site can still load heavier assets than expected. Launch day is about verification, not assumption. 

After launch: Monitor and stabilize performance

Even the best-planned migrations can reveal surprises once search engines and real users interact with the site. Small errors that didn’t appear on staging can impact rankings, traffic, and conversions.

Calm, structured monitoring in the days and weeks after launch ensures problems are caught quickly before they affect performance or user experience. Here’s what to keep an eye on.

• Monitor Search Console closely: Watch for crawl errors, indexing issues, and unexpected exclusions. Patterns matter more than isolated URLs. 
• Check indexed pages: Expect some movement, but sustained drops can point to redirect or crawl problems. 
• Track rankings and traffic against benchmarks: Compare performance against your baseline rather than reacting to day-to-day changes. 
• Confirm redirects still receive traffic: Old URLs can attract users and bots for months. Ensure they continue to resolve correctly. 
• Recheck site speed under real traffic: Performance can shift once the site is under load. 
• Audit for follow-up improvements: Once stability returns, review internal linking gaps, missing metadata, and content that did not migrate cleanly. Calm monitoring and clear data prevent small issues from becoming lasting damage.

Dig deeper: Technical SEO post-migration: How to find and fix hidden errors

What normal recovery looks like after a migration

Even well-managed migrations can see short-term movement. Rankings may fluctuate, and traffic may dip before stabilizing. 

If redirects are clean, content is intact, and crawl access is clear, recovery usually follows within weeks rather than months. Ongoing losses usually point to structural issues rather than algorithm changes. 

Knowing when to wait and when to act comes from experience. You don’t want to react too quickly or too late. Keep a careful eye on your analytics, and you’ll develop the expertise over time.

Website migrations succeed when they are planned, tested, and monitored at every stage. A clear focus on pre-launch, launch day, and post-launch checks protects visibility, performance, and confidence across teams. 

When SEO is involved early, and checks are clearly owned, migrations stop feeling like crisis events and become managed change.