Website Migration SEO: How to Move a Site Without Losing Rankings

Most UK businesses meet website migration SEO the hard way, about a fortnight after a smart new site goes live and organic traffic has halved. The work that prevents that happens before launch, not after.

What website migration SEO actually protects

Website migration SEO is the discipline of carrying accumulated search equity across a site change without dropping it on the floor. That equity does not live in your design or your copy. It lives in the relationship Google has built up between specific URLs, the links pointing at them, and the rankings those pages have earned over years. Change the addresses without telling Google where everything moved to, and you have effectively launched a brand new site carrying none of that history.

The term covers far more than a platform swap. Any change that alters how search engines reach, interpret or evaluate your pages counts as a migration: a redesign that rewrites your URL structure, a rebrand onto a new domain, a move from HTTP to HTTPS, a WooCommerce to Shopify replatform, or two sites merging into one. Some of these are invisible to customers and brutal for search. A redesign that keeps every URL byte for byte identical is genuinely low risk. A redesign that also tidies up the URL structure is one of the riskiest projects a small business will ever run, and it is usually waved through by someone who did not realise those were two separate decisions that could have been made months apart.

The practical consequence is that migration risk is not proportional to how different the site looks. It is proportional to how many URLs change, how much authority those URLs held, and how accurately the old set is mapped onto the new one.

Six types of website migration, and what each one puts at risk

Platform replatform

Moving between systems such as WooCommerce to Shopify, or Wix to WordPress. The danger is that each platform imposes its own URL conventions, so hundreds of addresses change at once without anyone explicitly choosing to change them.

Redesign on the same URLs

New templates and new copy, identical addresses. The lowest risk migration of the six, though internal linking, heading structure and page speed can still shift rankings if the new build strips them out.

Domain change or rebrand

Everything moves to a new domain name. Authority does transfer through redirects, but the new domain starts with no history of its own, so expect a longer settling period than a same-domain move.

URL structure change

Same platform, same domain, reorganised paths. Deceptively dangerous because it feels like housekeeping, yet it invalidates every existing link, bookmark and ranking signal pointing at the old paths.

HTTP to HTTPS

Technically a migration, because every URL changes protocol. Usually straightforward, provided the redirects are server level and internal links, canonicals and sitemaps are all updated to the secure versions.

Site consolidation

Merging multiple sites or subdomains into one. The highest complexity of the six, since several URL sets compete for the same destinations and duplicate content decisions have to be made deliberately.

Most real projects are two or three of these at once, which is where the risk compounds. A rebrand that also moves platform and reorganises the URLs is three migrations wearing one project name, and it should be planned and released as three.

A 24-point website migration SEO checklist

Migrations fail on sequencing far more often than on knowledge. The items below are ordered the way they need to happen, because several of them are impossible to do properly once the old site is switched off. Work through this SEO migration checklist in order and the large majority of avoidable damage never occurs.

Phase one: four to six weeks before launch

1. Crawl the existing site and keep the file. Export every indexable URL along with its title, meta description, canonical and status code. Once the old site is gone, this export is the only complete record of what existed.
2. Pull your top pages from Search Console and analytics. Take at least twelve months of data so seasonal pages are captured. Rank the list by clicks, impressions and referring domains, not by what the team assumes is important.
3. Export your backlink profile. Any external link pointing at a URL you are about to retire is authority you will lose unless that specific URL redirects correctly.
4. Benchmark performance before anything changes. Record sessions, conversions, indexed page count and Core Web Vitals now. Without a baseline you cannot tell a migration problem from a seasonal dip, and that argument will come up in week three.
5. Record the structured data and metadata you already have. Note which templates carry review, product, FAQ or breadcrumb markup, because this is the layer most likely to disappear silently in a rebuild.
6. Build the redirect map. One row per old URL, one destination per row. This is the single most important artefact of the whole project.
7. Decide what is being deleted on purpose. Migrations are a reasonable moment to retire thin pages, but that has to be a recorded decision rather than an accident discovered later.

Phase two: the week of launch

8. Test every redirect on staging. Run the old URL list through the staging rules and confirm each returns a single 301 to a live, relevant page.
9. Check for redirect chains. Old URL to interim URL to final URL wastes crawl budget and dilutes the signal. Point each old address straight at its final destination.
10. Confirm the staging site is not indexable, and that production will be. The staging robots.txt reaching production is the most common single point of failure in the entire process.
11. Verify titles, meta descriptions and canonicals carried across. Rebuilt templates frequently drop metadata that was set on the old system.
12. Preserve internal links. Navigation, related content and in-body links should point at new URLs directly rather than relying on redirects.
13. Check the new XML sitemap contains only new URLs. A sitemap that still lists old addresses, or that was generated against staging, teaches Google exactly the wrong map of your site.

Phase three: launch day itself

14. Confirm production is returning HTTP 200 and is crawlable, and that the robots.txt is the intended one.
15. Spot check twenty of your highest value URLs from the redirect map, by hand.
16. Submit the new XML sitemap in Search Console, and keep the old sitemap available for a period so Google can rediscover retired URLs and follow their redirects.
17. Confirm analytics and conversion tracking are firing on the new templates. Tracking silently breaking at launch is common, and it destroys your ability to measure the migration.
18. Check that HTTPS, canonicals and hreflang (if used) all reference the new addresses. On Shopify, make sure only one system writes hreflang: the platform adds its own tags automatically, and an admin setting now switches them off if an app or your theme already handles it.

Phase four: the first thirty days

19. Watch the Search Console coverage and crawl stats reports daily for the first fortnight, then weekly.
20. Fix 404s as they surface. Real user and crawler behaviour will find gaps your redirect map missed.
21. Re-crawl the complete old URL list at day seven and again at day thirty. Redirect rules get quietly edited during post-launch bug fixing, and this is how you catch it.
22. Compare clicks and impressions against the same period before launch, page by page rather than in aggregate.
23. Check whether you are still being cited in AI answers and assistants. Migrations can drop you out of generative results even when classic rankings look stable, and our guide to AEO and SEO explains why that surface behaves differently.
24. Leave the redirects in place permanently. There is no safe point at which to remove them.

If any of that reads as unfamiliar territory, our SEO services cover migration planning and post launch monitoring as a fixed scope piece of work.

The failures that cause most migration traffic losses

Traffic drops after a migration are rarely caused by exotic technical problems. They are caused by a short list of avoidable ones, and most are cheap to prevent and expensive to fix retrospectively. If you are migrating a website and want to avoid SEO issues, this is the list to hand your developer.

• The staging robots.txt going live. A single Disallow: / line shipped to production can deindex an entire site within days.
• Redirecting everything to the homepage. A bulk rule that sends all old URLs to the root is treated as a soft 404. It passes almost no value and wastes the entire redirect map.
• Forgetting non HTML assets. Images, PDFs and downloads accumulate links too, and they are routinely left out of redirect planning.
• Canonical tags left pointing at the old domain. This tells Google the old version is the authoritative one, which undoes the migration.
• Redirect chains and loops. Particularly common when a site has been migrated before and old rules were never consolidated.
• Losing structured data. Review, FAQ and product markup often lives in templates or plugins that do not survive a rebuild.
• Migrating during your peak trading period. A December migration for a retailer converts a manageable dip into a lost quarter.

Several of these overlap with the wider issues covered in our guide to common SEO mistakes, and the underlying mechanics are worth understanding if you want to brief a developer properly. Our explainer on how SEO works covers the fundamentals in plain English.

SEO for a website redesign and migration: telling the two apart

Redesign and migration get used interchangeably in project meetings, and that single piece of loose language causes a large share of the damage in this article. They are different projects with different risk profiles, and it is worth being pedantic about which one you are actually buying.

If the project is a brand new build rather than a move, our new website SEO checklist covers the launch-day sequence specifically. A redesign changes what the page looks like and what it says. A migration changes where the page lives or how a search engine reaches it. You can do either without the other. A redesign on identical URLs is a content and template exercise: check that titles, structured data and internal links survived, and you are largely done. Google's guidance on site moves without URL changes covers the narrower case where infrastructure changes but addresses do not.

The trouble starts when a redesign quietly becomes a migration because the new theme generates different URL patterns, or because someone decided the new navigation needed a tidier structure. Nobody records that as a decision, so nobody plans for it. Ask one question early in every website project: are any URLs changing? If the answer is yes, or nobody is certain, you are running a migration and it needs the checklist above.

The corollary is the most useful scheduling decision available to you. A redesign and a URL restructure do not have to ship on the same day. Split them into two releases several weeks apart and, if traffic moves, you know exactly which change caused it.

How long recovery should actually take

Honest expectation setting matters here, because the most damaging decisions get made in week three by people who were promised there would be no impact at all.

A well executed same domain migration typically produces a modest dip lasting two to four weeks while Google recrawls and reassigns signals. A domain change usually takes longer, commonly six to twelve weeks before performance stabilises, and larger sites take longer still because recrawling everything simply takes time. Google's own documentation on site moves with URL changes confirms that the process is gradual and that redirects should be maintained for the long term rather than retired once traffic looks healthy.

What is not normal is a sustained decline past roughly eight weeks on a same domain move, or traffic that never recovers at all. That pattern almost always points at a specific technical fault rather than a settling period, and the earlier it is diagnosed the cheaper it is to correct. The single most useful diagnostic is a page level comparison: if a handful of previously strong URLs have gone to zero while everything else is broadly stable, you have a redirect problem, not a Google problem.

How to brief a developer so the migration does not go wrong

Most SMB migrations are delivered by a web developer or an agency who is being paid to build a site, not to protect rankings. Those are different objectives, and unless the search requirements are written into the brief they will not be delivered, because nobody was asked for them. Five lines in a scope document prevent the majority of the damage.

• State that the redirect map is a deliverable. Name it explicitly, with a due date before launch rather than after, and ask to see it as a spreadsheet you can check.
• Ask who is responsible for the production robots.txt. Put one name against it. This single question prevents the most common catastrophic failure in the whole process.
• Require that existing page titles and meta descriptions are migrated, not regenerated. Otherwise a rebuild will happily overwrite years of tuned metadata with template defaults.
• Ask for a staging URL you can crawl yourself. If you cannot crawl it, you cannot verify anything, and you are relying entirely on assurances.
• Agree a rollback plan and who can trigger it. Migrations occasionally need reversing within hours, and that decision is much harder to make if nobody agreed in advance that it was allowed.

None of this requires you to be technical. It requires you to treat search continuity as a named deliverable with an owner, in the same way you would treat payment processing or contact forms working on launch day. If the destination platform is WordPress, our WordPress development team handles the build and the redirect layer as one piece of work rather than two.

What a website migration SEO service should include

Migration support is usually bought once, under time pressure, by someone who has never bought it before. That is a difficult position to judge a proposal from, so it helps to know what a complete scope looks like before you compare quotes.

1. A pre-migration audit and benchmark. A full crawl, a ranked inventory of what currently earns traffic and links, and a recorded performance baseline. Without this, nobody can prove afterwards whether the migration worked.
2. The redirect map, owned by the SEO side. Mapping should be done by whoever understands which URLs carry value, then handed to the developer to implement. When the developer owns the mapping, low-traffic pages with strong backlinks tend to get dropped.
3. Staging verification before launch. Crawling the staging build, testing the redirect rules, and checking metadata and structured data survived. This is the step that gets cut when a project runs late, and it is the one that matters most.
4. Launch day cover. Someone actually watching on the day, with an agreed list of checks and the authority to raise a rollback.
5. Thirty days of monitoring. Daily Search Console checks in the first fortnight and a page-level comparison against the baseline, not a single report a month later when the damage has set.

Two questions separate a genuine migration scope from a line item on a build quote. Ask who owns the redirect map, and ask what happens on the day if rankings drop. Vague answers to either mean the work has been priced but not planned. For a wider view of how UK SEO engagements are structured and what they should be accountable for, our buyer's guide to professional SEO services covers the questions worth asking any provider.

What migration support costs in the UK

Migration work is usually scoped as a fixed project rather than a monthly retainer, because it has a defined start and end. For a small brochure site of thirty to fifty pages, planning and verification is typically a few days of work. For an e-commerce catalogue running into thousands of URLs, redirect mapping alone can take longer than the build.

The economics are worth stating plainly. The cost of migration planning is almost always lower than the cost of one quarter of lost organic revenue, which is the realistic downside of getting it wrong on a site that depends on search. Our UK SEO pricing guide sets out typical day rates and retainer bands if you want to sanity check a quote. If the migration is also a platform decision, our comparison of Wix and WordPress for UK businesses covers the trade offs before you commit.

One last point for businesses that depend on local visibility. A migration moves your website, but your Google Business Profile, citations and map pack presence all reference your old URLs too, and those need updating in the same sprint. Our local SEO playbook covers which listings matter and in what order.

Frequently asked questions about website migration SEO