Website migration: 10 steps to preserve content and traffic

To migrate a website safely, inventory what you have, decide what moves, map every important old URL to its new destination, test before launch and monitor afterwards. A website migration can be an opportunity to improve performance, simplify your technology stack and create a stronger foundation for future growth.
It can also go wrong quickly.

Broken links, missing content, incorrect redirects, lost metadata or poorly mapped URLs can affect both user experience and search visibility. For organisations managing several websites, markets, languages or teams, the complexity increases further.
A successful website migration is a technical, content, SEO and governance project at the same time.

What is a website migration?

A website migration is a significant change to a website that affects its technology, structure, content, URLs or hosting environment. Common examples include:

• moving to a new CMS;
• changing domain or URL structure;
• redesigning a website;
• consolidating several websites;
• changing hosting infrastructure;
• restructuring a multilingual or multisite environment;
• moving towards a headless or composable architecture.

Some migrations involve only one of these changes. Others combine several.

Where possible, avoid changing everything at once. Google recommends splitting a site move into smaller steps where that makes sense for your site. Separating major changes also makes problems easier to identify and resolve.

Why website migrations are risky

A website contains much more than visible page copy. It also includes:

• URLs and internal links;
• metadata;
• redirects;
• canonical tags;
• hreflang information;
• structured content and content models;
• images and downloadable assets;
• structured data;
• backlinks;
• analytics and tracking;
• forms and conversion paths;
• search visibility built up over time.

If these elements are not mapped correctly, a migration can be technically successful while still causing traffic loss, broken user journeys or weaker conversion performance.

Step 1: Audit your existing website

Before deciding what moves to the new site, create an inventory of the current one. At a minimum, identify:

• all important and indexable URLs;
• organic traffic and search performance;
• current keyword rankings for priority pages;
• high-value landing pages;
• backlinks;
• conversion pages and CTAs;
• crawl and indexation issues on the current site;
• downloadable assets;
• duplicated or outdated content;
• multilingual and regional variants;
• structured content and content types;
• pages that should be kept, updated, merged or removed.

Record a baseline before anything changes. After launch, you will compare traffic, rankings, indexation and conversions against it, so allow for seasonality by comparing equivalent periods.

Classify each item into a clear action:

Keep → Update → Merge → Remove → Create

Keep pages that earn traffic, conversions or backlinks, merge pages that overlap, and remove content that is outdated and has no search or business value.

This gives the new website a cleaner content foundation from day one.

Step 2: Define the new site architecture

Once you understand the existing site, define how the new one should work. This includes the future:

• information architecture;
• URL structure;
• navigation;
• page types;
• content model;
• taxonomy;
• multilingual structure;
• multisite structure;
• roles and permissions;
• editorial workflows.

For international organisations, this step is especially important when managing multilingual and multisite content. You need to decide what should be managed centrally, what can be reused between markets and what needs to remain local.

A good migration should make future publishing easier.

Step 3: Build your URL mapping and redirect plan

If URLs are changing, prepare an old-to-new URL mapping before launch.
Build the list of old URLs from several sources, for example your sitemap, a crawl, Search Console and your backlink data, so that older or parameter URLs are not missed.

For each important URL, define whether it should:

• stay unchanged;
• move to a new equivalent;
• be merged into another page;
• be removed intentionally.

Google recommends preparing this mapping before a site move and then configuring redirects from old URLs to the corresponding new locations. For pages that have moved permanently, Google also recommends permanent server-side redirects whenever possible.
Avoid redirecting unrelated pages to a generic destination such as the homepage simply to avoid a 404.

The goal is to preserve meaning.

A useful migration table can be as simple as:

Old URL → New URL → Content action → Redirect status → Owner

For larger sites, this mapping also becomes a useful QA and post-launch monitoring tool.

Step 4: Plan your content migration

A website migration covers content, structure, data and configuration. Depending on your CMS and architecture, you may also need to migrate:

• structured content;
• content types;
• languages;
• media;
• taxonomy;
• metadata;
• configuration;
• integrations.

Before migrating, define:

• which content must move;
• which structured data must move;
• which content models need to be recreated or transformed;
• how languages and site structures will map to the new environment;
• which legacy content should be retired;
• which integrations and dependencies need to be tested.

For complex environments, treat migration as a controlled transformation.

Check the exact source and target versions

Migration procedures can differ significantly between product versions. Always validate technical requirements against the documentation for the exact source and target environments. Avoid applying instructions written for an older CMS version to a newer environment without checking that they still apply.

Step 5: Back up before making changes

Before running migration or database operations, make sure you have a tested backup and a clear recovery plan.

This is particularly important for:

• databases;
• repository content;
• uploaded files and media;
• configuration;
• custom code.

A backup is only useful if you know how to restore it, so define rollback ownership and procedures before launch.

Step 6: Migrate content, metadata and on-page SEO

For every migrated page, check:

• page title;
• meta description;
• heading structure;
• images;
• alt text;
• downloadable assets;
• internal links;
• forms;
• CTAs;
• structured data;
• canonical tags;
• hreflang;
• navigation;
• related-content relationships.

This is also a good moment to check whether the content still reflects your current:

• positioning;
• terminology;
• product offering;
• audience needs;
• brand messaging.

A migration is an opportunity to retire outdated content and legacy messaging.

Step 7: Test before launch

The target environment should be thoroughly tested before going live. Use a staging environment that mirrors production, and crawl it as a search engine would.

Your migration QA should include:

• broken links;
• missing content;
• incorrect redirects;
• missing assets;
• page rendering;
• mobile behaviour;
• page speed;
• navigation;
• forms;
• conversion paths;
• metadata;
• canonicals;
• hreflang;
• robots directives;
• crawlability and indexability;
• XML sitemap;
• analytics and tracking.

High-traffic, strategically important and conversion-critical pages should receive additional review.
Google also notes that moving a smaller section first can be useful for testing a migration before moving the entire site.

Step 8: Protect your SEO on launch day 

If URLs change, some temporary ranking fluctuation can occur while search engines recrawl and process the new URLs.

At launch, check that:

• redirects are live;
• internal links point to the new URLs;
• canonical tags reference the correct URLs;
• hreflang references have been updated;
• the XML sitemap contains the target URLs;
• accidental noindex directives have been removed;
• robots.txt is correct;
• analytics and Search Console are collecting data.

Step 9: Monitor after launch

A migration continues after launch day. Monitor the new site in stages, and compare priority pages with your pre-migration baseline.

First days after launch

• crawl errors and 404 errors;
• redirect issues;
• indexed URLs;
• analytics and conversion tracking.

Following weeks

• organic traffic;
• keyword visibility;
• conversion performance;
• page engagement.

Longer term

• whether traffic, rankings and conversions have stabilised against the baseline;
• pages that need further optimisation or content updates.

Your URL and content mapping now becomes a diagnostic tool: if performance drops, you can quickly identify what happened to the original page and whether the target implementation is correct.

Step 10: Improve content governance after the migration

One of the biggest opportunities in a CMS migration is improving how content will be managed afterwards. Use the migration to clarify:

• content ownership;
• editorial workflows;
• approval rules;
• reusable content;
• localisation;
• taxonomy;
• governance;
• lifecycle management;
• quality control.

This matters particularly in multilingual and multisite organisations, where weak operating rules can quickly recreate the same fragmentation inside a new platform.

Migration decisions still require human judgement, particularly for strategic pages, content removal, product claims and business-critical journeys.

The objective is a content foundation that is easier to govern, reuse and scale.

Website migration checklist

Before launch, make sure you can answer yes to the following questions:

If several of these questions cannot yet be answered, the migration probably needs another review before launch.

A website migration is an opportunity to build a better foundation

Website migrations are often triggered by technology: a new CMS, a new architecture or a new hosting environment. They also give organisations the opportunity to simplify their content estate, improve findability, remove legacy content and establish better ways of working.

For teams managing content across multiple sites, markets and languages, the CMS should support that complexity without making day-to-day content operations harder.

Request a demo