SEO and Site Migrations
Last updated
A site migration is any significant infrastructure change to a website: moving to a new domain, switching from HTTP to HTTPS, restructuring URLs, rebuilding on a new CMS, or combining multiple sites into one. The defining characteristic is that search engines must update how they understand and access the site. Done poorly, migrations can erase years of accumulated ranking signals in days.
Migration risk categories
Not all migrations carry equal risk. The main categories, roughly ordered by SEO impact:
Domain migrations carry the highest risk. Moving from one domain to another requires Google to transfer signals accumulated over years to an entirely new entity. The 301 redirect chain passes PageRank, but the transfer is not instantaneous and not always complete. Domain authority, brand signals, and established indexation can take months to fully re-establish.
URL restructures change the address of existing pages without changing the domain. Rewriting /blog/post-title to /resources/post-title, or removing date-based paths from URLs, requires a redirect for every changed URL. Pages without redirects lose all their inbound link equity and indexation history.
Protocol migrations (HTTP to HTTPS) are now considered routine, but still require correct redirect configuration. All HTTP variants must redirect to HTTPS, including both www and non-www versions.
CMS or platform rebuilds often involve unintentional URL changes, template changes that alter content, and shifts in page speed or rendering method. Even if URLs stay the same, a CMS change can alter what Googlebot sees when it crawls the page.
Content consolidations merge multiple sites or subdomains into one. Google must reconcile competing signals across previously separate entities, which can temporarily disrupt rankings even when the migration is technically clean.
The three non-negotiable requirements
Regardless of migration type, three steps determine whether rankings survive:
1. Complete URL inventory before migration. You cannot redirect what you have not catalogued. Crawl the current site with a tool such as Screaming Frog, export all indexable URLs, and cross-reference with Google Search Console to identify which URLs have impressions or indexation. This is the baseline.
2. A 1:1 redirect map. Every URL that changes must have a redirect to its new equivalent. Redirecting the homepage only, or redirecting changed directories but not individual URLs, is a partial migration. Each page that disappears without a redirect loses its inbound links, its indexation history, and any ranking signals accumulated over its lifetime.
3. Post-migration monitoring. Rankings and indexation do not confirm themselves. After launch, check Search Console daily for crawl errors, indexing drops, and manual actions. Compare crawl stats before and after. Monitor rankings for key pages. Problems identified within the first two weeks can usually be corrected before Google finalises its recrawl of the site.
What migrations cannot fix
A migration is an infrastructure event, not a content reset. Pages that ranked poorly before a migration will not rank better after it unless the content or targeting changes alongside the technical work. Similarly, a domain with a weak backlink profile does not acquire a stronger one by moving to a new domain name.
Migrations also do not repair underlying technical problems. If the current site has crawl blocks, thin content, or poor Core Web Vitals, those issues will exist on the new site unless they are explicitly addressed as part of the project.
Planning a migration
The full technical process, including pre-migration auditing, redirect mapping, staging checks, launch day configuration, and post-launch monitoring, is covered in the site migration guide.
The key principle that determines whether a migration succeeds or fails is timing: the redirect map must be complete before launch, not assembled after ranking drops are noticed.
Common mistakes
| Mistake | Effect |
|---|---|
| Launching without complete redirects | Inbound link equity lost; indexed pages return 404 |
| Chaining redirects (A → B → C) | Each hop loses a fraction of link equity; crawl efficiency drops |
| Forgetting www/non-www and HTTP/HTTPS variants | Some inbound links continue pointing to unreachable versions |
| Not updating internal links post-migration | Internal links still point to redirected URLs, increasing crawl hops |
| Removing the old domain too quickly | Inbound links from external sites still pointing to old domain lose value |
Monitoring after migration
Search Console is the primary tool. After migrating:
- Submit the new XML sitemap immediately
- Use the URL Inspection tool to verify key pages are being crawled and indexed at the new URLs
- Monitor the Coverage report for spikes in 404 or redirect errors
- Check the Performance report to track impressions and clicks over the weeks following launch
Most migrations see a temporary dip in rankings as Google processes the changes. A well-executed migration recovers within four to eight weeks. A poorly executed one can take six months or longer, and in some cases the signals are never fully recovered.