The 60-second answer
A redesign becomes a search migration when it changes how engines discover, identify or interpret important pages. The risk is not the new visual design itself. It is the broken continuity between the old evidence and the new website.
Protect that continuity through five controls:
- record what is changing;
- map every valuable old URL to an appropriate outcome;
- test search and commercial journeys before launch;
- monitor by failure type rather than one traffic total;
- keep ownership until the new system reaches a stable baseline.
Google may need time to process correct changes. Waiting is appropriate only after you have proved that the implementation is sound.
1. Start with the migration surface
“We are changing the website” is too vague for risk planning. List the systems that will move.
Address changes
Domain, subdomain, protocol, folders, product handles, language paths and parameters.
Content changes
Removed pages, consolidated services, rewritten categories, altered headings and changed internal links.
Rendering changes
New JavaScript framework, server-side rendering, client-side navigation, image delivery or consent controls.
Commercial changes
Checkout, forms, account journeys, product feeds, stock, currencies and analytics events.
Search instructions
Canonicals, robots rules, sitemaps, hreflang, structured data and status codes.
This creates the migration surface: the complete set of things that can break or require reprocessing. A redesign can look modest and still have a large migration surface.
2. Build the evidence pack before building redirects
The redirect map is important, but it should not be the first artefact. Begin with evidence of what the existing site does.
For every priority URL, capture:
- current address and intended destination;
- page purpose and target market;
- organic clicks and impressions;
- conversions or assisted commercial actions;
- significant external and internal links;
- indexability, canonical and status code;
- replacement, consolidation or retirement decision.
Do not preserve a page merely because it exists. Do not delete it merely because traffic is low. A low-traffic page may support a valuable journey, earn links or explain a product constraint.
The evidence pack also creates a pre-launch baseline. Without it, the team cannot tell whether a post-launch change is a fault, expected processing or an existing weakness.
3. Give every old URL an explicit outcome
Each discovered URL should have one of four outcomes:
| Outcome | Use when | Required proof |
|---|---|---|
| Retain | Address and purpose remain valid | Same URL returns the intended page |
| Redirect | A clear replacement exists | Permanent redirect to the closest relevant destination |
| Consolidate | Several pages now serve one intent | Destination covers the material need of the old pages |
| Retire | No replacement or continuing value exists | Deliberate not-found or gone response, with links removed |
Avoid universal redirects to the homepage. They hide planning gaps and give users a destination unrelated to their request.
Google’s own site-move guidance recommends mapping old and new URLs, using permanent server-side redirects and avoiding redirect chains where possible (Google Search Central: site moves).
Test the map as data. A spreadsheet reviewed by eye is not proof that the server implements it.
4. Define launch acceptance tests
The new site should not launch because it looks finished. It should launch because agreed tests pass.
Search controls
- Priority destinations return HTTP 200.
- Old priority URLs return the planned permanent redirect.
- Redirects do not loop or pass through avoidable chains.
- Canonicals point to indexable final URLs.
- Production pages are not blocked by
robots.txtornoindex. - Sitemaps contain the final canonical addresses.
- Internal links use final URLs rather than relying on redirects.
- Structured data matches visible page content.
Commercial controls
- Forms reach the correct owner.
- Checkout, booking and account journeys work on mobile.
- Prices, stock and product feeds agree.
- Consent and analytics events fire as designed.
- Error messages and recovery paths are usable.
Operational controls
- Monitoring starts before DNS or routing changes.
- A named person can roll back or patch critical faults.
- The team knows which errors require immediate intervention.
Record the result. “The agency checked it” is not an acceptance test.
5. Triage post-launch movement by failure type
One traffic chart cannot diagnose a migration. Split the evidence.
| Observation | Likely investigation |
|---|---|
| Widespread crawl errors | Hosting, routing, robots or server response |
| Old URLs remain indexed | Redirect discovery, chains or mapping quality |
| New pages classed as duplicates | Canonicals, similarity and content differentiation |
| One section loses visibility | Mapping, navigation, content or template issue |
| Traffic holds but conversion falls | UX, forms, checkout or tracking |
| One market disappears | Hreflang, localisation, routing or regional content |
Some correct changes take time to settle. Google notes that after certain content corrections, pages can remain in a duplicate cluster while canonical selection is re-evaluated (Google canonicalisation troubleshooting). That is a reason to inspect before reacting, not a reason to ignore errors for a fixed period.
Server failures, accidental blocking and broken redirects require immediate correction. A canonical still being reconsidered may require patience and evidence.
6. Use recovery criteria, not a launch anniversary
A migration is not stable because a particular number of days has passed. It is stable when the new system behaves coherently.
Look for:
- priority redirects repeatedly crawled and respected;
- destination pages indexed as intended;
- old addresses declining without valuable pages becoming orphaned;
- errors returning to an agreed operating range;
- search visibility forming a consistent new baseline;
- commercial journeys and reporting reconciled;
- unresolved exceptions assigned to owners.
Review by page type and market. A stable homepage can hide a failed product category. Total traffic can hide a conversion loss.
Keep the migration register open until the evidence supports closure. Handover is an operational decision, not a project-management ceremony.
Conclusion: protect continuity, not just rankings
A website migration moves more than pages. It moves addresses, evidence, commercial journeys and the instructions search engines use to connect old and new.
Map the change surface, prove the implementation and diagnose movement by type. The goal is not a promise of zero fluctuation. It is a controlled transition in which errors are visible and recoverable.
Can your team prove the migration is ready to launch?
Bring us the URL inventory, proposed architecture and critical customer journeys. We can turn them into a migration register, executable checks and a post-launch control plan - without pretending all movement can be eliminated.
Frequently asked questions
No. Risk depends on what changes and how continuity is managed. URL, rendering, content and technical-instruction changes deserve explicit controls.
No. Redirect when an appropriate replacement exists. Retire pages deliberately when no useful equivalent remains, and remove links pointing to them.
Immediately for server errors, blocking, broken journeys and incorrect redirects. For processing or canonical reassessment, inspect the configuration and evidence before changing it again.
Google recommends keeping them for at least a year, and users or external links may justify retaining them longer. Treat removal as a separate risk decision.
The live migration register connecting each important URL, intended outcome, test result, post-launch observation and owner.
Primary Google documentation checked on 15 July 2026. Migration effects vary by site, architecture and scale; this article is operational guidance, not a performance guarantee.