Migrating a WordPress Site Without Losing Rankings

• Host change only, same domain and URLs: the lowest risk. Mostly a DNS and configuration exercise.
• Domain change: everything needs redirecting, and you'll need to tell Google about the move.
• URL structure change: the highest-risk kind, because every redirect is a chance to lose a page.
• Redesign with the same URLs: no redirect work, but content and internal linking can change enough to move rankings on their own.
• Several at once: do them in stages if you possibly can. Changing host, domain and URLs simultaneously means you can't diagnose what went wrong.

This is the step that gets skipped and the one you'll wish you had.

• Crawl the entire current site and export every URL with its title, meta description, status code and canonical.
• Export Search Console performance data for the last twelve months — queries, pages, impressions, clicks, average position.
• Export your top landing pages from analytics, and note the traffic level for each.
• Record the current index coverage: how many pages Google actually has.
• Save a copy of robots.txt, the XML sitemaps, and any existing redirect rules.
• Note your Core Web Vitals so you can tell whether the new site is faster or slower.

Every URL that exists now and won't exist afterwards needs a 301 to the closest equivalent page. Not the homepage — the closest equivalent. A bulk redirect to the homepage tells Google the old pages are gone and you lose whatever they had earned.

Work from the crawl export. For each old URL, decide the new one. Where there's genuinely no equivalent, decide deliberately between redirecting to a relevant category and returning a 410, and record why.

Then check the map for chains: A redirecting to B redirecting to C. Collapse them so every old URL points straight at its final destination in one hop. Chains lose a little at each step and slow every visitor who follows them.

Test the map before launch. A spreadsheet of a thousand redirects contains typos, and finding them afterwards means finding them via lost traffic.

• Keep the staging site noindexed and behind HTTP authentication until launch. A staging copy indexed alongside the live site is the most common self-inflicted migration wound.
• Make sure the new site's robots.txt is the production one, not the development one that blocks everything.
• Check that Settings → Reading → 'Discourage search engines' is unticked before going live, and ticked while staging.
• Carry over titles, meta descriptions and canonical tags. A redesign that regenerates all titles from a template loses the ones that were written deliberately.
• Preserve the content. Trimming copy during a redesign is a content change and a migration at the same time, and you won't be able to tell which one moved the rankings.
• Keep the internal linking structure at least as good as it was. Navigation changes alone can shift what ranks.

• Lower the DNS TTL a day or two in advance so the switch propagates quickly and you can roll back fast.
• Go live, then immediately verify: HTTPS works, the canonical version redirects correctly, robots.txt is right, and a sample of redirects resolve in one hop.
• Submit the new XML sitemap in Search Console. Keep the old sitemap available for a while so Google can find the old URLs and follow their redirects.
• For a domain change, use the Change of Address tool in Search Console, and verify the new domain there first.
• Check that analytics and tag manager are firing on the new site. A migration that also silently breaks tracking is very hard to evaluate.
• Crawl the new site immediately and look for 404s, redirect chains, missing titles and broken internal links.

Expect a dip. Google has to recrawl everything, follow the redirects and reassess. A drop of some size in the first fortnight is normal even on a well-executed migration, and panicking into further changes makes diagnosis impossible.

• Watch Search Console's Pages report for a rise in 404s or 'redirect error' entries.
• Watch crawl stats — a big spike is normal and healthy as Google reprocesses the site.
• Check the top twenty landing pages from your baseline specifically, rather than only aggregate traffic.
• Fix 404s as they appear. Every one is a redirect you missed.
• Resist making unrelated changes. You want one variable.

Redirects preserve most of the value of an external link, but they're a fallback, not a plan. Where you can get a link updated, do.

Start with the ones you control: your social profiles, your Google Business Profile, directory listings, email signatures, printed material. Then contact the handful of highest-value external sites linking to you and ask them to update.

This matters most for a domain change. For a URL structure change on the same domain, the redirects do most of the work.

• Redirects done in bulk to the homepage instead of page by page.
• The development robots.txt or a leftover noindex shipping to production.
• The staging site left indexable and competing with the live one.
• Content substantially rewritten or trimmed at the same time as the move.
• Internal linking quietly degraded by a new navigation with fewer links.
• A slower new site, pushing Core Web Vitals from passing to failing.
• Giving up too early and reverting half of it after a week, leaving the site in a state nobody understands.

Six to eight weeks. Before that you're looking at Google's recrawl in progress, not at the outcome. Compare against the baseline you exported, page by page for the pages that mattered.

If traffic hasn't recovered by then, the crawl data will usually tell you why: 404s that should be redirects, pages excluded for a canonical pointing somewhere unexpected, or a set of URLs that never made it into the new sitemap.