Website Migration Without Losing Traffic: The Complete Protocol with Semalt

A badly executed migration is the only marketing action capable of erasing three years of work in one afternoon. And it happens uncomfortably often: the redesign belongs to the design team, the replatform belongs to engineering, and nobody owns the question of what happens to the URLs that bring customers today.

This protocol is the one we apply to platform changes, full redesigns and domain consolidations. It needs no expensive tooling: it needs doing things in a specific order and not skipping the inventory.

First of all: the inventory almost nobody does

The asset to protect is not the website: it is the URLs currently receiving impressions and clicks. That list is exported from Search Console data before anything is touched, over at least twelve months so seasonality is included.

That export produces three lists, and it is worth keeping them separate because they deserve different treatment.

The critical list on a mid-sized site usually holds between thirty and two hundred URLs. That is perfectly manageable by hand, and it is exactly the part automated migrations destroy when they redirect everything to the homepage.

The redirect map: rules that prevent the usual mistakes

The map is a sheet with two columns, old URL and new URL, plus a third for verification. We apply four rules and all of them come from failures seen in production.

One redirect, not a chain. If URL A goes to B and B goes to C, make A point straight to C. Chains accumulate across successive migrations and dilute signals.

Permanent, not temporary. It sounds obvious and it is the most frequent failure in rushed changes. A temporary redirect tells the engine not to consolidate anything.

Same language and same page type. The old English version goes to the new English one, a product page to a product page, a category to a category. Crossing languages or types breaks coherence and produces strange results for weeks.

No cascade rules by unreviewed pattern. Regex rules are useful, but a real sample of every pattern must be checked before trusting them.

Switch week: what to watch and in what order

The manual check nobody wants to do

Checking a hundred redirects by hand is tedious and it is exactly the work that separates a clean migration from a lost quarter. Do it with a sheet and two columns: old address, actual result when opened. Not what should happen according to the map, but what happens when you type it into a browser.

Four variants of each address deserve checking: with and without trailing slash, with and without common parameters, the uppercase version if the old site allowed it, and the old-protocol version if certificates changed. Most silent failures live precisely there.

The rollback plan you hope never to use

Before switching, agree what would trigger a rollback and who can authorise it. In most cases rolling back is worse than fixing forward, because a second address change compounds the instability. But the decision has to be taken calmly beforehand, not at nine in the evening on launch day with everybody looking at a falling chart.

Which drop is normal and which is not

Every migration has an unstable period. What matters is telling it apart from a failure, because the response is opposite: in one case you wait, in the other you act the same day.

Normal: position fluctuation for two to six weeks, a ten to twenty per cent impression drop in the first weeks with progressive recovery, and new pages taking time to settle.

Not normal: a drop above forty per cent sustained for more than two weeks, the complete disappearance of a section, critical pages returning errors or receiving no crawler visits at all, or old and new URLs competing with each other in results.

That last case usually means redirects are not applying in every case - with and without trailing slash, or with parameters - and it is among the most expensive failures because everything appears to work.

Who owns what in a migration

Migrations that go wrong almost never fail from technical ignorance: they fail because nobody owned the URLs. In the usual split, design answers for aesthetics, engineering for the schedule, and marketing finds out about the change once it is in production.

The split that works assigns three named responsibilities. Someone owns the inventory and the redirect map, with veto power over the launch date if the map is unverified. Someone owns technical execution and confirms redirects are permanent, chain-free and applied to every variant of each address. And someone owns the four-week watch afterwards, with a review booked in the calendar rather than a vague intention to check.

The third is the most neglected. A migration does not end on switch day: it ends four weeks later, when somebody compares the critical list against reality and confirms every important URL has a destination, a correct response and crawler visits.

What to tell the client or the board beforehand

Anticipating the normal dip prevents very uncomfortable conversations two weeks later. Before migrating it is worth putting three things in writing: that there will be instability for two to six weeks, that specific signals will be watched from day one, and which threshold will count as an alarm requiring intervention.

That threshold has to be set beforehand, not during. Our usual reference: a sustained impression drop above thirty per cent across a whole section for more than seven days triggers immediate review; below that, you wait and document.

Writing this down has a useful side effect. It forces you to define what is being measured and against which baseline, which is exactly the discipline that stops a migration becoming a battle of opinions once the numbers start moving.

Special cases that deserve their own treatment

Domain change

Beyond the redirect map, controllable mentions have to be updated: business profiles, sector directories, email signatures, sales materials. Links you do not control will keep pointing at the old domain, which is why redirects must stay live for years, not months.

Merging two sites

The risk here is not losing traffic but duplicating content. Two pages answering the same query on different domains cannot both survive: pick the better performer, merge the content, redirect the other.

Redesign without URL changes

The calmest case and the most neglected. Even when addresses stay the same, the HTML, the internal linking and often the visible content change. If the redesign removes text for visual cleanliness, the drop arrives anyway, and it is harder to explain.

Migrating and redesigning at once: why it usually costs more

The temptation to use a replatform to also redo the copy, the menu structure and the category architecture is enormous, because it looks efficient. In practice it multiplies risk and, above all, prevents diagnosis.

If addresses, design, content and navigation all change on the same day and two weeks later traffic drops thirty per cent, there is no reasonable way to know which of the four caused it. The practical consequence is that everything gets reverted or nothing does, and both options are bad.

The sequence we recommend splits the changes into two phases four to six weeks apart. First the pure technical migration: same addresses where possible, same content, new platform. Once indicators confirm stability, then redesign and rewrite. It costs more coordination and saves entire quarters of diagnosis.

When the calendar does not allow separation - which usually happens when the old platform contract expires - at least document exhaustively what changed in each area, so problems can be reviewed piece by piece.

The follow-up report: closing the loop

Every problem line becomes a concrete action with an owner. Most migrations that recover well do so because somebody reviewed this list at week four; the ones that never recover are usually the ones nobody looked at again until revenue dropped.

When to push after the switch

A well-executed migration restores the previous level; it does not improve it by itself. If the goal was growth, the work starts afterwards: new content in the sections that now have better structure, and steady authority signals. That is where managed campaigns make sense - AutoSEO at $149 a month or FullSEO from $500 a month with a dedicated team - always after the new site is stable, never during the migration, because mixing the two makes it impossible to know what caused what.

After the migration: the opportunity usually wasted

A migration forces a full review of the page inventory, and that work is almost always thrown away once the switch is done. Inside the list of URLs with no impressions in twelve months there are two kinds of content: what never worked, and what worked and was abandoned.

The second group is a source of cheap wins. These are pages that had traffic, still hold links, and stopped being updated. Reviving them - current data, clear structure, an internal link to the matching commercial page - usually returns more than publishing new content, because they start with history.

The ideal moment is between weeks four and eight after the switch, once the new site has stabilised and the full inventory is still fresh.

Frequently asked questions