Migrating a WordPress Site Without Losing a Single Ranking

Every migration is a controlled risk — a domain change, a platform move, or a full redesign all carry the same underlying danger: breaking the URL-to-ranking relationship Google has built up over months or years. I've taken over recovery work on migrations that lost 60-70% of organic traffic in a week, and in almost every case the cause wasn't the new site itself, it was a missing step in the handover.

Why Migrations Fail More Often Than They Should

Most failed migrations aren't caused by exotic technical mistakes. They're caused by treating the migration as a design or development project with SEO added at the end, instead of an SEO project that happens to involve a new design. By the time someone checks whether the old URLs redirect correctly, the old site is already offline and the mapping has to be reconstructed from memory or a stale crawl.

This is the same discipline problem I see in faceted navigation cleanups — it's not that the fix is hard, it's that nobody owns the checklist end-to-end. A migration needs one person accountable for every redirect, not a shared assumption that "someone" is handling it.

Before Anything Moves: Building the URL Inventory

The first thing I do on any migration — weeks before launch — is crawl the live site and export every indexed URL, cross-referenced against Search Console's coverage report and the last twelve months of analytics landing pages. This becomes the migration's source of truth. Any URL that has ever earned an impression, a click, or a backlink goes into the mapping sheet, not just the URLs someone remembers are important.

• Full crawl export from a tool like Screaming Frog, capturing every indexed and non-indexed URL
• Search Console coverage and performance reports, exported and merged against the crawl
• Top linked pages from an external backlink tool, so high-authority URLs never get missed
• Analytics landing pages from the past 12 months, to catch seasonal or campaign pages the crawl might undervalue

Mapping Every Old URL to Its New Home

Once the inventory exists, every single URL gets a 1:1 mapping to its new destination — not a blanket redirect to the homepage, which is the single most damaging shortcut I see teams take under launch-day pressure. A blanket homepage redirect tells Google the old content no longer exists anywhere, which resets relevance signals instead of transferring them.

Where a like-for-like page doesn't exist on the new site — a discontinued product, a merged category — I redirect to the closest topical match, not just the nearest URL structurally. This is especially important for ecommerce migrations, where category and filter URLs multiply fast and each one needs a deliberate decision, not a default rule.

Launch Day: The Sequence I Follow

• Deploy the new site to the live domain during the lowest-traffic window, with the redirect map already live in the web server config, not queued for a later update
• Verify a sample of at least 50 high-priority redirects manually, checking status codes directly rather than trusting a visual page load
• Submit the new XML sitemap in Search Console and request indexing on the top 20 highest-value URLs
• Update internal links across the site to point directly at final destination URLs, avoiding redirect chains
• Confirm canonical tags, hreflang (if applicable), and structured data all reference the new domain or URL structure correctly

The First 30 Days: What I Actually Monitor

Traffic dips of 5-15% in the first one to two weeks are normal even on a clean migration, simply because Google needs to re-crawl and re-evaluate the new URLs. What I watch closely is the shape of the dip, not just the size: a broad, gradual recovery across most pages is expected, while a sharp, sustained drop concentrated in a handful of previously top-performing pages usually means a specific redirect or canonical error, not a normal transition. I check Search Console's coverage report daily for the first two weeks, specifically for spikes in "Page with redirect" or "Not found (404)" errors that weren't in the pre-launch baseline.

Common Mistakes I Still See on Client Handovers

• Redirecting HTTP to HTTPS and old-domain-to-new-domain in two separate hops instead of one direct redirect, doubling load time and diluting link equity
• Leaving staging environment noindex tags active on the live site after launch — the single most common cause of a migration disappearing from search entirely
• Forgetting XML sitemaps, robots.txt, and any hardcoded canonical tags still referencing the old domain
• Changing URL slugs at the same time as the domain or platform, which makes it impossible to isolate which change caused a ranking shift if something goes wrong

How This Connects to Everything Else

A migration is also the moment technical debt either gets fixed or gets carried forward permanently, so I use it as a checkpoint against the same Core Web Vitals issues I'd audit on any site, and I make sure any location or service pages still match the Google Business Profile categories and service areas exactly. Increasingly, I also check that migrated content still reads clearly for AI answer engines, since a redesign often changes heading structure in ways that quietly break the answer-first formatting covered in Structuring Content So AI Search Engines Can Actually Use It.

If You're Planning One

The single biggest predictor of a clean migration isn't technical complexity, it's lead time — the teams that start the URL inventory a month before launch almost never lose meaningful traffic, and the teams that start it the week of launch almost always do. If you have a migration coming up, get in touch through the contact page with your current site and target launch date, and I'll map out what the redirect plan needs to cover before anything moves.