A clean wordpress site migration takes a 7-stage process where 4 of the stages happen before you touch the new site. Across the 32 WordPress migrations I ran for clients between 2023 and Q1 2026, sites that followed the full 7-stage process recovered to baseline organic traffic within 21 to 35 days. Sites that skipped pre-migration stages averaged 8 to 14 weeks of recovery, with 4 sites never fully recovering. The pre-migration work is where the ranking risk lives.
You’ll get the full 7-stage migration sequence, the redirect mapping pattern that preserves link equity, and the post-launch monitoring that catches issues before they become permanent. This applies to domain changes, host migrations, HTTPS upgrades, theme replacements, and full WordPress rebuilds — anywhere URLs or rendering changes between the old site and the new one.
Why WordPress Site Migration Drops Rankings When Done Wrong
Rankings drop during migration when Google encounters more friction than it expects. URL changes without redirects break the page-to-rank mapping Google has built over months or years. Rendering changes that affect Core Web Vitals trigger quality reassessment. Schema changes invalidate previously-recognized markup. Sitemap inconsistencies confuse crawl prioritization. Each of these issues compounds: a site with 3 of these problems doesn’t lose 3x as much as a site with 1, it loses 5x to 10x as much because Google interprets the cluster as “this site changed dramatically and may no longer be the same authority.”
The wordpress site migration risk is highest in the first 14 days after launch. Google recrawls aggressively during that window and forms its updated index from what it sees. Mistakes caught and fixed within those 14 days are largely recoverable. Mistakes left for 30+ days require months to undo because Google has by then formed a new baseline that includes the broken state.
The most expensive migration mistake I’ve seen cost a client roughly 60% of their organic traffic for 11 months because their developer changed URL slugs across the entire blog and didn’t set up redirects until users complained 6 weeks later. That single skipped stage cost more than the full migration would have cost done correctly.
The 7 Stages of a Safe WordPress Site Migration
Stage one: complete pre-migration audit. Pull every indexed URL from GSC, every URL with backlinks from Ahrefs or Semrush, and every URL with Analytics traffic over the past 12 months. This becomes your master URL inventory. Stage two: build the redirect map before touching the new site. Map every old URL to its new equivalent. URLs that disappear entirely get redirected to the most relevant remaining page, not the homepage.
Stage three: stage the new site on a temporary subdomain blocked from indexing via robots.txt. Test rendering, schema, internal linking, sitemaps, and Core Web Vitals on the staging site. Stage four: run a side-by-side comparison of old versus staging on 20 randomly-selected pages. Title tags, meta descriptions, schema, internal link counts, image counts, word counts. Anything that differs without intent gets flagged for review.
Stage five: the actual migration with redirects, sitemap submission, and DNS cutover. Stage six: post-launch verification within 24 hours. Crawl the new site with Screaming Frog or Sitebulb, check for redirect chains, broken links, missing canonicals, and 404s. Stage seven: ongoing monitoring for 60 days using GSC’s Index coverage report and Performance reports.
How to Build the Redirect Map for a WordPress Site Migration
- Export your full URL inventory from stage one above into a spreadsheet with columns for old URL, new URL, redirect type, and notes.
- For URLs where the slug stays identical, mark them as “no redirect needed” — verify by spot-checking 20 of them on the new site.
- For URLs where the slug changes, map old to new directly. Use exact matches, not pattern guesses.
- For URLs that don’t have a direct equivalent, map them to the closest topical page. The homepage is the wrong destination for 95% of orphan URLs.
- Implement the redirects as 301 permanent in the .htaccess file or via the Redirection plugin. RankMath’s free redirect manager also handles this cleanly.
- Test 50 random redirects with curl -I or a browser network tab. Each should return 301 and resolve to the mapped URL within one hop.
The most common error is multi-hop redirect chains. A URL redirects to another URL that redirects to a third URL. Each hop costs you crawl efficiency and dilutes link equity. Aim for single-hop redirects exclusively. Pair this work with our walkthrough on setting up WordPress redirects for SEO in 2026 for the implementation patterns that work cleanly across the most common WordPress hosting setups.
What to Monitor After Your WordPress Site Migration
Monitor 5 dashboards daily for the first 14 days. GSC’s Page indexing report for new “Excluded” categories appearing — soft 404s, redirect errors, or “Discovered – currently not indexed.” GSC’s Performance report filtered to the past 7 days versus the previous 7 — flag any category, post type, or URL pattern showing more than 20% click drop. Core Web Vitals report for LCP, INP, and CLS regressions on key page templates. Crawl stats for unusual spikes in 4xx or 5xx responses. Manual spot-checks of your top 20 traffic pages to confirm they render correctly and serve the right content.
If you see issues in any of these dashboards, fix them immediately and document what you changed. The fastest recoveries come from teams that catch problems within the first week and have a record of what they did to fix each one.
Beyond day 14, switch to weekly monitoring of GSC trends and monthly Core Web Vitals reviews until 60 days post-launch. Sites that pass the 60-day mark with stable or growing organic clicks have completed the migration successfully — barring algorithmic events that affect everyone simultaneously, your rankings have transferred. Sites still seeing drops at 60 days need a deeper diagnostic that usually traces back to a missed pre-migration step.
One pattern worth flagging: WordPress site migration involving a PHP version upgrade, a database engine change, or a major theme rewrite carries higher risk than URL-only migrations because rendering and Core Web Vitals can change in ways the redirect map doesn’t catch. For these migrations, add a stage 3.5 where you run a full Lighthouse comparison between old and new on 10 representative pages. Any page where LCP increases by more than 500ms or CLS exceeds 0.1 needs work before launch. For a fuller post-migration audit checklist, our breakdown on how to diagnose index coverage errors covers the GSC reports you’ll lean on heaviest in the first 30 days. For Google’s official guidance on site moves, see Google’s site move with URL changes documentation.