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.
Entity migrations carry a distinct risk that technical redirects alone do not address. When a company renames itself alongside a domain move, search engines must reconcile signals accumulated under the old brand name: Knowledge Graph entries, Wikidata, Wikipedia, third-party profiles (Crunchbase, LinkedIn), press coverage, and the anchor text of backlinks. Redirects transfer link equity, but they do not automatically update Google’s entity model. The TransferWise to Wise migration saw organic traffic fall from around 32 million to 13 million monthly visits before recovering within four months, despite the technical migration being well-executed.1
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. The rendering approach matters too: moving from a server-rendered framework to client-side JavaScript means Googlebot must queue pages for rendering rather than reading HTML directly, which can delay indexing across the entire site. A less visible risk is structural changes to HTML: replacing semantic elements like <table>, <article>, or <nav> with generic divs removes signals Google and AI systems use for content parsing, even when the visual result looks identical.
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.
Check for externally linked pages that a crawl won't find
A standard site crawl only finds pages reachable through internal links. Pages used as paid campaign landing pages, email destinations, or older press coverage URLs often carry external links but have no internal links pointing to them, so they won't appear in Screaming Frog or similar tools. Export your full backlink profile from Ahrefs or Majestic and cross-reference it against your crawl export. Anything in the backlink profile that isn't in the crawl export needs a redirect too.
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 can a site migration not 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.
How do you plan a site 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.
Time the launch to your traffic trough
Before fixing a launch date, pull 12 months of organic traffic and identify your quietest period, typically a low-trading week or off-peak month for your sector. A well-executed migration still causes a temporary dip while Google processes the changes. Launching during a traffic trough means that dip happens when there is least to lose. The same migration launched at peak season causes identical short-term disruption at maximum cost to the business.
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 |
| Not removing the noindex directive | Often leftover from staging; prevents indexation and keeps your site out of search results |
| Forgetting image URLs in the redirect map | Image URLs carry link equity and image search rankings; they need 301 redirects just like page URLs |
| Replacing semantic HTML with styled divs | Removing elements like <table> or <article> strips structural signals Google and AI systems use for content parsing |
How do you monitor rankings after a 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.
Exclude branded traffic from your at-risk forecast
When estimating organic traffic at risk before a migration, calculate from unbranded sessions only. Brand-name queries rarely lose rankings during a domain or URL change. Google's entity signals for your brand are largely independent of the URL signals being migrated. Including branded traffic in the model overstates the risk and can lead to unnecessary scope reductions or delays. Apply a query filter in Search Console to strip branded terms before building the forecast.