Migrating a WordPress/Woo site without losing your Google rankings

Last reviewed: 21 July 2026

Most "we lost all our rankings after the WordPress rebuild" disasters come down to a handful of redirect and indexing mistakes, every one of them avoidable if you get the URLs right before you flip the switch.

Map every old URL to its new home, with single-hop 301s

If URLs are changing, every important old URL needs a 301 (permanent) redirect to its closest new equivalent. Two rules:

One hop, not a chain. Redirect the old URL straight to the final destination. A chain, old to interim to final, bleeds ranking signal at every step and slows the page down. If you already have old redirects, repoint them at the new final URL directly rather than stacking a fresh one on top.
Match intent, not just the home page. Send a product to the matching product and a blog post to the matching post. Dumping everything on the home page tells Google the old pages are gone and you lose their rankings, and a redirect to an irrelevant page gets treated as a soft 404.

The LiteSpeed redirect gotcha

If your host runs LiteSpeed (a lot of WordPress and Woo hosts do), the standard Apache redirect trick can silently do nothing. The usual loop-guard people copy from Apache examples, a RewriteCond that checks the requested URI, behaves differently under LiteSpeed and can stop the rule matching at all. The reliable pattern on LiteSpeed is to condition on the raw request line instead:

RewriteCond %{THE_REQUEST} \s/old-path[\s?] [NC]
RewriteRule ^old-path$ /new-path/ [R=301,L]

%{THE_REQUEST} matches the original request the browser sent, which sidesteps the loop and fires reliably. If your redirects "work in the plugin" but you still land on the old URL, test them with curl and read the actual response header, do not trust the plugin's word for it. (Test the exact rule against your own host and LiteSpeed version, the syntax varies.)

Do not 301 a URL that is already ranking well

Counterintuitive, but it matters: if an old URL ranks well and you are keeping the content, do not redirect it away just to tidy up your URL structure. A 301 is a small risk every single time. Where two URLs serve the same content and one is the strong performer, point a canonical tag from the weaker one at the strong one to consolidate the signals, and leave the ranking URL live. Move URLs when you have to, not for neatness. We go deeper on that trade-off in canonical vs 301 when two pages rank for the same search.

Watch for two fighting robots tags

A classic post-migration killer: two plugins emitting conflicting robots directives. A "maintenance" or noindex plugin left switched on emits noindex, while your SEO plugin emits index, and the page ships both. At best it is ambiguous; at worst Google honours the noindex and drops the page. After launch, view source on your key pages and confirm there is exactly one robots meta tag, and it reads index,follow. Also check the new site did not inherit WordPress's site-wide "Discourage search engines from indexing this site" setting from staging.

Verify in Search Console for a few days after

Launch is not the finish line. For the first week:

Submit the new XML sitemap in Google Search Console.
Run the URL Inspection tool on a handful of important pages to confirm they are indexable and each redirect resolves in a single hop.
Watch the Pages / Coverage report for a spike in errors, and Crawl Stats for a rash of 404s.
Keep an eye on impressions and average position for a couple of weeks: a brief wobble is normal; a cliff means a redirect or robots problem to fix now, not later.

Once the migration is clean, it is worth a proper speed pass on the new build: see how to improve PageSpeed on WordPress.

The short version: map every old URL to its closest new page with single-hop 301s (never chains). On LiteSpeed hosts, condition the redirect on %{THE_REQUEST}, the usual Apache loop-guard is a no-op there. Do not redirect a URL that is already ranking; use a canonical to keep its equity. Confirm every key page ships exactly one robots tag and it says index. Then watch Search Console for a few days and fix any 404 or coverage spike straight away.

General guidance: redirect syntax varies by host and server; test on staging and confirm against your host's documentation before go-live.