SEO Site Migration: How to Move Without Losing Rankings

TL;DR: A migration preserves search visibility when every valuable old URL has a relevant destination, permanent server-side redirects point there directly, and Google can crawl and index the replacement. Inventory and benchmark the old site before launch. Build a one-to-one redirect map, update internal links and canonical tags, submit new sitemaps, then monitor the old-to-new indexation crossover. Use Change of Address for domain moves, not HTTP-to-HTTPS or hosting changes.

The first question in site migration SEO is not which plugin to install. It is this: will users and Google see different URLs after the move?

Google Search Central separates migrations into site moves with URL changes and site moves without URL changes. That distinction determines most of the work. Domain changes, HTTP-to-HTTPS moves, changed paths, and domain consolidations belong in the first group. Switching hosts or moving to a CDN while preserving every visible URL belongs in the second.

We ran a domain migration ourselves when our two-person team, Lida and me, moved SEOJuice from seojuice.io to seojuice.com in January 2026. Moving the application was not the part that worried me. The risky part was proving that every old URL reached the correct replacement, that the new site did not rely on old-domain internal links, and that Google was replacing rather than merely discovering URLs.

That distinction matters. “The new site is live” is an infrastructure milestone. It is not evidence that the migration worked.

What counts as an SEO site migration?

An SEO site migration is a change substantial enough to affect how search engines reach, crawl, or index a website. A new domain is the obvious example, but several less dramatic projects require the same controls.

• Domain change: Moving to another domain during a rebrand, acquisition, or top-level-domain change.
• HTTP to HTTPS: The protocol is part of the URL, so this is a move with URL changes even though the hostname remains the same.
• Platform or CMS change: A new platform may alter paths, parameters, pagination, case handling, or trailing slashes. Treat it as a URL-change migration if any resulting URLs differ.
• Redesign or restructuring: A visual redesign is not automatically a migration. It becomes one when paths, slugs, navigation, canonicals, rendered content, or indexability change.
• Domain consolidation: Merging multiple domains or hostnames into one requires a separate inventory and redirect plan for each source.
• Hosting or CDN move: If user-visible URLs stay identical, this is primarily a DNS and infrastructure operation rather than a redirect project.

I would avoid combining these changes unless the business constraint is stronger than the diagnostic risk. Google’s guidance is blunt: “Change only one thing at a time.” A simultaneous domain, CMS, design, and taxonomy change gives you four plausible causes for every lost landing page (actually more once rendering and templates enter the picture).

Before launch: inventory first, migration second

Build a defensible inventory of old URLs

Your redirect map can protect only the URLs included in it. Crawl the old site, then combine that crawl with XML sitemaps, Search Console exports, analytics landing pages, backlink data where available, and server logs. Each source sees a different slice of the site.

A crawler finds linked pages but may miss orphans. A sitemap may exclude old URLs that still rank. Analytics will not show pages without recent visits. Logs can reveal requests to files and legacy paths absent from the current navigation. “Complete” is an uncomfortable word here (I usually settle for independently reconciled).

Keep non-HTML assets in scope where they have search value or external links. PDFs, downloadable guides, images, and old campaign pages are easy to omit because they do not appear in a normal page crawl.

Capture a baseline outside the system being replaced

Export organic landing-page traffic, important query and page performance, indexed-page information, top-ranking URLs, and current crawl results. Segment the data by directory or page type. A single sitewide traffic number is too blunt to debug a migration.

If traffic falls 12 percent, that number tells you almost nothing. If one product directory disappears while the blog remains stable, you have a useful lead. Check that directory’s redirects, templates, canonical tags, and indexing directives first.

I have skipped baseline work because launch felt urgent. It saved perhaps an hour and made the later diagnosis slower and less certain. Not a clever trade.

Map every old URL to its closest replacement

Google Search Central gives the core instruction:

A redirect map sends each old URL to its real new equivalent, one to one:

# 1:1 redirect map (Nginx) - old URL to its closest new equivalent
location = /old-blog/why-seo/    { return 301 /blog/why-seo/; }
location = /products/old-widget/ { return 301 /shop/blue-widget/; }

# Anti-pattern: never mass-redirect everything to the homepage
# location / { return 301 /; }   # this creates soft 404s

“Once you have the listing of old URLs, decide where each one should redirect to.”

Create a mapping with one row per old URL. Include the intended destination, expected response code, page type, migration status, and any reason for retirement. Prioritize URLs receiving organic visits or external links, but do not interpret “prioritize” as permission to ignore the long tail.

The destination must preserve intent. An old product page should lead to the same product or its genuine successor. A migrated article should lead to that article. The homepage is not a universal substitute.

Preserve existing paths wherever practical. Every unchanged URL removes a redirect rule, a mapping decision, and a possible failure. Teams often rewrite slugs during a redesign because the new versions look cleaner. I would ask what measurable problem that cleanup solves before accepting the migration risk.

Decide what should not be redirected

One-to-one mapping does not mean every deleted page must be forced somewhere. If a page has no equivalent and no useful successor, a proper 404 or 410 can be clearer than an irrelevant redirect.

This requires editorial judgment, not a spreadsheet formula. Redirecting a discontinued product to its replacement model may be useful. Redirecting a deleted event page to an unrelated events index may not be. Relevance first.

Prepare the replacement for crawling

Import the content, configure HTTPS, prepare the production robots.txt file, verify the relevant Search Console properties, and inspect page-level indexing directives. Validate canonical tags, hreflang where used, structured-data URLs, pagination, and XML sitemaps against the production hostname.

Staging sites are commonly protected with robots.txt rules, noindex directives, authentication, or some combination of them. Those protections must not leak into production. If pages remain absent after launch, the checks in Why isn’t my site on Google? cover robots controls, noindex directives, and URL Inspection.

For a large site, migrate a section first if the architecture permits it. Google recommends “initially moving just a piece of the site to test any effects on traffic and search indexing.” A staged move is not always possible, but it is worth considering before accepting an all-or-nothing cutover.

During launch: make every signal agree

Use direct, permanent server-side redirects

Google recommends “server side permanent redirects from the old URLs to the new URLs as you indicated in your mapping.” If redirect mechanics are unfamiliar, read What is a redirect? first. Our comparison of 301 and 302 redirects covers the permanent-versus-temporary decision in more detail.

As Patrick Stox, lead author of the Web Almanac SEO chapter, puts it:

“Make sure your redirects are 301 or 308 rather than 302 or 307 status codes if you are doing a permanent move and want URLs indexed on the new website instead of the old one.”

The status code is not ceremonial. Google’s redirect documentation explains what happens with a permanent redirect: “Googlebot follows the redirect, and the indexing pipeline uses the redirect as a signal that the redirect target should be canonical.”

Each old URL should point directly to its final destination. Avoid old-to-intermediate-to-final chains. Test for loops caused by overlapping HTTPS, www, trailing-slash, CDN, server, and application rules.

Then inspect the live response rather than the configuration file. A rule can be correct in isolation and still conflict with another layer. This is where I stop trusting the migration sheet (and, to be fair, my own memory) and crawl production.

Do not mass-redirect pages to the homepage

Google explicitly warns:

“Don't redirect many old URLs to one irrelevant single URL destination, such as the home page of the new site.”

A mass homepage redirect conceals missing mapping work; it does not complete it. Search engines and users expected a particular resource. Sending every request to a generic page discards that relationship.

If many URLs share a legitimate successor, a many-to-one mapping can make sense. Several duplicate product URLs may all resolve to the canonical product page, for example. The problem is irrelevance, not the arithmetic.

Update internal links, canonicals, and generated references

Redirects are fallback infrastructure. They should not become the new site’s internal-linking system.

Update navigation, breadcrumbs, article links, related-content modules, canonical tags, hreflang references, structured data, sitemap entries, and asset references to use final URLs directly. Google’s instruction is: “Change the internal links on the new site from the old URLs to the new URLs.”

From what we see across sites on SEOJuice, template-level old links are more consequential than isolated editorial links because one stale component can reproduce the same redirect dependency across hundreds of pages. Check the templates first, then the content body.

Submit sitemaps and use Change of Address correctly

Submit the new XML sitemap in Search Console. Google says this helps it learn about the new URLs. Keeping separate old-URL and new-URL sitemaps gives you a practical way to monitor replacement.

For a domain-to-domain move, submit Change of Address from the old Search Console property. Google’s precise instruction is to submit requests for “all subdomains and the www and non-www variants of the old domain name.” The tool supplements permanent redirects; it does not replace them.

Do not use Change of Address for HTTP-to-HTTPS migrations. HTTPS changes the URL, but Google expressly excludes that case from the tool. It is also unnecessary for hosting-only moves and path changes within the same domain.

After launch: watch replacement, not only traffic

A migration is not complete when DNS resolves and the homepage renders. It is complete when users and crawlers consistently reach the intended content and the new URLs replace the old URLs in Google’s index.

Monitor Search Console indexing reports, crawl errors, rankings, and organic landing-page traffic against the baseline. Google describes the expected indexation pattern clearly:

“Over time the number of pages indexed from the old URLs sitemap would drop to zero with a corresponding increase of indexing of the new URLs.”

That crossover is more useful than refreshing one traffic chart. If a section fails to rise on the new side, inspect its redirects, canonical tags, internal links, sitemap inclusion, rendered content, and indexing directives. Our guide to how Google indexing works explains the crawling and canonicalization process behind this replacement.

A temporary dip can occur while Google recrawls and reindexes changed URLs. There is no credible universal percentage or recovery deadline. Site size, crawl frequency, internal linking, redirect quality, and the extent of the change all differ. A sharp page-level or directory-level loss is more actionable than an industry average anyway.

Keep redirects running

Google says: “Keep the redirects for as long as possible, generally at least 1 year.” Keeping useful redirects indefinitely can also protect visitors using old bookmarks and links from sites you do not control.

Do not cancel the old domain or retire supporting infrastructure prematurely. A redirect that works for the launch crawl but disappears months later cannot help users or crawlers encountering an old link afterward.

The failures I would investigate first

Check accessibility and redirects before rewriting titles or blaming an algorithm update. Migration failures are often mechanical: a page is blocked, a redirect collides with another rule, or a canonical points to the wrong host.

The order matters. Fixing metadata on a URL Google cannot crawl is busywork.

A hosting-only migration is a different operation

If every user-visible URL remains unchanged, do not manufacture a redirect project. Google defines this case as switching hosting providers or moving to a CDN without affecting the visible URL.

Prepare and test the new infrastructure, lower DNS time-to-live where appropriate, change DNS, and monitor requests served by both environments. Google advises shutting down the old infrastructure only when you are confident that all users, including Googlebot, receive content correctly from the new setup.

There is no redirect map and no Change of Address request because the URLs did not move. The principal risks are availability, performance, DNS configuration, server responses, and differences in what the new infrastructure serves to crawlers.

How SEOJuice fits after a migration

After moving seojuice.io to seojuice.com, what we needed was a repeatable inspection of the live result. Not another launch spreadsheet.

SEOJuice’s free SEO audit checks migration-sensitive surfaces including robots.txt, sitemaps, canonical tags, HTTPS configuration, redirects, and internal links. It can surface links still pointing at the old domain, redirect destinations returning errors, leftover noindex directives, and canonical or HTTPS mismatches.

The boundary is important. The audit identifies what is wrong and where. It does not write server redirect rules or submit Change of Address for you. Those steps remain under your control (which is probably where domain-level changes should stay).

Frequently Asked Questions

What is an SEO site migration?

An SEO site migration is a change that affects how search engines reach, crawl, or index a website. Examples include moving domains, switching from HTTP to HTTPS, changing CMS platforms or URL structures, consolidating domains, and moving hosts. The central distinction is whether visible URLs change, because changed URLs require mapping and redirects.

Will I lose rankings when I migrate my site?

Not necessarily. Permanent redirects help Google treat the destination as canonical and replace the old URL. Some fluctuation can occur during recrawling and reindexing. Sustained losses usually justify checking missing redirects, irrelevant destinations, loops, temporary redirects, changed content, canonicals, and blocked indexing.

Do old URLs need one-to-one redirects?

Each valuable old URL should be assessed individually and redirected to its closest relevant replacement. Do not send unrelated pages to the homepage. If no relevant replacement exists, a proper 404 or 410 may be more accurate than a misleading redirect.

When should I use Google’s Change of Address tool?

Use it for a move from one domain to another. Submit the necessary requests for subdomains and www or non-www variants of the old domain. Do not use it for HTTP-to-HTTPS changes, paths changing within one domain, or hosting and CDN moves. Change of Address does not replace permanent redirects.

How long should migration redirects remain active?

Google recommends keeping redirects for as long as possible, generally at least one year. Retaining useful redirects indefinitely can protect old bookmarks and external links, provided the destinations remain relevant.

How do I verify that a migration worked?

Compare post-launch traffic, rankings, indexed URLs, and crawl results with the baseline. Crawl old URLs to confirm direct permanent redirects, crawl the new site for old internal links, and inspect robots directives, canonicals, sitemaps, and server responses. In Search Console, the old sitemap’s indexed count should decline while the new sitemap’s count rises.