Treat every existing URL as an asset or a decision.
A website migration is not only a file transfer. Search engines and other sites know the current pages by their URLs. Changing those addresses without an accurate route to the replacement creates dead ends for people and crawlers.
The safest plan inventories the old site, decides what each page becomes, tests the new site without exposing it early and monitors the live change after redirects are active.
How do you migrate a website without losing SEO?
Inventory the existing URLs, map every valuable page to a relevant destination, preserve strong content and metadata, implement server-side permanent redirects, update internal links and canonicals, remove launch noindex rules, submit the new sitemap and monitor Search Console, analytics and server errors after release. Some temporary ranking fluctuation can still occur while search engines recrawl the change.
Record what already exists before changing it.
The migration plan needs evidence from the current site. Do not wait until the old system has been switched off.
Create a URL inventory
Combine crawl data, sitemap URLs, analytics landing pages, Search Console data and important linked downloads. Include pages that sit outside the main navigation.
Mark performance and purpose
Record traffic, queries, links, conversions and the role of each page. A low-traffic page may still support customers, campaigns or a valuable integration.
Decide keep, improve, combine or remove
Give every old URL a clear outcome. Combine only when the new destination genuinely answers the old intent; otherwise return a true not-found response.
Capture technical settings
Record titles, descriptions, canonicals, structured data, robots directives, hreflang where used, analytics events and third-party verification that must survive the move.
Build a one-to-one redirect map wherever possible.
Google recommends server-side permanent redirects and warns against sending many unrelated old URLs to one destination such as the homepage.
Map to the closest relevant destination
Redirect an old service or article to the new page that serves the same need. A homepage redirect is appropriate only when the homepage is genuinely the replacement.
Avoid chains and loops
Point each old URL directly to the final live destination. Chained redirects add latency and make testing and future maintenance harder.
Update links at source
Replace old internal URLs in navigation, content, canonicals, structured data, sitemaps, profiles and important campaigns rather than relying on redirects forever.
Keep redirects in place
Google advises keeping migration redirects for at least a year. From a user perspective, useful old addresses may deserve an indefinite route.
Test the release, then watch the live site closely.
The first crawl of the live migration often exposes gaps that a design review cannot see. Assign an owner to the post-launch checks.
Check index controls
Confirm the production robots.txt allows intended crawling and that temporary noindex rules are removed from indexable pages. Verify canonicals point to the live preferred URLs.
Test response codes
Sample and bulk-check old URLs, redirects, live pages and intentional removals. A visual destination can still return the wrong HTTP status.
Submit and inspect
Submit the new sitemap in Search Console, inspect important URLs and monitor indexing reports. Use the Change of Address tool when moving to a new domain or subdomain as Google specifies.
Monitor people and systems
Watch landing-page traffic, forms, key journeys, server errors, redirects and analytics events. Search data takes time, so keep operational checks separate from ranking observations.
The migration launch checklist.
Resolve these controls before opening the new site to search engines and customers.
URL map
Every important old URL has a relevant final destination or a deliberate 404/410 decision.
Redirects
Permanent server-side redirects work directly, without loops, irrelevant destinations or unnecessary chains.
Indexation
Production robots, noindex rules and canonicals match the intended public site.
Content and metadata
Important headings, copy, titles, descriptions, structured data and alternative text have been carried across or deliberately improved.
Internal and external routes
Navigation, contextual links, sitemaps, profiles, campaigns and high-value backlinks point to current URLs where they can be updated.
Measurement
Search Console, analytics where approved, form delivery and conversion events remain accessible and testable.
Post-launch owner
Somebody is responsible for crawl errors, redirect gaps, content issues and performance after release.
Sources and further reading.
These primary sources inform the guidance above. Your project may need additional legal, security or accessibility advice for its own context.
Site moves and migrations
Google Search Central: Google's current process for URL mapping, redirects, crawl controls, Search Console and post-move monitoring.
Redirects and Google Search
Google Search Central: Official guidance on permanent and temporary redirect methods and their use in search.
Put migration into the redesign scope from day one.
We can inventory the existing site, define the redirect map and make search protection part of the build and launch plan rather than an afterthought.
Website migration questions.
Will a website redesign affect Google rankings?
It can. Content, URLs, internal links, metadata, rendering and performance may all change. A well-run migration protects existing signals, but Google notes that significant moves can still produce temporary fluctuations while pages are recrawled and reindexed.
Should every old URL redirect to the homepage?
No. Redirect each old page to the closest relevant replacement. Google warns that sending many unrelated URLs to one destination can confuse users and may be treated as a soft 404.
How long should website redirects stay active?
Google recommends keeping site-move redirects for at least one year so signals can transfer as pages are recrawled. Useful legacy URLs can remain redirected for longer to protect bookmarks and external links.
Should a staging website be indexed?
Usually not. Protect staging with authentication or suitable crawl and indexing controls. Before launch, explicitly verify that the production site no longer carries temporary blocks or noindex rules.