Website migration: how do you move a site without losing its rankings?

Migrating a website means moving it to another technical environment while carrying over its content, data and features. The change can involve the CMS, the hosting or the domain name, and each scenario puts visitors, editorial teams and search rankings at risk in different ways. Before you start, you need to know what stays the same, what changes and how you will check the result. This article goes through the scope, the checks and who does what, so you can limit losses and then measure them.

The technical scope and the validation criteria shape the preparation far more than the name of the destination tool.

What does a website migration cover?

Changing platform, web hosting or domain does not touch the same parts of the site. The scope has to name what moves and what stays in service: when several changes land at once, an issue becomes hard to trace back to its cause.

The term IT migration also covers wider projects, such as moving internal applications to the cloud. For a website, ask for a map of the pages, data and services actually involved, rather than a general description of the infrastructure.

Why move a site, and when should you pair it with a redesign?

A CMS that has become a chore to publish with, features to carry over or hosting to replace are all reasons to look into a transfer. Changing platform is not always the answer: a WordPress site that still does its job can often change hosting or theme without leaving its CMS, provided you assess its website maintenance cost over time.

Migration concerns the foundation, a redesign the interfaces and journeys. You can keep the design through a technical change, or rework the journeys without changing platform. If you do both, the validations stay separate: data carry-over on one side, interface behaviour on the other.

In that case, have designers work with developers from the first content decisions, without waiting for the mock-ups to be approved. A template designed without knowing the target content model forces you to rework the data migration.

Our article on the decisions involved in a website redesign goes back over this distinction. Moving from WordPress to Webflow is a case of its own, with its own carry-over choices.

Prepare the transfer before touching the site

The switch depends on an approved inventory, recoverable data and named acceptance-test owners. So the work starts on the existing site: the team has to know what it is keeping before building the destination.

Map the site and define the scope

The initial audit ties each piece of content to its URL, its template and the features it depends on. The editorial lead confirms which pages to carry over, the technical lead the dependencies and access constraints. Together they deliver an approved inventory that says, for each item, whether it is kept, transformed or removed.

• Pages, URLs and priority content.
• Templates and reused components.
• Forms, booking and other features.
• Internal links and downloadable documents.
• Connected services and required access.

Secure content and data

Recovering text, media, metadata and useful data is only half the job: you then have to check that it was carried over properly. On WordPress, the files and the database are two separate things, and having the images does not prove the content and its relationships can be recovered. The technical lead documents the exports and the editorial team validates the transferred content.

A backup is only usable if its scope is known, the access is available and the restore has been tested in a suitable environment. The guide from ANSSI, the French national cybersecurity agency, on the fundamentals of information system backups gives reference points for this preparation without replacing the choices specific to the site. Sensitive exports also need restricted access and protection while they are transferred.

Assign sign-offs and prepare staging

Brand, content, product, development: each team gets its list of items to check and the authority to sign them off. Brand reviews the interfaces, content checks the carry-over, product tests the journeys and development verifies the technical behaviour. Reservations and their owner go into a shared document.

Tests before publishing happen on a staging environment. Specify who has access, how changes are tracked there and how you avoid exposing sensitive data. That is where the built interfaces get validated, beyond their mock-ups: a form or an editorial component gets tested as it actually works.

Transfer the site without losing the thread

You check the copy on the target environment before touching the public address. Development carries over the files, content and data, then logs the gaps in a report; the editorial team validates what will be published.

Once acceptance testing has passed, the publishing lead confirms the content freeze and the last backup. The technical lead prepares the DNS settings, checks the DNS TTL in place and plans a cache purge if a CDN serves the site. The result is a switch-over procedure, with each check and its owner.

The rollback plan sets out when to go back, with which access, and the handling of data created after launch. Restoring the old site is not always the right answer: bookings or enquiries received on the new environment may need to be kept. What happens to them is decided before any return to the old site is authorised.

Protect search rankings during the change

To keep your rankings, three things have to come through the change intact: the content people search for, the URL destinations and the indexing signals. Even a well-prepared migration does not guarantee those rankings. Hence the need for checks that produce comparable findings, before launch as well as after it.

Build the mapping and handle redirects

URL mapping gives every old URL a destination or a decision. Start with the pages tracked in Search Console and the content you want to keep. A URL that does not change still gets checked, for its content as well as its accessibility.

A permanent move calls for an HTTP 301 redirect to the matching page, tested all the way to its destination. A page with no equivalent needs a clear decision: a relevant replacement page or a deliberate removal. Avoid redirect chains and blanket redirects to the home page, which do not necessarily meet the need behind the old page.

Check indexability and technical signals

Indexing settings have to point to the public versions you want Google to see. The SEO lead validates the expected destinations and development checks they are in place on the live site, so that no staging restriction stays active by mistake.

• Canonical tag consistent with the chosen URL.
• robots.txt file suited to the public pages.
• Indexing directives checked on the templates.
• hreflang tags checked for international versions.

Compare crawls before and after launch

One crawl run before the migration and another after it set the crawled URLs, HTTP statuses, internal links and accessible pages side by side. Keep the same scope and note the changes you decided on: a page removed on purpose should not pass for an unexplained disappearance.

Google’s guide to site moves with URL changes recommends relying on Search Console during the migration to track indexing of both the old and the new URLs. The two tools complement each other: the crawl shows what the site exposes at the time of the test, Search Console what Google does with it.

Track symptoms and find their cause

A drop in visibility gets diagnosed page by page and symptom by symptom, before you blame the migration. Compare the content involved, the URL changes and the technical errors; if you have access to the server logs, analysing them completes the picture. When the destination is Webflow, mad.studio’s Webflow SEO agency takes over this monitoring after the switch.

• Page not found: check the URL and its destination.
• Indexing drop: review the directives and the pages involved.
• Wrong redirect: test the path to the final destination.
• Inconsistent crawling: compare server logs with Google Search Console.

Test the new site before and after the switch

Acceptance testing checks that visitors can complete their journeys, with criteria close to those of a UX design audit, and that the team finds the content it expects. Staging validates the carry-over; on the live site, you then check the URLs and services actually published.

On an e-commerce site, add the applicable accessibility checks. The DGCCRF, the French consumer protection authority, states that since 28 June 2025 the French requirements stemming from the European Accessibility Act cover certain products and services, including e-commerce services. A technical change does not exempt you from checking the journeys concerned.

The switch-over checklist: D-7, launch day, D+7

Splitting the work this way avoids launch-day panic: each check has its date, and nothing depends on the team’s memory.

Run the launch and the follow-up

The launch procedure assigns three roles to named people: giving the go-ahead to publish, running the switch and signing off the journeys. Whether the destination is a CMS or a custom-built website, it comes with written checks and no promise of SEO results.

Organise the switch

You launch once acceptance testing is approved and technical access is confirmed. The editorial team applies the planned freeze; the technical lead runs the procedure, checks the DNS settings and verifies the configured TTL, without assuming a propagation delay that holds everywhere.

With a CDN, purge the cache at the moment of publishing so you can check the version actually served to visitors. The people in charge of priority journeys stay available to test the public pages, the forms and their destinations. If a blocking issue appears, you apply the decision set out in the rollback plan, after reviewing the data already received.

Monitor and fix after launch

After launch, the editorial, functional and SEO checks carry on, on the site visitors actually use. Anything that prevents an enquiry, a booking or access to priority content comes before presentation gaps that do not block the journey.

Each incident has a URL, a reproducible description, an owner and a test after the fix. Google Search Console tracks the pages and rankings concerned, but not whether a form works: form and content checks carry on even when no search alert shows up.

To choose between doing it in-house and getting support, check that your team covers technical access, editorial carry-over, redirects and availability on launch day, and talk to the person who will carry out the operations. The quote should separate the transfer, interface changes, acceptance testing and monitoring, because the amount of work varies with the features to carry over and the content transformation.

Between a technical transfer and interface changes, it all depends on the current site’s limits and the features to keep.