Website Migration SEO, Without The Ranking Drop

You are probably reading this because a move is coming. A new design has been signed off, or the platform is being changed, or the domain is finally becoming the one you actually trade under. The site works now. It brings in enquiries now. Nobody involved in the rebuild is being paid to protect that, and you have noticed.

This page covers what causes rankings to drop during a move, what has to be recorded before anything changes, how every old address gets matched to a new one, what the first few weeks after launch normally look like, and how to tell an ordinary dip from a genuine loss. It also covers the migrations we turn down.

Migration SEO in six points

• Rankings are lost at the mapping stage, not the design stage. Every old address needs a decision, and the decision has to be written down before the build starts.
• A migration with no baseline cannot be judged afterwards. If nobody recorded what ranked before, nobody can prove what changed.
• A short dip is normal. Search engines have to recrawl and reprocess the site, and that takes weeks rather than days.
• The riskiest migrations change two things at once, such as a new platform and a new address structure in the same release.
• A migration is the cheapest chance you will ever get to fix structural problems, because everything is being touched anyway.
• We are answerable for the rankings through the move, not for the launch date.

How does True SEO run a website migration?

Two ways, and the choice is yours rather than ours. We either take the search side of the migration end to end, or we sit alongside the developers and designers you already have and make sure nothing they build costs you a position. Most of our migration work is the second one.

The distinction matters because a lot of businesses assume that bringing in an SEO consultancy means replacing the people building the site. It does not. The build team knows the platform, the design and the deadline. What they are rarely paid to know is which forty of your three hundred pages are carrying the enquiries, and that is the gap the rankings fall through.

Either way the sequence is the same, and it is the sequence rather than the effort that decides the outcome. The work splits into three stages, and the stage most often skipped is the first one.

The launch window is the one thing we ask for that people find unusual. Migrating on a Friday afternoon means any fault runs unattended for three days, and the cost of that is real.

Who should be worried about a migration, and who should not?

Worry in proportion to how much of your revenue arrives through search.

A business taking most of its enquiries through referral and repeat custom can move its site with modest risk. A business where organic search is the main route to new customers is moving the thing that feeds it, and should treat the migration as a commercial project rather than a design one.

The second factor is how much is changing at once. Changing the look of a site while every address stays identical is close to risk free. Changing the platform, the address structure and the content in a single release means that when something goes wrong, you cannot tell which of the three caused it. That is the situation we are called into most often, usually a fortnight after launch.

Three questions sort most of it. How many of your enquiries began with a search? How many of your addresses are changing? Has anybody written down what currently ranks? A business that can answer all three has a manageable project. A business that cannot answer the third has no way of knowing whether the move worked.

Visual

One change is diagnosable, three at once are not

What actually causes rankings to fall during a migration?

Rankings fall because search engines lose the thread between the page that earned the position and the page that replaced it.

Everything else is a variation on that. The commonest cause is an address that quietly stops existing. A page ranked, the rebuild did not include it, and nothing points to where it went. Search engines find an error page where an authority used to be, and the position it held goes to somebody else. This happens most often to old blog posts and to service pages that the new sitemap simply forgot.

The second cause is redirect chains. An address points to a second address, which points to a third. Each hop is technically valid and the reader arrives fine, so nobody notices. Google Search Central guidance on site moves is direct about this: redirect to the final destination rather than through a chain, because long chains can be dropped before the end is reached.

The third is a change of address structure with no thought for what the old structure earned. A tidier set of addresses is often a genuine improvement, but tidiness is not worth a position, and the two goals have to be balanced deliberately rather than one being assumed.

The fourth is the staging site being indexed, or the live site being blocked. Both come from the same file, and both are usually a copy and paste error carried over on release night. It is the single easiest fault to prevent and one of the most damaging to leave running for a week.

The fifth is losing what made the pages rank in the first place. A rebuild that trims copy, drops headings and removes internal links can hold every address perfectly and still fall, because the pages arriving at those addresses no longer answer the question they used to answer. That is where the technical and on page layer beneath a rebuild stops being optional.

How is every old address matched to a new one?

Every old address gets an explicit decision and none is left to a default rule.

That decision is one of four: it moves to a direct equivalent, it merges into a broader page, it is deliberately retired, or it stays exactly where it is. The mapping is built as a document before the build begins, not generated afterwards from whatever the new site happens to contain. Working the other way round is how pages get missed, because you can only map what you remember to look for.

Visual

The four decisions, one per old address

Direct equivalents are simple and cover most of a typical site. Merges need judgement, because pointing five thin pages at one strong page is usually right, and pointing five strong pages at one is throwing away four positions. Retirements are legitimate and underused. A page that ranked for nothing, earned nothing and answered nothing is not worth carrying into a new site out of caution.

Which migrations carry the most risk?

Domain changes carry the most, because everything moves at once and the new address has no history of its own.

A domain change is survivable and often correct, particularly for a rebrand, but it needs the mapping to be complete rather than mostly complete, and it needs the old domain kept and pointing for far longer than most businesses expect.

Platform changes come next. Moving between systems usually forces the address structure to change, because each platform has its own conventions for how a product, a category or an article is addressed. That is the moment a business is most likely to accept a structure it did not choose, simply because the new system produces it by default.

Consolidations are the quiet one. Merging two sites into one, after an acquisition or a rationalisation, means two sets of history competing for the same positions. Done carefully it compounds authority. Done carelessly it halves it.

The lowest risk migration is a redesign that keeps every address. If your project can be scoped that way and still achieve what you want, it usually should be, and we will say so on the call rather than sell you a larger piece of work.

Two rows on that table change what a project should be. A migration sitting only in the bottom row does not need a migration engagement at all: it needs a baseline and a content parity check, and very little else. One sitting in the top two rows with a launch date already fixed usually needs the date moved rather than the mapping compressed, and that is a conversation worth having early, because it gets more expensive every week it is deferred.

What happens to rankings in the first weeks after launch?

Expect movement, and expect it to look worse before it looks better.

Search engines have to discover that the site has changed, recrawl it, and reprocess what they find, and none of that happens in a single pass. A site with a few hundred pages is normally reprocessed within weeks. A large site takes longer, and the pages that get crawled last are usually the deep ones.

A normal pattern is a dip in the first fortnight, partial recovery through weeks three and four, and a return to the previous level within one to three months. Sharper drops that keep falling past the fourth week are not a recrawl pattern, and should be treated as a fault rather than as patience being required.

The distinction we watch is between the whole site softening and specific pages disappearing. A general softening is usually reprocessing. A page that has fallen out entirely while its neighbours are fine is usually a mapping error, and that one is fixable in an afternoon if you find it in week one instead of month three.

This is why we stay attached after launch rather than handing over a document. The value of a migration plan is mostly spent in the fortnight after go live.

How long does recovery take, and what counts as recovered?

Recovery means the positions and the enquiries are back where the baseline said they were, and it usually takes one to three months on a well executed move.

Anything still down after that is not recovering, it is a loss that needs diagnosing. We judge recovery on the baseline rather than on the overall traffic line, because a traffic line can hide the thing that matters. Total visits can return to normal while the pages that produced enquiries stay down, replaced by traffic that never converts. That is a failed migration with a healthy looking chart.

The measures are the positions of the addresses that earned money before the move, the enquiries those pages produced, and the proportion of the old address list resolving correctly. The third should be complete within days. The first two take as long as they take.

Two migrations, and what the numbers did

Both moved without permanent loss, and one finished ahead of where it started.

A Cardiff accountancy practice moved from a custom system to WordPress with a new design and about eighty pages. The crawl found one hundred and forty live addresses rather than eighty, because eleven years of blog posts had never appeared in any sitemap. Nineteen of those posts were carrying positions on their own. The mapping covered all one hundred and forty, seventy of the old posts were merged into eight substantial guides with redirects pointing at the merged versions, and traffic dipped by about a fifth in the first three weeks. By week nine it sat around fifteen per cent above the pre migration baseline, because the merged pages ranked better than the fragments they replaced.

A three branch letting agency changed domain during a rebrand and kept its structure identical. The mapping took an afternoon because every address had a direct equivalent. What nearly went wrong was elsewhere: the staging site had been indexed for six weeks before launch, so two versions of the content existed before the real one went live. Removing the staging index and pointing the old domain properly took a fortnight to settle, after which positions returned to baseline within a month. Nothing in the design or the redirect plan caused the problem. A file nobody had looked at did.

What do we need from you and your developer?

Tell us before the launch date is fixed, and give us access to the current site data.

Those two things decide whether this is a controlled project or a rescue. From you we need read access to your search analytics and to whatever records enquiries, plus a sense of which pages actually matter commercially, because that is knowledge the numbers alone do not carry.

From whoever is building the new site we need a staging environment we can crawl, the proposed address structure before it is built rather than after, and a named person who can implement redirects. We work alongside your developer or your agency rather than replacing them, and most of our migration work runs that way. Where the build itself is also ours, it runs through our web design service planned around search from the start.

The one thing we ask for that people find unusual is the launch window. Migrating on a Friday afternoon means any fault runs unattended for three days, and the cost of that is real.

When is a migration the wrong idea entirely?

When the current site is producing enquiries and the reason for moving is that somebody has grown tired of looking at it.

That is not a reason, and a rebuild carries risk that a redesign of the existing pages does not. It is also wrong when the underlying problem is content rather than presentation. A site that does not rank will usually not start ranking because it looks better. If the pages do not answer the questions buyers are asking, a new theme changes nothing, and the money is better spent on the answers.

And it is wrong when nobody can afford the attention afterwards. A migration needs somebody watching for a month. A business heading into its busiest trading period is choosing the worst possible moment, and we will say so.

We turn down migration work on these grounds several times a year. It costs us the project and saves the client more than the project was worth.

Why True SEO for a migration

We are answerable for what happens to your rankings, not for the launch date.

That is an unusual position to take and it is the reason the work is scoped the way it is, with the baseline first, the mapping before the build, and somebody watching for the month after release. A design team is measured on delivering the site. Somebody has to be measured on the site still earning what it earned before.

True SEO Consultants Ltd works from Startup Stiwdio, University of South Wales, 86-88 Adam Street, Cardiff, CF24 2FN. We are led by Mohammad A Mahmud, an ACCA qualified accountant who has worked in search since 2011, and Julie Williams, a fractional finance director with more than thirty years behind her. Migrations get treated as commercial risk rather than as a technical exercise, which is what comes of having two accountants running a search consultancy. We work with businesses throughout the UK and onboard clients worldwide through a fully remote digital process, so the site being moved can sit anywhere.

Migration sits inside the wider set of search services this consultancy delivers, and it is usually the moment the rest of them become worth doing.