Site migrations are one of the highest-risk events in SEO. Done well, a migration causes a temporary dip in traffic that recovers within weeks. Done poorly, it can destroy years of accumulated ranking equity in a matter of days. I have helped clients recover from migrations that went wrong, and that work is significantly harder and more expensive than planning the migration correctly from the start.

Types of Migrations and Their Risk Levels

Not all migrations carry the same risk. Changing hosting providers without touching URLs is low risk. Redesigning a site while keeping URLs and content identical is moderate risk — there are still implementation opportunities for something to go wrong. Changing the domain, switching platforms, restructuring URLs, consolidating multiple sites, or doing all of these simultaneously is high risk and requires the most rigorous planning. The combination of domain change plus URL restructure plus content consolidation in a single push is the scenario that tends to produce the worst outcomes.

  • Domain migrations: full 301 redirect map from every old URL to its new equivalent is non-negotiable
  • Platform migrations (e.g., WordPress to Webflow): verify the new platform generates the same URL structure or plan redirects
  • HTTPS migrations: if still on HTTP, consolidate to HTTPS before any other changes when possible
  • Subdomain to root domain consolidation: requires canonical and redirect coordination across two origins

Pre-Migration Checklist

I build a pre-migration baseline before anything changes. This includes a full crawl of the current site to capture every URL, a download of Google Search Console data covering the past 12 months of queries and clicks, and a snapshot of rankings for the top 100 to 200 target keywords. This baseline is what I measure against post-launch to identify specific drops and diagnose their cause. Without it, recovery is guesswork.

  • Crawl the existing site and export all URLs, canonical tags, meta tags, and internal link structure
  • Export Search Console performance data (queries, pages, clicks, impressions) for the baseline period
  • Identify the top 20 percent of pages by organic traffic — these are the highest priority to map correctly
  • Verify that 301 redirects are in place and tested in a staging environment before going live
  • Update the XML sitemap to reflect new URLs and submit it immediately after launch

Building a Redirect Map That Actually Works

The redirect map is the most critical deliverable in any domain or URL migration. A map that covers 95 percent of URLs sounds almost complete but it means five percent of your pages — possibly including some of your strongest-performing ones — return 404s after launch. I use a combination of the pre-migration crawl export and Search Console's top pages report to build an exhaustive list, then map every old URL to its logical new destination.

For a WordPress-to-WordPress migration where the URL slug changes across the board, a bulk redirect plugin can process the map. For more complex platform migrations, server-level redirects in an .htaccess file or Nginx config are more reliable than application-layer redirects. Here is what a batch of 301 directives looks like in .htaccess:

RewriteEngine On
Redirect 301 /old-page/ https://newdomain.com/new-page/
Redirect 301 /services/old-name/ https://newdomain.com/services/new-name/
Redirect 301 /blog/2021/post-title/ https://newdomain.com/blog/post-title/

Each old path maps to exactly one new canonical URL. Redirect chains — where old-URL-A redirects to old-URL-B which redirects to new-URL-C — pass equity with reduced efficiency and should be collapsed to single-hop 301s before launch.

Launch Day and Immediate Post-Launch

On launch day I monitor server response codes in real time using log file analysis or a monitoring tool set to check critical URLs every few minutes. The most common launch-day failure is a redirect map that was built correctly but was not fully implemented on the server — so some old URLs 404 instead of redirecting. I also check that canonical tags on the new site are self-referencing and correct, that robots.txt is not set to disallow and was not accidentally copied from a staging environment, and that Google Search Console is updated with the new domain property if the domain changed.

Three things that must be verified within the first hour after going live:

  • Robots.txt is accessible and does not contain Disallow: / from the staging config
  • A sample of the highest-traffic old URLs return 301 responses pointing to the correct new destinations
  • The new XML sitemap is submitted to Search Console under the new property

How to Diagnose Post-Migration Traffic Drops

A temporary traffic drop in the first two to four weeks after a migration is normal — Google is reprocessing the redirect signals and building confidence in the new URL structure. A drop that does not recover or that continues declining after week four is a signal that something went wrong during implementation. I work through the diagnosis in a fixed order:

  • Check redirect coverage: pull a crawl of the old domain and verify each URL returns a 301 (not a 404, 302, or 200)
  • Verify canonicalization: confirm new pages have self-referencing canonicals and are not accidentally pointing back to old URLs
  • Check for accidental noindex: crawl the new site for noindex meta tags and X-Robots-Tag headers at the page and template level
  • Review Search Console crawl stats: a sharp drop in Googlebot crawl activity is a sign of a robots.txt or crawlability issue

Recovery When Things Go Wrong

If traffic drops sharply and does not recover within two to four weeks, the first thing I investigate is redirect implementation. Missing redirects, redirect chains, and redirect loops are the most common culprits. The second area is canonicalization: new platforms sometimes generate unexpected canonical tags or serve content under multiple URL patterns. The third area is crawlability: a noindex tag or robots.txt disallow from the old staging configuration that was not removed before launch.

One real example: a client migrated from an old CMS to WordPress and saw a 60 percent drop in organic traffic. The issue was that the new WordPress install had generated paginated URL variants for every category page (/category/page/2/, etc.) that were canonicalized to themselves rather than to the main category page. Google was splitting indexation signals across dozens of low-value pagination URLs per category instead of consolidating them. Fixing the canonical template resolved the issue within about six weeks.

Search Console Change of Address Tool

When a migration involves a full domain change, Google provides a Change of Address tool inside Search Console that formally notifies Google of the move. It is not a substitute for 301 redirects — redirects are still required — but it accelerates the process of Google recognizing the new domain as the canonical home for your content. The tool requires that you verify ownership of both the old and new domain in Search Console before submitting. I typically submit the change of address notification within the first 24 hours after a domain migration goes live, once I have confirmed the redirects are resolving correctly.

The notification stays active for approximately 180 days. During that window, Google uses it as an additional signal alongside the redirect chain. After the period expires, the redirects alone carry the signal, which is why it is important that the 301 redirect map remains in place indefinitely — removing redirects too early is a common cause of traffic loss six to twelve months after a migration.

Migration audits almost always benefit from reviewing server logs directly. Log file analysis shows exactly which URLs Google is crawling, how often, and what status codes they are returning — which is often more revealing than any crawl tool output. If you want both covered in one engagement, a website audit is where to start.