WooCommerce to Shopify Migration Without Losing SEO or Revenue

We build and run Shopify stacks for a living, which means a WooCommerce to Shopify migration shows up on our desk on a regular basis.

Every one of them has a build side that gets scoped properly: the theme and the design system, the catalog and its data mapping, the apps that have to replace your plugins, payments, shipping, tax, and the QA pass over all of it. That work is real, and it’s most of the hours.

Running underneath it is a second workstream that rarely appears on the project plan: everything that has to survive the WooCommerce to Shopify migration. Your URLs and the rankings attached to them. Your review corpus and the stars it puts in the search results. Your Merchant Center matching.

Your analytics history. Your customer accounts. None of it is technically hard. All of it fails quietly.

The build side of a WooCommerce to Shopify migration has an owner and a launch date. The preservation work usually has neither, which is why it tends to get discovered after cutover instead of before. The order below is roughly the order it should get done in.

Shopify’s storefront paths aren’t configurable. You can’t edit the subdirectory names (opens in new tab), such as /collections, /products, and /pages, and they stay the same regardless of what domain you’re using. A product’s address on Shopify is always /products/ plus a handle, and that subdirectory name isn’t editable.

WooCommerce, by default, doesn’t use that structure. Its default product base (opens in new tab) is product, producing URLs like example.com/product/hoodie-with-logo, and its default category base is product-category. Some stores run a “Shop base” permalink instead, which puts products at example.com/shop/hoodie-with-logo, or a fully custom base. None of those match Shopify’s fixed structure, so no WooCommerce URL survives the migration unmapped.

Can I keep my old URLs on Shopify? No. Shopify’s subdirectory names are fixed regardless of what domain you’re using, so every product and category URL changes by definition. Every URL needs a redirect, not a preserved path.

Is a WordPress to Shopify migration the same thing? Nearly, and the difference is worth scoping. WooCommerce is a WordPress plugin, so a WooCommerce to Shopify migration is a WordPress to Shopify migration plus a product catalog, a customer list, and an order history. If you’re on WordPress without WooCommerce, everything here about blog paths, category and tag archives, author archives, attachment pages, and Yoast or Rank Math metadata still applies, and you can skip the catalog, discount, and subscription sections entirely.

Because every URL changes, a WooCommerce to Shopify migration is what Google calls a site move with URL changes (opens in new tab), not the much gentler site move with no URL changes that applies when you’re only changing hosting. Every product page, every category page, and depending on your permalink settings, potentially your entire blog changes address on the same day. Google notes that a platform like Blogger or Shopify may already have built-in redirect solutions (opens in new tab).

The non-negotiables of a safe platform move apply to any platform pair.

Not on WooCommerce? We handle migrations from Wix and Squarespace migrations as their own projects.

The alarming figures that circulate about a WooCommerce to Shopify migration, a percentage of SEO value lost, a share of migrations that fail outright, a recovery window measured in months, trace back to agency landing pages and listicles with no underlying study, no sample, and no method attached. If a migration-loss percentage shows up in a sales conversation, ask where it came from.

Google says a small to medium-sized website can take a few weeks for most pages to move in its index (opens in new tab), and that larger sites can take longer. It gives no month figure, and there’s no official multi-month recovery figure.

Google’s guidance is to expect temporary fluctuation in site ranking during the move:

On link equity, Google’s position is that 301 and other permanent redirects don’t cause a loss in PageRank (opens in new tab). That directly contradicts the widely repeated claim that redirect chains cost you a fixed percentage of link equity per hop.

Google tells you to expect ranking fluctuation while it recrawls and reindexes a moved site, and says most pages on a small to medium-sized site can take a few weeks to move in its index. Google says permanent redirects don’t cost you link equity. Nobody has published a credible number for what a botched WooCommerce to Shopify migration specifically costs, which leaves execution as the variable you actually control.

You can’t prove what a WooCommerce to Shopify migration cost you if you never recorded what you had. Skip it and every post-launch traffic conversation becomes an argument with no evidence in it.

Shopify’s own Core Web Vitals reporting has a short memory. The web performance report is built from real user data, covers only the last 90 days (opens in new tab), and might be delayed by up to 36 hours. The pre-migration state of your WooCommerce store lives nowhere Shopify will show you after cutover, so you have to capture it deliberately, before you move.

The same problem exists on the Google side. Search Console’s Core Web Vitals report pulls from the Chrome UX Report, and only indexed URLs can appear in it (opens in new tab).

CrUX is a rolling field dataset tied to specific, already-indexed URLs. The moment your URLs change, that URL-level history doesn’t transfer. Your new Shopify URLs start with no field data of their own, regardless of how fast the new store actually loads.

That’s why a real pre-migration baseline is three things, captured before staging even begins: a full crawl and indexed-URL inventory of the live Woo site, a Core Web Vitals snapshot at the field-data thresholds Google actually uses (LCP within 2.5 seconds, INP at 200 milliseconds or less, CLS at 0.1 or less, all measured at the 75th percentile (opens in new tab)), and a ranking and revenue-by-landing-page export.

A technical SEO audit is exactly this kind of exercise, and a Core Web Vitals benchmark run before the build starts is the difference between having a before-and-after and having only an after.

A WooCommerce to Shopify migration needs 301 redirects, and one Shopify rule breaks the naive version of the map: you can redirect only from broken URLs (opens in new tab), the ones that display an error message such as Page not found or 404. If a source path still resolves to something on the new store, whether by coincidence or because a theme or app is serving content there, it isn’t broken, so the redirect you set up for it never fires. This is the single biggest way a WooCommerce to Shopify redirect map fails silently.

Depending on your WooCommerce configuration, a Shopify migration means mapping several distinct patterns, not just products:

The /shop/ page is one of four pages WooCommerce creates on install (opens in new tab), distinct from the category archives. The category and tag bases are ones you can’t remove from the URLs altogether (opens in new tab), and attachment pages exist because WordPress automatically generates a new web page, containing only that image (opens in new tab), for every upload.

What happens to my blog? Blog content has no CSV import path on Shopify, only apps or the Blog API, and your post URLs move from WordPress’s date or category-based structure to Shopify’s blog path format. Both the content transfer and the redirect map need separate planning from the product catalog.

Variation URLs deserve a separate note. A WooCommerce product variation doesn’t get its own clean path.

WooCommerce’s WC_Product_Variation::get_permalink() is a wrapper that adds the variation’s attributes to the URL (opens in new tab) on top of the parent product’s address. When optional query parameters identify variants, Google recommends using the URL with the query parameter omitted as the canonical URL (opens in new tab). Don’t spend redirect budget mapping variant parameters one to one.

Here’s how a simplified version of that map looks once you’ve built it:

Once the map exists, the mechanics are straightforward. Shopify redirects are 301s, which browsers and search engines cache (opens in new tab), and they’re bulk-importable through a CSV with exactly two columns (opens in new tab), Redirect from and Redirect to. Standard plans cap out at 100,000 redirects (opens in new tab); Plus goes to 20,000,000. A handful of prefixes (opens in new tab) can’t be used as a redirect source at all, including /apps, /cart, /orders, and notably /shop, which happens to be one of WooCommerce’s own permalink base options.

On chains, follow Google’s guidance (opens in new tab) directly rather than your instinct to redirect through a convenient waypoint: “Avoid chaining redirects. While Googlebot can follow up to 10 hops in a ‘chain’ of multiple redirects, we advise redirecting to the final destination directly. If this is not possible, keep the number of redirects in the chain low, ideally no more than 3 and fewer than 5.”

If you run the import through Matrixify, its entry paid tier, at $20 per 30 days, caps out at 10,000 redirects, well below Shopify’s own 100,000-redirect plan ceiling; the $50 per 30 days tier (opens in new tab) reaches the full 100,000. For a mid-catalog Woo store, the redirect count, not the product count, is what pushes you into the higher tier.

Verify the map before and after the WooCommerce to Shopify cutover with a real crawler rather than trusting the CSV import screen. Google suggests Screaming Frog by name (opens in new tab) for crawling your own site. Screaming Frog’s All Redirects report (opens in new tab), run in list mode against your old URL inventory, returns Chain Type, Number of Redirects, Redirect Loop, Temp Redirect in Chain, and Final Status Code for every URL you feed it. That’s how you catch the failure Google names first, redirects to the wrong (non-existent) URLs on the new site, before Googlebot does.

The redirect map alone is a real body of work, before revenue continuity even enters the picture. It’s the discipline that our SEO migration work exists to handle as its own workstream, separate from the store build itself, and it’s a large part of what we cover end to end in a managed WooCommerce to Shopify migration.

This part of a WooCommerce to Shopify migration happens before cutover: controlling what Google can and can’t see while you’re still building.

A Shopify store behind a password is invisible by design. With a password page active, search engines find and display only the password page (opens in new tab) of your online store. Other pages, such as product pages, are hidden and aren’t displayed in search results.

Your sitemap is unreachable under a password too: a sitemap reader can’t access it (opens in new tab) if your website is password protected. That’s good news for avoiding premature indexation of a half-built store, and it comes with a real limitation: you can’t pre-validate how the new store will index before you take the password off.

If you need finer control than the password page gives you, robots.txt is customizable through a robots.txt.liquid template. Shopify treats that as an unsupported customization (opens in new tab): Shopify Support can’t help with edits, and Shopify warns that incorrect changes can cause loss of all traffic.

Noindex isn’t a setting either. It’s a theme edit, pasted as Liquid into theme.liquid (opens in new tab). Neither is something to touch casually, and both are the kind of migration-only change people forget to undo: Google warns site owners to remove any noindex or robots.txt blocks that were only needed for the migration (opens in new tab).

Google’s best post-cutover instrument is the two-sitemap method: submit the two sitemaps you saved from the mapping (opens in new tab), one of old URLs and one of new. Initially, the sitemap containing the new URLs would have zero pages indexed, while the sitemap of the old URLs would have many. Over time the number of pages indexed from the old URLs sitemap would drop to zero, with a corresponding increase in indexing of the new URLs.

Submit both and watch the numbers trade places. That’s your real-time confirmation that Google is treating this as a move, not a disappearance.

Everything above is measurable in Search Console. The losses below aren’t. They show up in a P&L, weeks later, and they’re the ones a launch checklist is worst at catching.

Passwords are encrypted outside of Shopify, so you can’t migrate customer passwords from another online store using a CSV (opens in new tab). You need to invite your customers to create new passwords so that they can register their accounts, and that affects every customer account you have. Treat this as an email deliverability event, not a footnote: every returning customer needs a reset email that lands, gets opened, and doesn’t read like a phishing attempt.

You can’t export or migrate reviews from WooCommerce to Shopify (opens in new tab). That describes native WooCommerce reviews rather than the third-party review platform most real stores actually run. What matters for those stores is what happens when a purpose-built review app has to re-match its corpus to a completely new set of product IDs.

The first place that re-matching breaks is product identity, and it’s the one that costs the most because it fails silently. Stamped requires platform-generated product IDs, not SKUs, handles, or URLs (opens in new tab), and its reviews can’t be migrated without a valid product ID mapping. On Judge.me, product identifiers differ between WooCommerce and Shopify (opens in new tab), and if a product isn’t mapped in the manual mapping step, its reviews are imported as store reviews instead. On Yotpo, if the Product ID value is empty (opens in new tab), the review is treated as a site review.

The import doesn’t error. It reports success, and the reviews exist somewhere in the account. They just aren’t attached to the product anymore, so the product page shows zero, and nobody notices until a customer asks why the five-star product they remember buying looks unreviewed.

Shopify product IDs are long enough that spreadsheet software silently converts them to scientific notation. Stamped warns that this will lead to the reviews not being assigned to the correct products (opens in new tab), and Junip warns about the same trap (opens in new tab). That’s not a failure to import, it’s a misassignment, which is arguably worse because it looks like it worked.

Loox is the notable exception. It matches primarily on the Shopify product handle (opens in new tab), the last part of the product URL after /products/, which means preserving your product slugs from Woo into Shopify is a review-corpus decision, not just a redirect decision.

REVIEWS.io matches on SKU, which makes unmatched SKUs (opens in new tab) the risk when SKUs drift during a migration. Its imports are only available within the first 90 days of your REVIEWS.io account (opens in new tab) and allow one import per review type. That’s a one-shot window, and getting the SKU mapping wrong the one time you’re allowed to run it isn’t trivially reversible.

The second is verified-buyer status, and it has a real downstream cost. Reviews imported from your Judge.me account on WooCommerce won’t be verified in your Judge.me account on Shopify (opens in new tab), and imported reviews won’t appear in your Google Shopping product reviews feed. Google Merchant Center requires a 50-review minimum across all of your products (opens in new tab) to display product ratings at all.

A store that migrates its entire review corpus can keep every star on its own product pages and still fall below the 50-review floor in Merchant Center, losing star ratings in Google Shopping entirely, and quietly.

The third is theme-resident structured data, and it’s the easiest to forget because it isn’t stored in the review app at all. Okendo’s widgets require an App Embed toggle turned on in the Shopify theme customizer (opens in new tab), and without it the widget won’t appear. On Judge.me, a theme overwriting or blocking the product schema is a known cause of missing rich snippets (opens in new tab), and the review widget has to be installed on the product page.

Google’s rule for review markup is unforgiving on this point: “It must be immediately obvious to users that the page has review content,” and if you marked up reviews, users should be able to see the text of the review and associated rating (opens in new tab). A new theme is guaranteed on a WooCommerce to Shopify migration, so reinstalling the widget and re-verifying the schema isn’t optional cleanup. It’s how you avoid shipping structured data that claims a rating your page no longer displays.

Judge.me has sunset its app on all non-Shopify platforms (opens in new tab). Its WooCommerce sunset date was 31 October 2025, with access until 19 November, and Judge.me says that after the date access to all Judge.me functionalities and data will be permanently removed. Judge.me reviews can no longer be exported from the WooCommerce admin, and Judge.me’s support team runs the export on request. Export your review corpus early and independently, before you need it, not on migration day.

Cart2Cart advertises migrating (opens in new tab) “products, customers, orders, reviews, and more,” while Shopify’s position is that reviews can’t be migrated from WooCommerce. Test Cart2Cart’s claim before you trust it with your corpus.

Merchant Center’s matching logic prefers GTINs first (opens in new tab), and falls back to SKU, Brand plus MPN (Manufacturer Part Number) pairs, and product URLs when a GTIN isn’t available. Those fallbacks generally don’t offer as good a match as GTINs, which can lead to reviews not being matched to products. A WooCommerce to Shopify migration changes every product URL by definition, which resets one of those three fallback signals.

Google also requires that the domains in the product_url of the review data source match the registered domain in your Merchant Center account (opens in new tab), which matters directly if your Shopify move also touches your domain or subdomain structure.

Shopify has a self-referral problem that’s the direct analog of the old PayPal-referral bug WooCommerce stores know well: if a customer enters the checkout and then returns to your online store to continue shopping, the checkout page might be listed as a source. Shopify recommends excluding your store’s primary domain, checkout.shopify.com, shop.app, and external payment providers (opens in new tab) such as paypal.com.

The shop.app entry is new to you, because Woo stores never had it as a self-referral source. It’s worth adding to your exclusion list on day one rather than discovering three weeks of inflated referral traffic that’s actually your own checkout.

Migration isn’t only an SEO event, it’s a revenue event, and it’s worth modeling what the underlying performance work is actually worth in your funnel rather than treating any of this as a cost center to minimize.

Most stores don’t. For the ones that do, this is the largest single thing that can go wrong on cutover day. A subscription agreement is linked to a product, a customer, a payment gateway and potentially one or many orders, so migrating a subscription can be rather difficult (opens in new tab). The asset that has to move isn’t the card number, it’s the token: WooCommerce Subscriptions needs customer payment method data, like a credit card token (opens in new tab), to link the subscription with the payment gateway.

When WooCommerce is the platform importing subscriptions and the tokens can’t move, its fallback is to create the subscription with an invalid customer token for a valid payment gateway (opens in new tab), so that the first renewal payment after the import will fail and the failed payment handling process is initiated. The official answer, in other words, is to intentionally break the customer’s next charge and then chase them to fix it.

On the Shopify side, moving actual card numbers is gated behind plan tier: migrating credit card primary account numbers (PANs) (opens in new tab) requires your store to be on the Shopify Plus or Enterprise plan, a plan that starts at $2,300 per month (opens in new tab). For stores that can’t or won’t go to Plus, there’s a slower alternative: as customers update their billing information (opens in new tab), their payment methods move from the secondary gateway to the primary gateway. That’s a real path, and it means your store runs two gateways in parallel until customers re-enter their details, on their card-expiry schedule rather than yours.

If you’re weighing whether Plus is the right target in the first place, especially for a B2B or wholesale operation outgrowing WooCommerce and weighing a Shopify migration, that decision belongs earlier in the process than the migration mechanics covered here.

Some things have no clean path from WooCommerce to Shopify, and knowing that in advance saves a lot of frustration on launch day.

Historical orders reach Shopify only through migration apps, the Order API, or the Transaction API (opens in new tab), and blogs and pages are limited the same way, to apps and their own APIs. On import, any staff member set to receive order notifications will receive a new order email for each imported order. Shopify only allows for 3 product options (opens in new tab), and products with greater than 3 options won’t have their options imported.

WooCommerce supports three coupon types with granular restrictions (opens in new tab) like minimum spend, excluded sale items, and per-user usage limits, while Shopify’s native discounts (opens in new tab) cover amount-off, buy-X-get-Y, and free shipping, with tiered or custom-eligibility logic requiring apps.

Yoast’s settings export (opens in new tab) covers site option groups only, and a per-post CSV of SEO titles and descriptions is a Premium feature. Rank Math’s settings export (opens in new tab) excludes post metadata, and the CSV carrying seo_title, seo_description, canonical_url and schema_data per post is PRO-only. The free core WooCommerce CSV tool covers products, with customers, orders, and coupons requiring the paid Customer / Order / Coupon Export extension (opens in new tab).

Google’s guidance on when to run a WooCommerce to Shopify migration is that small and medium sites should move all URLs on the site simultaneously instead of moving one section at a time (opens in new tab), because it helps Google’s algorithms detect the site move and update its index faster. Don’t stage a partial cutover hoping to de-risk it. If you’re a small or medium site, which covers most WooCommerce stores, a clean single cutover is the lower-risk option, not the higher-risk one.

Pick your window deliberately. Google’s advice is to time your move to coincide with lower traffic, if possible (opens in new tab). If your traffic is seasonal or dips on certain weekdays, it makes sense to move your site during the recurring traffic dips.

Google also warns that after a migration it will crawl your new site more heavily than usual (opens in new tab), and tells you to ensure that your new site has sufficient capacity to handle the increased traffic from Google. On a Shopify destination there’s no server for you to provision, so the practical version of that warning points backward: your old WooCommerce host still has to serve every redirect under a heavier-than-usual post-migration crawl. Don’t downgrade or decommission it on cutover day.

Don’t reach for Search Console’s Change of Address tool. It exists for domain moves only: it can be used only on properties at the domain level (opens in new tab), and you can’t move properties at the path level.

If you’re keeping your domain, which most WooCommerce to Shopify migrations do, this tool doesn’t apply to you. A same-domain WooCommerce to Shopify migration is governed entirely by the redirect map and Google’s site-move guidance.

After the move, Google’s guidance is to monitor the traffic on both the old and new URLs (opens in new tab), verifying every domain and subdomain variant separately in Search Console. Because migrating from WooCommerce to Shopify changes every path shape at once, start that on day one and know what you’re looking for.

The most common post-move failures Google names are a useful checklist to run against your own launch: incorrect redirects, other crawl errors, insufficient server capacity, and not updating sitemaps (opens in new tab). A normal dip looks like fluctuation across many URLs while the index catches up.

Google’s few-weeks figure describes how long it can take most pages to move in the index, not how long your traffic line stays down, and Google publishes no recovery figure at all. You’re watching for direction, not a date. A broken migration looks like a spike in not-found errors in Search Console that doesn’t shrink week over week, or a sitemap of new URLs that never climbs off zero indexed pages while the old sitemap never drops.

Google also recommends keeping your redirects in place for as long as possible, generally at least 1 year (opens in new tab), because that allows Google to transfer all signals to the new URLs, including recrawling and reassigning links on other sites that point to your old URLs. From a user’s perspective, Google says to consider keeping redirects indefinitely. Redirects aren’t a launch-week artifact to clean up later.

How do I actually test that the migration worked? Crawl your old URL list in list mode and confirm every URL resolves to a 301 rather than a 404. Submit both your old and new sitemaps in Search Console and watch indexed counts trade places over the following weeks. Compare your Core Web Vitals field data once there’s enough traffic on the new URLs to be meaningful, against the baseline you captured before you moved.

This is the discipline behind our 90-day post-launch monitoring window: watching indexed-URL counts trade places between the old and new sitemaps, tracking the redirect map for anything silently failing the broken-URL rule, and treating a wide gap between launched and confirmed working as the default assumption rather than the exception. Once the dust settles, the work shifts into ongoing ecommerce SEO: variant URL hygiene, collection page structure, and the duplicate-content questions a new platform introduces that the old one never had.

If your rankings have already slipped and it wasn’t from a recent migration, that’s a different problem with a different fix, and we’ve written about what recovery looks like for a site in gradual decline.

Shopify lays out an escalation ladder (opens in new tab) for how complex a WooCommerce migration gets: manual copy and paste, then CSV export and import, then a migration app from the Shopify App Store, then hiring a Shopify Partner, then custom API solutions. Most WooCommerce stores of any real size land somewhere between the third and fourth rung, and the honest answer to “can I do this myself” depends entirely on how many of the items above apply to your store.

If you want to migrate WooCommerce to Shopify yourself, and you run a small catalog, no subscriptions, and native reviews you don’t care much about, the CSV path plus a redirect tool covers most of it, and a competent DIY effort with a crawler and a spreadsheet is realistic. If you’re running a third-party review platform with hundreds of products, active subscriptions, and a Merchant Center feed that matters to your paid budget, you’re weighing every item in the revenue-continuity section above against your own team’s bandwidth to execute all of it correctly, once, with no do-over on the parts that only run one time. That’s the actual decision.

Cost is part of that calculation too. Shopify’s plans are priced like this:

The plan-tier arithmetic on Shopify’s list prices (opens in new tab) is worth doing yourself before you pick a target plan. On Basic, a store that keeps a third-party payment gateway pays a 2% Shopify surcharge on top of whatever that gateway already charges, so on a $60 order that surcharge alone is $1.20 before the gateway’s own cut. Moving to Shopify Payments removes that surcharge but resets your card rate to 2.9% plus 30 cents.

Which is cheaper depends on your gateway’s own rate, so run the comparison against your actual processor before you commit to a plan. WooCommerce hosting has no single list price, so a total-cost-of-ownership comparison between the two platforms needs your own numbers.

What does a WooCommerce to Shopify migration cost? Shopify’s plan pricing starts at $39/mo for Basic, with Plus starting at $2,300/mo for stores that need Plus-only capabilities like card-number migration for subscriptions. Beyond the platform fee, cost depends on catalog size, redirect volume, and whether you’re paying for a migration app tier, a partner, or both. A fair total-cost comparison also needs what your current WooCommerce hosting costs, so it isn’t something anyone can offer without your specific numbers.

What tends to tip the decision toward a migration agency rather than a DIY effort isn’t the product export. It’s everything downstream of it: the redirect map at real catalog scale, the review corpus re-matching, the subscription contract recreation, and the monitoring window that catches what the launch checklist can’t. If that’s the shape of your store, have us run the migration end to end rather than discovering those gaps one at a time, after they’ve already cost you something.

None of the work above is the hard part of a WooCommerce to Shopify migration. The theme, the catalog mapping, the app replacements, and the QA are harder, and your build team already knows it owns them. The preservation work is easier and it goes wrong more often, because easy work with no name on it is the work that doesn’t get done.

So give it a name and a date. Capture the baseline before the build starts.

Own the redirect map as a deliverable rather than a launch-day task. Decide who is re-matching the review corpus and who is watching Merchant Center in the weeks after. That’s the entire difference between a WooCommerce to Shopify migration that costs you some ranking fluctuation and one you’re still explaining next quarter.

If your store is small and clean, you now have the method to run this yourself. If it’s carrying real subscription revenue, an established review corpus, and a catalog large enough that the redirect map alone is a serious project, we run WooCommerce to Shopify migrations end to end, revenue-continuity work included. If you want a second opinion on where your current store stands before you commit to a date, start with a free visibility audit.