Migrating a WooCommerce Store Without Losing Orders or SEO
Moving a WooCommerce store to a new host or domain is risky. Here is how I plan a migration so that no order goes missing, every URL keeps working, and payments, emails and rankings carry over to the new server.
A store owner moves to a faster host on a Friday night. By Monday, three customers are asking where their orders went, Google Search Console is full of 404 errors, and Stripe is still sending payment notifications to the old server.
None of that is bad luck. A WooCommerce store is not a brochure site. It takes orders all day, it talks to payment gateways, and it has years of URLs that Google has already ranked. Copying the files and the database is the easy part.
This post explains how I plan a WooCommerce migration so that no order goes missing and the rankings stay where they are.
What Counts as a Migration
The same risks apply to several different jobs:
- Moving to a new host, with the same domain.
- Changing the domain, for example after a rebrand.
- Moving from HTTP to HTTPS, or from www to non-www.
- Pushing a rebuilt site from staging to live.
- Moving from another platform, such as Shopify, to WooCommerce.
A host move with the same domain and URLs is the lowest risk. A domain change, or a platform change where every URL is different, needs the most care for SEO.
The Two Things You Can Lose
Orders. You copy the database at 10:00. The new server goes live at 14:00. Every order placed on the old server in those four hours exists only on the old server. When DNS switches, those orders disappear from your admin, even though the customers have paid.
Rankings. Google ranks individual URLs. If /product/blue-shirt/ becomes /shop/blue-shirt/ and nothing redirects it, Google sees a page that vanished. Rankings, backlinks and traffic for that page go with it.
Everything below is about protecting those two things.
Step 1: Record What You Have Before You Touch Anything
You can't check a migration against a site you never measured. Before you start, save:
- A full list of URLs. Crawl the site with a tool like Screaming Frog, and download the XML sitemaps. Include products, categories, tags, pages, blog posts and images.
- Your top pages from Search Console. Export the pages report for the last 3 to 6 months. These pages must work perfectly on day one.
- Counts. Number of orders, customers, products, coupons and active subscriptions. You will compare these after the move.
- The current setup. PHP version, active plugins, permalink settings, cron jobs, and any custom code in the theme.
- Every integration. Payment gateways, shipping services, email delivery, ERP or stock sync, and marketing tools. Note where each one sends data back to your site.
Then take a full backup of the files and the database, and download it somewhere off the server.
Step 2: Build and Test the New Server First
Set up the new server and copy the site to it while the old site keeps running normally. Test it with a temporary URL or by editing your own computer's hosts file, so that only you see the new server.
Match the PHP version at first, even if you plan to upgrade later. Changing the host and the PHP version on the same day makes problems much harder to trace.
If the domain is changing, update the URLs in the database with WP-CLI. It handles the serialized data that WordPress and WooCommerce store in many options. A plain find and replace in a SQL file breaks that data.
wp search-replace 'https://oldstore.com' 'https://newstore.com' --all-tables --precise --dry-runCheck the dry run report, then run it again without --dry-run.
On the test copy, go through the whole shop: browse, search, add to cart, apply a coupon, check shipping rates, log in as a customer and view past orders. Fix problems now, while nobody is relying on this server.
Step 3: Plan the Cutover So No Orders Are Lost
There are two ways to deal with orders placed during the move.
| Approach | How it works | Best for |
|---|---|---|
| Short order freeze | Pause checkout on the old site, take a final copy of the database, switch DNS, then reopen checkout on the new site | Most stores. It is simple and safe. |
| Delta sync | Keep selling, then copy only the orders placed since the first copy onto the new server | High-volume stores that can't pause checkout even briefly |
For most stores I recommend the freeze. Choose the quietest hour from your analytics, and show a short notice such as "Checkout is paused for maintenance, back in 30 minutes". Customers can still browse. A 30 minute pause costs far less than lost or duplicated orders.
A delta sync is possible, but it needs care. An order is not one row. It is spread across several tables: the order itself, its items and item meta, notes, addresses, the customer record and lookup tables. If the new site has already created its own test orders, the IDs can clash. Never move orders with a CSV export and import. That loses the links between orders, customers, refunds and subscriptions.
Also check which order storage your store uses. Newer stores use High-Performance Order Storage (HPOS), which keeps orders in their own wc_orders tables instead of the posts table. Any order copy must include the right tables for your setup.
Lower the DNS TTL to 5 minutes a day or two before the move, so the switch spreads quickly.
Step 4: Keep Every URL Working
The safest SEO plan is to keep every URL exactly the same. If you are only changing host, that means keeping the same permalink settings, product base and category base, and nothing more is needed.
If any URLs must change, make a redirect map before launch:
- Redirect one to one. Each old URL should go to the closest new page with a 301 redirect. Old product to new product, old category to new category.
- Don't send everything to the homepage. Google treats mass redirects to the homepage like missing pages, so the rankings are still lost.
- Avoid redirect chains. If a page was already redirected in the past, point the oldest URL straight to the final page.
- Keep the SEO data. Titles, meta descriptions and schema from Yoast or Rank Math live in the database, so they move with it. Check a few product pages to be sure.
- Keep image URLs if you can. Product images often bring traffic from Google Images.
For a domain change, keep the old domain registered and redirecting for at least a year. Then use the Change of Address tool in Search Console.
Step 5: Reconnect Payments, Emails and Integrations
This is where most "the site works but something is wrong" problems come from.
- Payment webhooks. Stripe, PayPal and other gateways send payment confirmations to a webhook URL. If the domain changed, update it. Otherwise orders stay "Pending payment" even though the customer paid.
- Live keys. Staging copies often use test API keys. Make sure the live site has live keys and test mode is off.
- Order emails. Send a test order and check that the customer and the admin both receive the email. A new host may need SMTP set up again, along with SPF and DKIM records for your domain.
- Scheduled tasks. Subscription renewals, stock syncs and abandoned cart emails run through WP-Cron and the Action Scheduler. Set up a real server cron job if the new host needs it, and check that no scheduled actions are stuck.
- Licenses. Premium plugins may need to be activated again on the new domain.
- Caching. If the new host has page caching, make sure cart, checkout and my account are excluded.
Subscription stores need one more check. WooCommerce Subscriptions can detect a site copy and pause automatic payments on the duplicate. That protects you on staging, but on the real live site you must confirm it is set to live so renewals keep charging.
Step 6: Check Everything After Launch
Go through this list straight after DNS switches:
| Check | What you want to see |
|---|---|
| Order, customer and product counts | The same as the counts you saved, plus any new orders |
| A real order with a real payment | Payment completes, the order becomes Processing, and both emails arrive. Refund it afterwards. |
| Your top 20 pages from Search Console | Each loads with a 200 status, or redirects once to the right page |
| Old URLs from the crawl | No 404 errors and no redirect chains |
| Settings, Reading | "Discourage search engines" is not ticked |
| robots.txt and sitemap | Nothing important is blocked, and the sitemap uses the new URLs |
| Search Console | The sitemap is submitted again for the live domain |
The "Discourage search engines" box deserves its own mention. It is usually ticked on staging so the test site stays out of Google. When staging is pushed to live, the setting comes with it, and the whole store slowly drops out of the search results. It is one checkbox, and it is the most common migration mistake I see.
Keep an eye on the Search Console pages report and your 404 log for the next two weeks. A small dip in traffic in the first week is normal while Google crawls the changes. A steady drop means something was missed.
Always Have a Way Back
Don't cancel the old hosting on migration day. Keep it running, unchanged, for at least one or two weeks. If something serious goes wrong, you can point DNS back to it within minutes.
Once the new server has been stable for a while, take one last backup of the old server and only then close it down.
A new host is also a good time to fix speed problems, but do it as a separate step after the move. My post on why a WooCommerce store is slow covers what to look at.
Final Thoughts
A WooCommerce migration goes wrong when it is treated as a file copy. It goes right when you measure the old site first, pause checkout for the final copy, keep or redirect every URL, and reconnect payments and emails before customers notice.
Most of the work happens before the switch. The switch itself should be the boring part.
If you are planning to move your store, or a migration has already left you with missing orders or lost rankings, this is the kind of work I do. Take a look at my services or send me the details through the contact form below.
