SEO Migration Without Losing the Plot
Key takeaways
- Map existing URLs before changing a domain, content management system or URL structure.
- Google recommends server-side permanent redirects where possible, including 301 and 308, and warns against irrelevant redirects to the homepage: site-move guidance.
- Update internal links, canonical URLs and sitemaps so they point to the new destinations rather than relying on redirect chains.
- Google AI-feature eligibility still depends on indexing and snippet eligibility; a migration does not create a special route to AI citations: Google's AI guidance.
- Define launch acceptance around both technical access and functioning commercial journeys, not a green homepage check.
What should an SEO migration actually preserve?
An SEO migration should preserve the relationship between a search need, its useful content and the page where a visitor can act. Keeping the server online is only one part of that job.
Google's site-move documentation recommends preparing the new site, mapping old URLs to new URLs, implementing redirects and monitoring traffic. It also advises changing one major thing at a time where practical.
Our recommendation for a UK founder or marketing lead is to separate the move from an untested rewrite of every commercial page. A domain change, new platform, new navigation and deleted buying guidance create several possible causes for a problem. Changing them together makes diagnosis harder.

Before commissioning the move, agree what must remain available: products, service explanations, regional details, evidence, downloads and the routes to enquire or buy. Treat those as acceptance requirements, not items to revisit after launch.
Which URLs deserve attention first?
Prioritise URLs by commercial importance and existing discovery signals, not merely by how recently they were published. Keep a complete inventory, then use priority to decide the testing order.
Google suggests identifying important URLs through sitemaps, analytics, server logs, links and the content management system in its mapping guidance. It also explicitly includes images, videos and other embedded resources in migration planning.
Build one inventory from those sources. Do not assume the current crawl contains every address that still receives a visit or backlink.
Our recommended priority groups are:
- Commercial journeys: pages associated with orders, enquiries, quotations or other meaningful actions.
- Established discovery: pages with useful search traffic, links or verified citations.
- Supporting evidence: specifications, research, downloadable documents and explanatory pages that help a buyer decide.
- Retired content: pages with no valid replacement, requiring an explicit removal decision.
Avoid deleting a low-traffic specification sheet solely because it looks quiet in analytics. First check whether it supports a valuable buying decision or has external links. “Not many visits” and “not useful” are different findings.
What belongs in the redirect map?
Each old URL needs a deliberate outcome: retain it, redirect it to a relevant replacement, consolidate it into genuinely matching content or retire it. The map should also record who accepted that outcome.

A useful working record contains the old address, its purpose, priority, new destination, expected response, content checks and accountable owner. For an international site, add the relevant language or region so a redirect does not silently change the audience.
Google recommends server-side permanent redirects where possible and direct routing to the final destination. It warns that redirecting many unrelated pages to a homepage can confuse users and be treated as a soft 404, meaning a page that behaves like an error despite its response.
If several old pages have genuinely been combined into a useful replacement, redirecting them to that consolidated page can make sense. If the content has simply gone and there is no relevant replacement, use the appropriate removal response rather than inventing a match.
A blanket homepage rule makes the spreadsheet shorter. That is not the same as making the migration better.
What must be tested before launch?
Test the proposed destinations, their important content and their search directives before exposing the move to normal visitors. Use real templates and difficult edge cases, not only a handpicked homepage.
Our suggested launch-blocker list is deliberately short:
| Area | Evidence required before release |
|---|---|
| Important destinations | Expected pages load with their main content and assets |
| Redirect rules | Old URLs resolve to the approved final destinations |
| Indexing controls | No unintended production crawl blocks or noindex rules |
| Canonical signals | Preferred URLs match the approved new structure |
| Commercial journeys | Forms, checkout or other agreed actions work end to end |
| Measurement | Required events are recorded and recognisable in the reporting system |
| Recovery | A named owner can apply the agreed rollback or forward fix |

This is a recommended operating standard, not a Google-mandated checklist. Keep the test output and record any accepted exceptions explicitly.
Use SAGEO's canonical-tags guide for preferred-URL checks and the JavaScript SEO guide when a new platform changes how content is rendered. A page shell loading successfully does not establish that the useful answer is present.
What changes when the migration goes live?
Re-test the public site because production infrastructure and settings can differ from the environment used for preparation. Launch approval should depend on the real destinations and actions.
Google's migration guidance calls for updated canonicals, internal links and relevant language annotations, removal of unintended staging noindex rules, redirect testing and Search Console monitoring. It also recommends submitting the new sitemap.
Start with the highest-priority old URLs, then test the broader inventory. Check the final response, destination relevance, canonical, visible content and important media. Validate a real enquiry or transaction through the site's authorised testing method without creating an accidental customer commitment.
Use the XML sitemap guide to check that the sitemap lists the intended new URLs. Do not leave internal navigation pointing through redirects simply because those redirects work.
For a UK business with regional or international sections, check that location-specific services, currencies and contact routes remain appropriate. That is an editorial and commercial acceptance check, not just a language-tag check.

How long should migration redirects stay?
Google recommends keeping redirects for as long as possible, generally at least one year. Its guidance also notes that keeping them indefinitely may be useful for visitors.
Do not remove redirects because the launch project has left the team's calendar. Keep ownership of the old domain, certificates and redirect infrastructure in the operating plan where they are needed for the move.
Google also warns that rankings can fluctuate while it recrawls and reindexes the site. There is no universal completion date. Monitor important page groups, errors, search visibility and commercial outcomes rather than treating one day's traffic change as a verdict.
Does an SEO migration affect AI discoverability?
A migration must preserve accessible, eligible source pages, but no redirect plan can guarantee continued citation by an AI answer engine. Keep technical eligibility separate from the system's decision to use a source.
Google says a supporting page in AI Overviews or AI Mode must be indexed and eligible for a search snippet. It states that there are no additional technical requirements, and that meeting its requirements does not guarantee indexing or serving.
Our recommendation is to preserve the material that makes an answer useful: the direct explanation, supporting evidence, qualifications, named entity and relevant commercial next step. Do not retain a URL while replacing its substance with a vague brand introduction.
Where you monitor AI citations, keep the observation method consistent before and after the move. Treat that as a separate monitoring exercise, not proof that one technical change caused every citation movement.
Planning a platform or domain move? Use the SAGEO starting point and bring the old URL inventory, proposed structure and launch date to the discussion. Ask for a migration acceptance brief, not just a redirect file.

Limitations
This framework is not a site-specific migration audit and does not guarantee rankings, traffic, leads or AI citations. Google documentation describes Google's systems; other search and answer engines may behave differently. Testing depth and release timing depend on the site's infrastructure and commercial risk.
Images are generated editorial concepts, not screenshots of audit findings, client systems or measured performance.