Content and growth
A new website should not cost you the visibility the old one earned
Most migration damage is caused by decisions made months before launch, by people who had no reason to know those decisions mattered. It is almost entirely preventable, and almost never prevented.
If a migration has already gone wrong, treat it as urgent — the recoverable window narrows week by week.
A website migration is one of the few events that can remove years of accumulated search visibility in a single afternoon. It is also one of the few where the risk is entirely known in advance, which makes the frequency of failure difficult to justify.
The pattern is consistent. A new site is commissioned for good reasons — the old one is dated, hard to maintain, poor on mobile. The agency building it is competent at design and development. Nobody in the project is responsible for the question of whether the new site will be found, because it did not occur to anyone that a better website could perform worse.
Three months after launch, traffic is down forty per cent, and the conversation becomes an argument about whose responsibility it was.
Process
How a migration is protected
The work divides across three phases, and the first is where nearly all of the value sits. By launch day, the outcome is largely already determined.
Before: establish what must be preserved
A complete inventory of every address that currently earns visibility, receives links or converts. Built from analytics, Search Console, server logs and a full crawl rather than from the sitemap alone, because the sitemap is always incomplete.
Before: review the proposed structure
Whether the new architecture preserves what matters, where content is being consolidated or dropped, and whether the new templates will present content in a form search engines can process. This is where changes are still cheap.
Before: build and verify the mapping
Every old address mapped to its closest equivalent, with any address that has no equivalent flagged as a decision rather than a redirect to the home page. Verified on staging before anyone commits to a launch date.
During: pre-launch verification
Confirming on staging that indexing directives are correct, structured data survived, canonical declarations point where intended, and the staging environment's blocking directives will not follow the site into production.
During: launch-day checks
Immediate verification that redirects are live and returning permanent status codes, that the production site is indexable, and that nothing is returning errors at scale. The first two hours matter disproportionately.
After: monitoring and correction
Tracking indexation, errors and visibility daily for the first fortnight and weekly thereafter. Migration problems announce themselves early to anyone watching for them and are considerably cheaper to fix in week one than in month three.
By the time a migration launches, whether it will succeed has already been decided. Launch day is when you find out, not when you influence it.
Failure modes
What actually goes wrong
Migration failures are remarkably consistent. In nearly every case the cause is one of a small number of mistakes, all of which are preventable and most of which are invisible until traffic falls.
The most damaging is also the most common: an incomplete redirect map. It happens because the map is built from the pages the organisation remembers, and websites accumulate pages nobody remembers — old campaign landing pages, articles from a previous marketing manager, product pages for discontinued lines that still hold links.
- Incomplete redirect mapping. Addresses that earned value return errors instead of resolving.
- Staging directives shipped to production. The blocking rule that protected staging follows the site live.
- Content quietly reduced. A cleaner design turns out to mean substantially less text.
- Content moved behind JavaScript. What was in the response now arrives after execution.
- Internal linking flattened. A simplified navigation removes the signals that distinguished important pages.
- Structured data lost. Markup that existed on the old templates was never carried across.
- Redirect chains. The new map layered on top of an old one, so requests resolve in four hops.
Situations
Migrations this applies to
Not all of these are equally risky. Domain changes and platform changes carry the most exposure; a template refresh carries the least, but not none.
Platform change
Moving between content management systems or ecommerce platforms. High risk, because URL structures, templates and rendering behaviour all change simultaneously.
Domain change
Rebrand, acquisition or consolidation. The highest-risk category, because every signal the previous domain accumulated must be transferred deliberately.
Site consolidation
Merging several sites into one. Complex because content must be combined without creating pages that compete with each other for the same intent.
Redesign on the same platform
Lower risk, and not zero. Template changes alter content volume, heading structure and internal linking, all of which affect how pages are assessed.
Internationalisation
Adding language or regional variants. Risky in a distinctive way: the errors tend to produce duplication and misdirected visitors rather than lost pages.
Protocol or subdomain change
Moving to HTTPS, or between www and non-www. Mechanically simple, frequently done incompletely, and easy to verify properly.
Frequently asked questions
When should we involve you?
We are only changing the design, not the URLs. Is this still relevant?
How much traffic is normally lost in a migration?
What is the single most common cause of migration failure?
Can you help after a migration has already gone wrong?
Record what your current site is achieving before you change it
A snapshot of the existing site is the baseline any migration should be measured against. It takes a minute now and is impossible to reconstruct afterwards.