SEO Migration

I start with a full audit of the current site's health. For a recent migration of a B2B SaaS blog from blog.site.com/blog/ to site.com/resources/, I exported 200 blog URLs from the [sitemap](/sitemap/), noted their organic traffic and ranking positions for key terms. The blog accounted for 12,000 monthly visits and 8% of revenue; I needed to protect that. Benchmarking showed that 30% of blog pages ranked in the top 3 for their main keyword. I also checked index coverage in Search Console to catch any already-orphaned pages.

Next comes URL mapping. I group URLs by page type: home, category, product, blog, landing page, and so on. For the blog, I used a simple pattern: /blog/YYYY/slug became /resources/slug. For pages with no direct equivalent — like archived event pages that generated 50 visits a month — I mapped them to the most relevant category page rather than the homepage. That preserved topical relevance. I also flagged 12 pages that would be removed because they had zero traffic and no backlinks; those got a 410 response.

Redirect implementation is where the real work begins. I deploy 301 redirects using the server configuration (nginx in this case), and then I test every single redirect with a script that curls the old URL and checks for the HTTP status and the destination URL. For 200 URLs, that takes about two minutes. I found five that returned 404 because I had mistyped a path, and one that looped back to itself. I fixed those before launch.

Before the DNS switch, I submit the new sitemap to Search Console and keep the old one active for a few weeks. I use the Change of Address tool only when the domain changes — for subdomain-to-folder migrations that stay on the same root domain, I avoid it because Google already treats subdomains as part of the same site. I update all internal links on the new site to point directly to the new URLs, not through redirects. Then I ask Google to crawl the new sitemap via the URL Inspection Tool.

A decision rule I follow: if the old domain has backlinks to pages that won't exist on the new site, I create dedicated landing pages with valuable content and redirect the old URL there, rather than to the homepage. That kept link equity flowing to a relevant context and minimised ranking drops for those terms.

The most common trap I see is using 302 redirects instead of 301s. A 302 tells search engines the move is temporary, so they keep the old URL as the canonical source and don't transfer link equity. I once inherited a migration where 2,000 product pages used 302s — traffic dropped 30% in two weeks before I switched them to 301s. Always use 301 for permanent site moves.

Blocking the new site is another classic mistake. If the new site has a noindex meta tag in the header, or the robots.txt file disallows all crawlers, Google will not index the new URLs. I've seen a team that launched a redesigned site with a staging environment's [robots.txt](/robots-txt/) still in place — it took four weeks to recover because Google had already dropped most URLs from the index. Audit the new site's robots.txt and meta tags before the switch.

Forgetting to update internal links creates unnecessary redirect chains. Each chain adds latency and can waste crawl budget. On a site with 50,000 pages, every page that links to a redirected URL forces Google to follow one extra hop. That slows down discovery of your new structure. I set a post-migration task to run a link audit and update any hardcoded references.

If your site uses [hreflang tags](/hreflang-tags/) for international targeting, a migration can break language and region signals. You must update each hreflang annotation to point to the new URL on the new site, or Google might treat the old and new versions as separate sites, diluting the signal. I map hreflang tags in the same spreadsheet as the URL mapping and verify them with the hreflang testing tool after launch.

Finally, don't forget [canonical tags](/canonical-tags/). On the new site, each page should self-reference its own URL as the canonical. If you leave the old canonical tags pointing to the old URLs, Google will see them as duplicates and may index the old ones instead. A client once kept old canonical tags on 300 blog posts; their new site showed zero indexed pages in Search Console for two weeks.

Early in my career, I thought a migration was finished once the redirects were live and the DNS had propagated. I celebrated the launch and then checked Search Console a week later to find that organic traffic had dropped 40%. A batch of redirect rules had failed because my .htaccess file had a syntax error that affected URLs containing a specific query string parameter. I had only tested 50 representative URLs, not the full set. Now I test every single redirected URL using a script that curls from the old URL and confirms the 301 status and final destination.

Another mistake: I forgot to update the canonical tags on a few hundred product pages. The new site had <link rel="canonical" href="http://old-site.com/product/..." /> because the developer had copied the template from the old site. Google indexed both old and new URLs as [duplicate content](/duplicate-content/), and the old URLs continued ranking with the old, outdated page content. It took three weeks to republish corrected canonicals and re-request indexing. That lesson cost me a client's monthly bonus.

I also once underestimated the importance of pre-migration backup. I had exported rankings and traffic data for high-value pages, but not for long-tail terms. After the migration, when I needed to compare performance for 5,000 keywords, I had no baseline for the long tails. I now export all keyword data from Search Console — clicks, impressions, position — for every query that ever had an impression in the last 16 months. That gives me a complete before-and-after picture.

One more: I used temporary testing domains that were password-gated with HTTP basic auth. Google could not crawl them, so when I launched the site the discovery was slow. Now I create a staging subdomain on the live server with no auth, and I block it via robots.txt only — so I can temporarily allow Googlebot to test a few pages before launch.