SEO migration

What is an SEO migration?

An SEO migration is any change to a website that may alter how search engines crawl, index and rank its pages. Moving to a new domain name is the best-known example, but switching to HTTPS, adopting a new URL structure, changing CMS, merging websites or overhauling page templates also count as migrations.

The risk common to all these situations is a break in the signals the site has built up over time: URLs that disappear, external links pointing to errors, content that changes role or technical tags that contradict the new structure. A well-prepared migration does not guarantee that rankings will not fluctuate, but it greatly reduces the risk of lasting losses and makes it possible to diagnose any discrepancy quickly. The earlier SEO is involved in the project, the easier it is to protect: decisions about URLs, templates and content are far cheaper to adjust on paper than after launch.

• A change of domain or subdomain.
• A move from HTTP to HTTPS, or consolidation of www and non-www versions.
• A new site structure or URL format.
• A change of CMS or e-commerce platform.
• Adding or restructuring language versions.

Building a URL inventory before the change

An inventory of existing URLs is the foundation of any migration: anything that is not listed will not be redirected. Bring together the sitemap, a full crawl of the site, page views from your analytics, queries and pages from Google Search Console, known backlinks and any older URL lists still available.

No single tool provides a complete history. A crawl only finds linked pages; Search Console only shows pages that have earned impressions; backlink tools only see part of the web. Merge these sources, remove duplicates and flag active pages, redirects already in place, older deletions and URLs that external sources are still discovering. Server logs, when available, are a useful addition to this list.

• Every HTML URL, including useful paginated and filtered pages.
• Downloadable files (PDFs, documents) that receive links.
• Important images if they generate traffic.
• Existing redirects, to avoid creating chains.
• Metrics for each URL: visits, impressions, links and conversions.

If the site has never been analysed in depth, an SEO audit before the migration lets you fix existing problems instead of carrying them over to the new site.

Creating an accurate URL mapping

Every old URL needs an explicit decision: keep it, redirect it to genuinely equivalent content, or deliberately remove it. This mapping table is the central document of the migration; it should be reviewed by someone who knows the content, not just generated by a script.

Closeness of topic and intent matters. An old service page should point to the new page for the same service, not to a general category. Mass redirects to the home page create a poor experience and may be treated by Google as “soft 404” errors. When a page no longer has an equivalent, a 404 or 410 status is more honest than a misleading redirect. On a large site, group URLs by pattern, for example all blog articles or all product pages, and write one rule per group, but still check a sample of each rule by hand and handle high-value pages individually.

• One row per old URL, with destination, response code and rationale.
• Direct redirects to the final destination, with no intermediate hops.
• URL parameters and capital letters handled consistently.
• The table approved before the redirect rules are developed.

Which redirect should you use for a website migration?

For a permanent change, use a server-side permanent redirect, meaning a 301 or 308 status code. Google Search Central explains that these redirects signal that the new address should replace the old one in search results. The 302 and 307 codes are temporary and suit short-lived situations, such as maintenance or a test.

JavaScript redirects and meta refresh tags are less reliable and should only be used as a last resort, when server configuration is impossible. Google recommends keeping redirects in place for as long as possible, generally at least a year; in practice, keeping them indefinitely is often the safest approach, because external links and bookmarks continue to use the old addresses.

• 301 or 308: permanent move.
• 302 or 307: temporary move.
• 404 or 410: content removed with no equivalent.
• No chains of several successive redirects.

Preparing the new site’s technical signals

Every technical signal on the new site should point directly to the final destinations. Canonical tags, hreflang annotations, internal links, XML sitemaps, structured data and robots rules must be consistent with one another and with the mapping table.

Avoid redirect chains and internal links that still go through an old address: every detour slows down crawling and muddies the signals. Also make sure that the noindex tags or password protection used on staging are not deployed to production, a frequent mistake with immediate consequences.

• Absolute canonical tags pointing to the new URLs.
• Reciprocal hreflang annotations between language versions.
• Internal links, menus and footers updated.
• A new sitemap limited to canonical, indexable URLs.
• Titles and content carried over or improved, not stripped back.
• Analytics tools and goals reconfigured on the new site.

SEO migration checklist for launch day

On launch day, the goal is to publish the new site, activate the redirects and immediately check the critical points. Schedule the switchover at a quiet time, with the key people available, and avoid the day before a weekend or a holiday.

• Deploy the approved version and activate all redirect rules.
• Remove staging restrictions: noindex, restrictive robots.txt, password protection.
• Test a sample of priority old URLs and their destinations.
• Check forms, payments and integrations under real conditions.
• Submit the new sitemap in Google Search Console.
• For a change of domain, use the Change of Address tool in Search Console.
• Update your Google Business Profile and main external profiles.
• Note the exact time of the switchover to make later analysis easier.

Validating before and after the switchover

Validation happens in two stages: a full check on staging, then a series of checks on the live site. Before the switchover, test priority pages, forms, resources, error codes and several screen sizes in an environment as close as possible to production.

After the switchover, recrawl the list of old URLs to confirm that each one returns the correct redirect, then the list of new URLs to confirm that they respond with a 200 status and no further redirect. Check server logs and Search Console for crawl errors, excluded pages and spikes in 404s. Check Core Web Vitals too: a new design can worsen LCP, INP or CLS without it being noticeable on a fast computer.

• Launch day: crawl of old and new URLs, functional tests.
• First week: crawl errors and indexing of key pages.
• Following weeks: impressions, clicks and conversions by page.

Prepare these checks before the switchover rather than in a rush afterwards. Save the URL lists to recrawl, the priority pages to monitor and the Search Console reports to review, together with the baseline values recorded before the change. Annotate the migration date in your analytics tools. That way, any variation can be compared with a documented starting point, and an error spotted on the first day can be corrected before it has a lasting effect on crawling or on the enquiries the site receives.

How long does it take for rankings to stabilise after a migration?

Stabilisation generally takes several weeks, sometimes longer for a large site, because search engines need to recrawl both old and new URLs before transferring signals. Google Search Central notes that the time required depends in particular on the size of the site and how often it is crawled; there is no guaranteed timeframe.

Ranking fluctuations are common during this period. Monitoring should distinguish normal fluctuation from a reproducible technical problem: a broad, gradual dip that recovers does not mean the same thing as a sudden drop concentrated on one group of pages. In the second case, compare the affected URLs with the mapping table straight away.

• Compare performance page by page, not just the site total.
• Monitor the pages that generate enquiries first.
• Document every fix with its date.

During this period, avoid piling on other changes, such as a large-scale content rewrite or a new navigation structure: each additional change makes it harder to identify the cause of any variation.

Common mistakes that cause an SEO migration to fail

A migration rarely fails because of a single technical problem; it fails because several small oversights add up at the moment of the switchover. Most of them are known in advance and can be avoided with a checklist and a clear division of responsibilities.

• An inventory limited to the current sitemap, missing older pages that are still linked.
• Temporary (302) redirects left in place instead of permanent ones.
• Redirect chains that have built up over successive redesigns.
• A staging robots.txt file that blocks crawling of the new site.
• Canonical or hreflang tags still pointing to the old domain.
• Content heavily cut or merged without regard for the searches it covered.
• The old domain cancelled or the old server shut down while redirects still depend on it.
• No monitoring after launch, allowing errors to take hold.

Appoint one person responsible for each area: content, technical work, measurement and communication. The developer does not always know the commercial value of a page, and the person who knows the content does not necessarily see the server responses. A sign-off meeting bringing these roles together before the switchover lets everyone review the mapping table and the checklist side by side.

Remember to renew the old domain name as well: as long as it receives links and visits, it must keep redirecting to the new site.

Keeping records and a rollback plan

Archive the URL mapping, the checks carried out and the deployed version: these records make it possible to diagnose a problem several months after the switchover. Also keep a copy of the old site, its data and its server configuration. Make sure that backup can actually be restored rather than assuming it can: a rollback that has never been tested tends to fail precisely when it is needed.

An atomic deployment, meaning one published in a single operation that can be reversed, reduces downtime if something goes wrong. Define in advance the conditions that trigger a rollback and who makes that decision. If the migration is part of a website redesign, this plan is an integral part of the project, just like the design and the content.

• Final URL mapping table, versioned and dated.
• Crawl results from before and after the switchover.
• A full backup of the old site and its redirects.
• A tested rollback procedure.

Frequently asked questions

Does a migration always cause a drop in traffic? Not necessarily. Temporary fluctuations are common, but a well-prepared migration limits the risk of lasting losses. No one can guarantee that rankings will stay exactly the same.

Should we migrate and redesign at the same time? It is possible, but it multiplies the variables and makes diagnosis harder. Our fix or redesign guide helps you decide whether a step-by-step approach is preferable.

What should we do with pages that have no equivalent on the new site? Redirect them to genuinely similar content if it exists; otherwise, let them return a 404 or 410 error rather than redirecting them to the home page.

How can we check that a migration went well? By comparing crawls from before and after, Search Console reports and the performance of key pages. Our guide to understanding an SEO audit details the technical checks to carry out, and you can contact us for support.