The migration plan protects what would obviously break.The traffic leaves through everything else.

Website migration and replatforming SEO: protecting the organic and paid traffic you already earn, before, during and after the switch.

We are not the ones building your new site. Your developer or platform partner does that. We make sure what the old site earned arrives on the new one, and we tell you which numbers afterwards are real.

Why traffic disappears at a replatform

What a migration plan protects

Products, categories, customers, orders, design, checkout. The things that would obviously break if they were missed, owned by people who will notice immediately.

All of it necessary. None of it is where the traffic goes.

Where the traffic actually leaves

Pages nobody owns. Manuals, spec sheets, leaflets, old landing pages, PDFs that quietly earn clicks on paths the new platform will never reproduce.

Nobody misses them on launch day. They show up eight weeks later as a number falling.

This is the pattern, and it is remarkably consistent. A redirect map built from the sitemap is not the same as one built from what earns clicks and links, and the difference only shows up once it is expensive to unpick.

110,000+redirects on our largest migration, a two-catalog consolidation
77,000+products carried across it
1replatform we are running right now, taxonomy changing completely
2018the year we first published our method for protecting traffic through a rebuild

How we work a migration

Three weeks before launch

Benchmark traffic, rankings and analytics while the old site is still standing. Map old URLs to new ones. Inventory every paid search and shopping feed destination. Plan the redirects, the sitemaps and the feeds.

You get a plan, a set of benchmarks, and a written list of what is at risk.

Go-live

Redirects implemented without chains. Robots and sitemaps updated. New feeds published. Paid search and shopping destinations switched at the same moment as the site. Search engines told deliberately rather than left to work it out.

The switch happens once, in the right order.

Three weeks after launch

Watch traffic, rankings, crawl errors and conversions daily. Fix the 404s that only appear under real traffic. Chase the backlinks and citations still pointing at dead URLs. Adjust feeds and campaigns as the index catches up.

And tell you which movements are real.

Three weeks either side of launch is the shape of it. Longer if the catalog is large or the taxonomy is changing completely. The point of the first three weeks is that almost everything expensive to fix afterwards is cheap to prevent before.

We first published this method in 2018, in three phases, and it has not needed restructuring since. What has changed is the scale, the platforms and the number of places a migration can now leak from. Paid destinations and shopping feeds were an afterthought then. They are not now.

What we have learned running one

Four things we are dealing with on a replatform right now

None of these appear on any migration checklist we have read, including the good ones.

  1. The redirect map cannot be derived. It has to be constructed. When the replatform changes the information architecture and the product taxonomy at the same time, there is no old page that corresponds to a new page. Exporting the old sitemap gives you a list, not a map. Every checklist assumes a like-for-like swap, and a large replatform almost never is one.
  2. Keeping the same domain is the trap, not the relief. Same domain means the same analytics property before and after, so the charts run continuously and the comparison looks valid. If the tracking is re-implemented even slightly differently at cutover, the step change is a measurement artefact and it is indistinguishable from real traffic loss, arriving in the exact fortnight when everyone is watching.
  3. The homepage distorts everything. On the project we are running it carries just under half of all organic clicks, and its URL does not change, so it survives untouched. Read the aggregate and half your reassurance comes from the part that was never at risk. The pages actually in danger are buried underneath it.
  4. Two instruments will give you two answers. We report organic on clicks and users, never on sessions, because sessions overstate organic reach substantially and the gap widens exactly when referral patterns change. Which they do, at a migration.

This is the part of the job that is not a checklist. Anyone can list redirects. Telling you whether the number you are staring at three days after launch is a real loss or an instrument change is the thing worth paying for.

About the statistics everyone quotes

What the numbers on other migration pages are worth

Almost every page you will read on this subject opens with a statistic. We went looking for where those numbers come from. Most of them trace back to another agency page, which traces back to another one, and the trail ends without ever reaching a study.

There is one piece of real published research, and it is worth knowing. Across 892 domain migrations analysed by Dan Taylor and published on Search Engine Journal, 17% had still not recovered their previous organic traffic after 1,000 days.

And here is the part that matters for you: that study measured DOMAIN changes, not replatforms. Moving to a new platform on the same domain is a different risk profile, and anyone quoting that figure at you about a replatform either has not read it or is hoping you will not.

We would rather tell you that than quote you a frightening number we cannot stand behind.

What we cover

URL mapping and redirects

Old to new, constructed from what actually earns clicks and links rather than from the sitemap. Implemented as single hops, because chains lose what the redirect was meant to save.

Technical continuity

Sitemaps, robots, canonicals, indexation and analytics continuity, verified after cutover rather than assumed. Most of the damage we have seen is a setting nobody checked on the day.

Paid search and shopping feeds

Every ad destination and every product feed URL updated in step with the site. Miss this and campaigns run to dead pages while the feed gets disapproved, on the day traffic matters most.

Backlinks and citations

The links pointing at your old URLs are an asset you paid for. Redirects carry most of it. Outreach recovers the rest, and only the ones worth the effort get chased.

Local listings

Google Business Profile and Bing Places still pointing at the old structure, plus the directories that copied them. Cheap to update, expensive to forget.

Monitoring and interpretation

Daily through the window that matters, with a stated view on whether each movement is real. This is the part clients tell us they actually wanted.

The last two are the ones that get dropped. The paid search side in particular sits outside the development project entirely. Local listings and monitoring sit outside the development project, so they belong to nobody by default. The paid and feed work sits outside it too, which is why campaigns are so often the first thing to break.

Who this is for, and who it is not

It fits businesses moving to a new ecommerce platform, sites being rebuilt with a new structure, groups consolidating several sites into one, and anyone changing domain. It fits best when there is real organic and paid traffic to lose.

We will say no when:

  • You want us to build the new site. We are not a development shop, and the honest version of this service depends on us not being one.
  • The site has little traffic to protect. Then this is insurance against a small loss, and you should spend the money on the new site instead.
  • You have already launched and want a guarantee. We can help, and recovery depends on decisions that have already been made.
  • Nobody will own the redirects on your side. Somebody has to implement them. If that person does not exist, the plan will sit unread.

Where this sits beside the rest

A migration touches most of what we do. Crawling, rendering and indexation are technical SEO, the catalog that has to survive the move is ecommerce SEO, and the measurement question underneath all of it is analytics and reporting.

Platform-specific work continues afterwards on BigCommerce, WooCommerce and Commercebuild, and the broader picture is on the SEO consultant page.

Questions we get asked

Q. How do I migrate a website without losing SEO?

By deciding what must survive before anyone builds anything, and by benchmarking it while the old site is still up. In practice that means a constructed URL map rather than a sitemap export, single-hop redirects, sitemaps and feeds switched at the same moment as the site, and daily monitoring through the weeks after launch. The losses we get called in to fix are almost never caused by a bad redirect. They are caused by pages nobody knew were earning anything.

Q. What is SEO migration?

It is the work of carrying search visibility across a change to your site: a new platform, a new structure, a new domain, or a rebuild of the same site. It sits alongside the technical migration rather than inside it. The development project moves the functionality. This moves the traffic, and the two are usually owned by different people, which is exactly why it gets missed.

Q. How much does it cost to migrate a website?

Our part of it is priced on the number of URLs involved, averaged across the old site and the new one, because that is what determines the work. It is a fixed figure agreed before we start, not a retainer and not a percentage of anything. It covers the planning, the cutover and the monitoring afterwards, and it does not include building the new site, which is your developer’s work and a much larger number. Tell us roughly how many URLs each side has and we will give you the figure on the call.

Q. When should we bring you in?

Before the redirect map is written, which usually means about three weeks before launch. That is the point where advice is cheapest and changes almost nothing about your timeline. After launch we can still help, and it costs more and recovers less, because some of the evidence of what you used to rank for has already aged out of the reports.

Q. We are keeping the same domain. Are we safe?

Safer, and not safe. Keeping the domain preserves the domain-level signals and avoids a property change, which is genuinely good. What it also does is make your before and after look continuous when the measurement underneath may not be. That produces a chart that appears trustworthy and is not, and it is the single most common reason we get called into a migration that has already happened.

Q. Do you do the migration itself?

No. We are not a development shop and we will not pretend otherwise. Your developer or your platform partner builds and moves the site. We protect what it earns, work alongside them, and give them a specific list rather than a generic checklist. If you do not have anyone building it, that is the first thing to solve and we will say so.

Q. What happens to our paid campaigns?

They break quietly unless someone updates them. Every ad destination and every shopping feed URL has to switch at the same time as the site, or campaigns spend against dead pages and feeds start getting disapproved. It is one of the most avoidable losses in a migration and one of the most commonly forgotten, because it sits with a different team.

Q. How long before traffic recovers?

It depends on how much changed and how well the mapping was done, and anyone who gives you a number without seeing your site is guessing. What we will commit to is telling you, week by week, whether what you are seeing is recovery, noise, or a real problem still open. Most of the anxiety in the weeks after a launch comes from not being able to tell those apart.

Q. What would tell us this went badly?

A sustained fall in impressions for the queries you ranked for before, once the index has caught up, on pages that still exist. Not a dip in the first fortnight, which is normal, and not a fall in sessions, which may be your tracking. We agree on which numbers we are judging it by before launch, so nobody is choosing the flattering one afterwards.

Q. Do you work on rebrands and domain changes too?

Yes, and they are harder. A domain change gives up the accumulated signals attached to the old hostname and relies entirely on redirects and outreach to rebuild them, while a platform change on the same domain keeps them. The work overlaps heavily. The risk profile does not.

Start with a conversation

Thirty minutes on what is moving, when, and what it currently earns. Have the call before the redirect map is written. That is the point where this costs least and changes most.