Website Migration Checklist: Redesign Without Losing SEO, Leads or Tracking

A website redesign can look successful on launch day and still damage the business.

The homepage is cleaner. The new CMS works. Everyone approves the mobile layout. Then a week later somebody notices that an old service page now returns 404, a contact form is not delivering, analytics stopped recording conversions, or pages that used to bring qualified search traffic have disappeared.

That is why I treat a serious redesign or platform move as a migration of a working business system, not just a transfer of pages.

The practical question is:

What already works on the current website, and how do we prove it survived the move?

First decide whether you are actually migrating

Not every redesign is a migration.

If the domain, URLs, platform, content and integrations remain substantially unchanged, you may simply be improving the interface and customer journey.

Migration risk rises when you change one or more of these:

• domain or subdomain;
• URL structure;
• CMS or framework;
• hosting infrastructure;
• navigation and information architecture;
• important page content;
• forms, booking or payment integrations;
• analytics and consent tooling;
• how the site is rendered or deployed.

Google separates moves with URL changes from hosting moves where visible URLs stay the same. Its current site-move guidance also recommends changing one major thing at a time where practical rather than combining a domain change, CMS migration and complete redesign into one uncontrolled event. Google Search Central: site moves with URL changes

If you are still deciding whether the existing foundation should survive, start with my website redesign vs rebuild guide.

1. Inventory the current website before touching it

Before development starts, capture what exists.

At minimum, record:

• every important public URL;
• pages receiving organic impressions, clicks or valuable backlinks;
• pages used by paid campaigns or sales teams;
• forms and where each submission goes;
• booking, payment and CRM integrations;
• analytics events and conversion definitions;
• structured data that matters;
• downloadable files and important images;
• DNS, domain, hosting and deployment ownership;
• current sitemap, robots rules and canonical behaviour.

This is not bureaucracy. It creates the baseline that tells you what must survive.

A page with modest traffic may still be commercially important because every sales proposal links to it. A form with ten submissions a month may be more valuable than a blog post with thousands of informational visits.

Do not let a migration plan preserve only what is easy to measure.

2. Decide what stays, changes, merges or disappears

Every important old URL needs an explicit decision.

Use four buckets:

Keep: the page remains useful and can retain its URL.

Change: the purpose survives but the URL or structure changes.

Merge: several overlapping pages become one stronger destination.

Retire: the content genuinely has no useful replacement.

Keeping useful URLs stable reduces unnecessary migration work. When a URL must change, map the old page to the closest relevant new destination.

Google recommends preparing an old-to-new URL map and using server-side permanent redirects such as 301 or 308 where possible. It specifically warns against sending many unrelated old URLs to one irrelevant page such as the homepage. Google Search Central: redirects

3. Protect the search layer before launch

The new website should be checked before DNS or routing changes make it live.

Verify that:

• important content actually migrated;
• page titles and useful metadata are present;
• new pages use the intended canonical URLs;
• internal links point to final destinations rather than old URLs;
• the production robots.txt will allow intended crawling;
• temporary noindex rules used on staging will be removed at launch;
• the XML sitemap contains the correct production URLs;
• structured data still represents the visible content accurately;
• redirects can be deployed and tested immediately.

A common migration failure is not a mysterious ranking algorithm. It is a staging control that accidentally reached production, a missing redirect, a broken canonical, or content that simply did not make the move.

Google’s migration troubleshooting guidance explicitly calls out forgotten noindex or robots blocks, incorrect redirects, crawl errors and outdated sitemaps. Google Search Central: site migration troubleshooting

4. Test the business journey, not just the pages

A developer can confirm that /contact returns HTTP 200 while the business still loses every enquiry.

Test real journeys end to end:

service page → call to action → form → success state → stored submission → notification → analytics event → human follow-up

For ecommerce or paid products, test the full payment state rather than stopping at the checkout screen.

For bookings, verify availability, confirmation and failure states.

For lead generation, submit the form from a real phone and confirm that the person responsible for enquiries actually receives it.

If the interface says a message was sent but nobody receives it, use my contact-form delivery troubleshooting guide before declaring the migration complete.

5. Preserve measurement before you need it

Take a baseline before launch.

Record useful Search Console and analytics numbers such as:

• organic clicks and impressions by important page;
• top commercial landing pages;
• form or booking completions;
• paid-campaign landing pages;
• conversion events;
• important country and device patterns;
• current crawl or indexing issues.

Then verify the same measurement after launch.

Without a baseline, a team can see traffic fall and have no idea whether the migration caused it, which pages changed, or whether tracking itself broke.

Google recommends using Search Console and analytics to monitor site moves and notes that temporary ranking fluctuations can happen while moved URLs are recrawled and reindexed. Google Search Central: debugging search traffic drops

6. Launch with a rollback mindset

Before switching traffic, know what happens if a critical function fails.

You should know:

• who controls DNS;
• who can deploy or roll back;
• where the previous site or release is preserved;
• who owns redirect changes;
• who can fix forms, payments or booking integrations;
• who is watching errors immediately after launch.

A migration is safer when recovery is designed before the incident.

This is also why account ownership matters. A technically correct website can still become operationally fragile if the business cannot access its domain, hosting, repository, CMS or analytics. My website handover checklist covers that ownership layer.

7. Verify immediately after launch

Do not wait for a monthly SEO report.

On launch day, check:

1. important old URLs redirect to the intended new destinations;
2. important new URLs return the correct status;
3. canonicals point to the production URLs;
4. robots and noindex rules are correct;
5. the sitemap is live and submitted where appropriate;
6. forms, booking and payment journeys work in production;
7. analytics and conversion events fire;
8. mobile navigation and calls to action work;
9. Search Console verification remains available;
10. obvious 404, server and integration errors are being monitored.

For domain or URL migrations, Google recommends keeping permanent redirects for as long as possible, generally at least one year. It also recommends monitoring both old and new URLs as the move is processed. Google Search Central: moving a site

A migration should preserve value, not preserve clutter

The goal is not to copy every weakness from the old website into the new one.

A redesign is an opportunity to remove duplicated pages, simplify navigation, improve conversion paths and replace technical constraints.

But improvement should be deliberate.

Preserve what has evidence of value. Change what has a clear reason to change. Map what moves. Test what makes money. Measure what matters.

That is the standard I use when thinking about websites as systems rather than screenshots.

If you are planning a redesign, CMS move or platform migration and want the search, conversion and ownership layers considered before launch, see my web design service or contact me.