What Is a Site Migration in SEO?
Most people arrive at this question because a developer or a designer has proposed something and they want to know what the risk is. The useful answer is that a migration is any substantial change to what lives at an address, that a great many rebuilds are migrations without anybody calling them one. The risk comes from not knowing that.
A Definition That Is Wider Than People Expect
A site migration is any substantial change to a website's addresses, platform, structure or domain. That definition catches far more projects than the word implies, which is the first useful thing to know.
What the four things mean. In order of how obvious they are.
A domain change is moving to a different web address entirely. A platform change is moving the site onto a different system. A structure change is reorganising how pages relate to each other. An address change is altering where individual pages live.
The important consequence. Names do not matter.
A redesign that changes addresses is a migration whatever anybody calls it. The search consequences follow from what actually changed rather than from what the project was titled in the proposal.
What is not a migration. Worth stating too.
Changing the wording on a page, adding a new page or altering colours and imagery without touching addresses is ordinary site work. The line is whether what lives at an address has changed.
Why the definition is the whole point. Recognition comes first.
Nobody plans for a risk they have not identified. Block two is about how frequently that happens.
Most Migrations Are Not Called Migrations
Almost nobody commissions a migration. They commission a new website, a rebrand or a move to a better platform. The migration happens inside it without ever being named.
The projects that are actually migrations. Five common ones.
A rebrand with a new domain. A new website replacing an old one. A move to a different platform. Tidying up untidy addresses. Adding a second language or a country version.
Why the naming matters so much. It determines who is in the room.
A project called a redesign is staffed and scheduled as a design project. The people involved are designers, developers and whoever signs it off. Search is not represented, because nobody identified it as relevant.
What that produces. A predictable pattern.
The work is done competently, the site launches, it looks better than the old one and something happens to performance weeks later that nobody connects back to the launch.
The practical test. One question.
Ask whether any page will live at a different address afterwards. If the answer is yes the project is a migration and should be planned as one. The same applies if nobody is sure.
What Is Actually At Risk
The website itself is the least valuable thing in a migration. What is at risk is everything that has accumulated around its addresses over the years the site has existed.
Rankings. The visible part.
Positions built over time, which are attached to specific addresses rather than to a business in the abstract. Change the address without telling anything, then the position has nothing to attach to.
The traffic that follows them. The commercial part.
Whatever proportion of enquiries or sales arrives through search. That is the number a business actually feels. It moves after the rankings rather than with them.
Every external link. The irreplaceable part.
Every link any other website has ever pointed at the old addresses. Those were earned over years. They cannot be rebuilt on demand and they stop working the moment their target does.
Why that framing helps. It sets the budget.
A migration described as a website project gets a website project's care. Described as protecting years of accumulated value, it gets planned properly.
Why It Goes Wrong
Migrations rarely fail because somebody was bad at their job. They fail because of how projects are organised, which is a more useful thing to know since it can be fixed at no cost.
Search is nobody's job. The root cause.
The developer assumes the marketing side has it covered. The marketing side assumes the developer has it in hand. Nobody has been made accountable, so nobody checks.
The deadline is the launch date. The pressure.
Everything on a build project is measured against going live. Work that protects something invisible competes badly against work that visibly delays a launch.
The consequences arrive late. The reason it repeats.
Search effects appear over the following weeks. By then the project is finished, the team has moved on and whoever notices the decline is not the person who could have prevented it.
Why this matters more than technique. It is preventable.
Naming one person as accountable for the search side, at the start, is the cheapest risk reduction available on any migration. It costs nothing and it prevents most of what goes wrong.
What Good Looks Like
A well run migration follows a sequence: audit, map, test, launch, notify, monitor. Each stage exists so that the next one is recoverable if something is wrong.
Audit. Record what exists.
A complete picture of the current site before anything changes. This is the only stage that cannot be done later, which is why it comes first.
Map. Decide where everything goes.
A document listing every existing address and its destination. This is the artefact the whole migration runs on.
Test. Check the plan against reality.
Verifying that what was built matches what was mapped, while it is still cheap to correct.
Launch, notify, monitor. The three after.
Going live, telling the places that need telling and watching for the weeks that follow. The project does not end at launch, which is the mistake most projects make.
A Drop Is Normal
A temporary decline in performance is expected after a migration, including a well run one. Almost nobody is told this in advance. Being told changes what happens next.
Why it happens. Everything has to be rediscovered.
Old addresses have to be revisited, redirects have to be found, new addresses have to be assessed. None of that is instant and none of it happens in a neat order.
What that looks like from outside. Alarming.
Performance moves, some pages behave differently from others and the site appears inconsistent for a period. That looks like a failure and is usually the normal middle of a process.
The useful questions. Three of them.
How deep is the decline, how long has it lasted and which direction is it moving. Those tell you something. Whether a dip happened at all does not.
Why being told matters. It prevents the second mistake.
Somebody who was not warned panics and starts changing the site, which makes the cause impossible to identify and delays the recovery they were trying to accelerate.
Who Should Be Involved And When
Search input is needed at the planning stage. Being asked to check a site the week it goes live is being asked far too late to change anything that matters.
What gets decided early. The things that cannot be undone.
How addresses will be structured, what the site's hierarchy will be, which pages will exist and which will not. All of that is settled in the first weeks and all of it has search consequences.
What a late review can achieve. Very little.
Somebody brought in the week before launch can check redirects and catch obvious errors. They cannot change a structural decision made in week one without the project being rebuilt.
What to ask for instead. A seat at the start.
Involvement when the structure is being decided, not when it is being implemented. That is a scheduling change rather than a budget one.
Who else needs to know. More than the build team.
Anyone running advertising, email or anything else pointing at specific addresses. Those break in exactly the same way and are usually forgotten entirely.
What This Cluster Covers
The rest of this series follows the sequence in block five, with separate guides for the platform moves people search for by name.
Working out what you are doing. The first decision.
Which kind of migration this is, plus whether it should happen at all, in types of site migration.
Getting ready. The stages before anything moves.
Planning, auditing and mapping, beginning with how to plan a site migration.
The mechanics. What actually has to be right.
Redirects, internal links, tags, crawling and indexing, structured data and performance, each with its own guide.
Afterwards. The part projects forget.
Notifying, monitoring, recovery and what to do when something has gone wrong. The catalogue of what tends to go wrong is in common site migration mistakes. The full series is on the website migration guide.
Most migrations
are not called
migrations.
The search side owned by somebody named at the start rather than assumed, the structure decided before it is built rather than checked after, every address recorded while the old site still exists, the settling period expected rather than panicked through, with nothing changed while anybody is still watching.
What a migration engagement covers:
A migration is a one-off project rather than a monthly service, so it is scoped and quoted against the size of the site and how much is changing at once.
Every guide.
One practice.
What a migration is, the types, when to do it, planning, the checklist, auditing, mapping, redirects, internal links, tags, downtime, crawling, structured data, performance, notifying, monitoring, recovery and the mistakes.
