Site Migration SEO

A site migration is when you change the URLs, domain, platform, or hosting of your site. In my experience, the SEO world treats it like a routine IT task, but it is closer to open-heart surgery. One missed redirect or a broken internal link can send your organic traffic into a tailspin that takes months to recover. I rank migrations by risk: domain change is the highest, followed by platform switch (like moving from WordPress to a custom CMS), then URL structure change. The lowest risk is a simple HTTPS migration, but even that can go wrong if you forget to update hard-coded links in PDFs or third-party services.

I always prepare a full URL inventory before touching anything. I crawl the live site with a tool like Screaming Frog, export every URL, then map each one to a new destination. If I cannot find a logical new home for a page, I redirect it to the nearest parent category rather than the homepage. That rule alone saved a client's traffic when we migrated a 20,000-page e-commerce site. The redirects worked, but the internal links were still pointing to old URLs. That is a common failure point. I now run a script to replace all internal links in the database before launch.

The rule I live by: never launch on a Friday. Give yourself at least a working week to fix errors before the weekend hits. A migration is not finished when the new site is live; it is finished when the old URLs stop appearing in search results.

It matters every time you change the URL of a page that has traffic or backlinks. But the two scenarios where I have seen the most damage are domain changes and CMS migrations. A domain change resets all your domain authority – search engines have to re-learn the new domain's trust signals. CMS migrations often break more than you expect because the underlying template code changes how URLs are generated. I once moved a client from an old ASP.NET site to a modern CMS. The new system generated cleaner URLs, but the old URLs had query parameters that were not mapped correctly. We lost 40% of organic traffic in the first week because I missed a set of 200 URLs that had no redirects.

Benchmarking is non-negotiable. I pull data from Google Search Console and analytics for the 30 days before the migration. I note the top 50 landing pages by traffic and their average positions. After the move, I compare week-over-week to see if the new pages are settling. If traffic drops more than 20% in the first two weeks, I stop the rollback and investigate. Usually the culprit is a robots.txt that accidentally blocks the new site, or a missing [301 redirect](/301-redirect/). I also check [canonical tags](/canonical-tag/) – they should point to the new URL, not the old one. A common mistake is to keep the old canonical, which tells Google to ignore your new page.

Another scenario where migration matters is when you merge two sites. I handled a merger where we had to combine 5,000 pages from one domain into another. The redirects were in place, but the internal linking structure of the new site still pointed to the old domain. That caused a chain of redirects that slowed down the site and diluted link equity. I now prioritise updating internal links before the redirects go live. A [technical SEO audit](/technical-seo/) should catch these issues, but do not rely on it – crawl the new site yourself after launch.

For years I believed that a perfect redirect map was all you needed. I thought if every old URL returned a 301 to the right new URL, search engines would cleanly transfer rankings. I was wrong twice.

First, I ignored internal links. On a migration for a 50,000-page site, I spent three weeks on the redirect map but never updated the internal links. After launch, Google crawled the old internal links, which redirected to new URLs. That created a redirect chain that increased page load time and confused the crawler. The result: the new pages took six months to recover their original rankings. I now run a script to update every internal link in the database to point to the new URL, not the old one. I also update the [sitemap](/sitemap/) to include only new URLs, and I submit it to Google Search Console on launch day.

Second, I underestimated the staging environment. I used to set up a staging site that was password-protected and thought that was enough. But Googlebot sometimes finds the staging URL through referrer logs or if the password is weak. One client's staging site got indexed because I forgot to add a noindex tag. The duplicate content flag confused Google, and the live site dropped in rankings. I now block staging with a [robots.txt](/robots-txt/) disallow rule and a password, and I never use the same user-agent as the live site. I also check the staging site's crawlability in Search Console before launch.

I also learned that [hreflang tags](/hreflang-tags/) need careful handling during a migration. If you have a multilingual site, the hreflang annotations must reference the new URLs. I forgot to update them once, and Google stopped showing the correct language versions in search. That cost a client 30% of their international traffic for two months. Now I add hreflang verification to my migration checklist.