WooCommerce to Shopify Migration Checklist That Protects SEO

The part of a WooCommerce to Shopify migration that costs you money is not the data. Products, customers and orders move reliably with any of the mainstream migration apps. What costs money is that every URL on your site changes, and the redirect map connecting old to new is the deliverable most migration projects underscope. Get the map right and you take a shallow, recoverable dip. Get it wrong and you rebuild organic revenue from scratch.

This WooCommerce to Shopify migration checklist is sequenced the way we run the work: audit, map, build, verify, launch, watch. The URL and redirect sections are deliberately the longest, because that is where the failures happen.

Phase 1: inventory before you touch anything

You cannot redirect what you have not listed. Before a single product is exported, produce four artefacts and keep them in version control.

A full crawl of the live store. Run a crawler over production and export every URL returning 200, with its title, canonical tag and indexable status. This is your ground truth. Do it before anything changes, because you cannot reproduce it afterwards.

A top-URLs-by-value export. Pull Search Console performance data for the last twelve months at page level, and your analytics revenue-by-landing-page report. Sort by clicks and by revenue. The two lists rarely match and both matter. These URLs get manual verification later; the long tail gets pattern rules.

A backlink export. Any URL with external links pointing at it must redirect to a genuinely equivalent page, even if that page is being retired. Link equity does not survive a redirect to the homepage.

A list of everything WooCommerce does that is not "show products". Bookings, quote forms, wholesale pricing rules, membership gates, custom shipping calculators, subscription logic. Each one is either a Shopify app, a piece of custom development, or a reason to stop the project. Price them now, not in week six.

Phase 2: the URL structure problem

This section decides the outcome. WooCommerce and Shopify do not simply use different URLs, they use different shapes of URL, and a one-to-one mapping is not always possible.

How WooCommerce builds URLs

WooCommerce inherits WordPress permalinks, so the structure varies by installation. Common patterns:

Two details there cause trouble. WordPress adds a trailing slash by default. And nested categories produce a URL depth Shopify has no equivalent for.

How Shopify builds URLs

Shopify's paths are fixed. You choose the handle, not the prefix.

Shopify's URL redirect documentation shows how rigid this is: /products, /collections and /collections/all are listed among the fixed paths you cannot redirect from. No trailing slashes. No nesting beyond one collection level.

The mapping rules fall out like this:

• /product/x/ becomes /products/x — drop the prefix, drop the trailing slash
• /product-category/boots/ becomes /collections/boots
• /product-category/footwear/boots/ becomes /collections/boots, and the parent category becomes either its own flat collection or a navigation-only page
• /product-tag/waterproof/ becomes /collections/all/waterproof or a purpose-built collection, depending on whether the tag page earns traffic
• Anything with a query-string filter maps to the closest collection, handled by a pattern rule

Product handles change more often than you expect

Shopify generates a handle from the product title at creation. If two products resolve to the same handle, Shopify appends a numeric suffix, and now /products/chelsea-boot-1 sits where you expected /products/chelsea-boot. If your WooCommerce slugs were hand-edited over the years, they will not match the generated handles at all.

Export the handles Shopify actually created after the import and diff that against your intended map. Do not build the redirect file from the map you planned. Build it from what exists.

Collection URLs are not category URLs

A WooCommerce category is a taxonomy term with hierarchy. A Shopify collection is a flat list, manual or rule-based. If your category tree is three levels deep and each level ranks, you are flattening a structure Google currently understands. Decide deliberately which levels become collections, which become tag-filtered views, and which stop existing. Every retired level needs a redirect to its nearest surviving ancestor, not to the shop root.

The blog is its own project

Shopify blog URLs carry a blog handle in the path, so /blogs/news/article and /blogs/guides/article are different URLs for the same content if you move an article between blogs. WordPress post categories have no Shopify equivalent; you get tags. If the blog is a genuine content asset driving non-brand traffic, consider leaving it on WordPress rather than flattening a taxonomy that took years to build. That is a WordPress development decision rather than a Shopify one, and it turns on the same question as whether a working WordPress site is worth re-architecting at all.

Phase 3: building the redirect map

The map is a CSV with two columns: old path, new path. Shopify imports it directly through the URL redirects screen, and the documented redirect limits are high enough that catalogue size is rarely the constraint.

Build it in this order.

1. Pattern rules first. Generate the bulk of the map programmatically from your crawl export using the mapping rules above. One script, re-runnable, output committed to the repo.
2. Manual rows for the value list. Every URL from your top-clicks and top-revenue exports gets checked by a human against the actual destination. That is a couple of hours of work and the highest-leverage couple of hours in the project.
3. Backlinked URLs next. Same treatment.
4. Discontinued products. Redirect to the parent collection, or to a genuine replacement product if one exists. If a product is gone for good with no equivalent, letting it 404 or 410 is more honest than dumping the visitor into a collection they did not ask for.
5. Everything else. A catch-all to the homepage is a last resort for URLs with no traffic, no links and no equivalent. It should cover a small fraction of the map, not half of it.

Two rules worth arguing about with whoever runs the project:

• Never chain redirects. If /old/ already redirects to /older/ on WooCommerce, the new map should point /old/ straight at the final Shopify URL. Chains dilute and occasionally break.
• Keep the redirects. Google's site move with URL changes guidance recommends permanent redirects and says to "keep the redirects for as long as possible, generally at least 1 year". On Shopify that means never bulk-deleting the redirect table because it looks untidy.

Verify the map with a script, not by clicking. Every source URL should return a single 301 to a destination that returns 200:

while read -r old new; do
  code=$(curl -s -o /dev/null -w "%{http_code}" "https://example.com$old")
  final=$(curl -s -o /dev/null -w "%{redirect_url}" "https://example.com$old")
  echo "$old $code -> $final (expected $new)"
done < redirects.tsv

Phase 4: canonicals and structured data

Shopify serves the same product at both /products/handle and /collections/collection-handle/products/handle. Themes are expected to emit a canonical pointing at the bare /products/handle form. Verify it in the rendered HTML of a product opened through a collection, because that is the path where the bug hides. Do the same for paginated collection pages and tag-filtered collection views, which can generate a large number of thin, near-duplicate URLs if the theme lets them be indexed.

On structured data, do not assume parity. Your WooCommerce store probably emitted Product, Offer, BreadcrumbList and possibly AggregateRating through an SEO plugin. Which of those are worth rebuilding deliberately, and why a rating you cannot back does not belong in markup at all, is covered in schema markup for AI search. Shopify themes vary in what they output. Run the Rich Results Test against a product, a collection and an article on staging, then against the same three page types on the live WooCommerce site. Anything that disappears is a rich result you are about to lose.

Reviews deserve a specific warning. WooCommerce reviews live in your database; Shopify reviews live in an app. If review data does not migrate, your AggregateRating markup goes with it and star ratings vanish from the search results on launch day. That is often the most visible loss in a migration, and it has nothing to do with redirects.

Phase 5: staging and pre-launch verification

Shopify development stores and password-protected storefronts are not crawlable, which makes pre-launch verification awkward. Work around it rather than skipping it.

• Crawl the staging store with the storefront password supplied to the crawler, and compare the URL inventory against the destination column of your redirect map. Every destination must return 200. A map pointing at 404s is worse than no map.
• Check robots.txt.liquid if you have customised it. Shopify exposes robots.txt through that template, and it is an easy place to accidentally block a collection path.
• Confirm the sitemap at /sitemap.xml includes products, collections, pages and blogs, with counts that roughly match your intended inventory.
• Check every page type renders its title, meta description and canonical. Migration apps rarely carry across SEO plugin fields, so meta descriptions are often what silently arrives empty on four hundred products.
• Test checkout on a real gateway in test mode, then with one live low-value transaction. Rankings do not matter if orders fail.

Phase 6: launch day sequence

Order matters here.

1. Import the redirect CSV before the DNS change, so redirects are live the moment traffic arrives.
2. Point DNS at Shopify. Keep the WooCommerce environment running but unlinked for at least a month; you will want it for reference.
3. Verify the property in Search Console if the domain or protocol changes. If the domain stays the same, no Change of Address is needed — that tool is for domain moves, not URL structure changes on the same host.
4. Submit the new sitemap.
5. Spot-check twenty redirects manually with curl -I and confirm each is a single 301 to a 200, not a chain.
6. Confirm analytics and conversion tracking fire on the Shopify thank-you page. This breaks constantly and is invisible until you look. A conversion that never records makes a working campaign look dead, which is the most expensive leak in a Google Ads account.

Phase 7: what to watch in Search Console

For the first eight weeks the Pages report tells you more than the Performance report does.

Do not judge anything from the first ten days. Recrawling is gradual and the data is incomplete.

A realistic recovery timeline

We will not give you a percentage, because we have not measured one we could defend. What we can describe is the shape.

Expect a visible drop in the first fortnight, because Google is still serving old URLs it has not recrawled while some new ones have no history. Expect impressions to return before positions do. Google's own site move documentation says that "for medium-sized websites, it can take a few weeks or more for Google to gradually start showing the new URLs instead of the old ones (and for larger sites, even longer)".

If you are still materially below your pre-migration baseline after roughly three months, the cause is almost never "the migration". It is a specific, findable fault: a broken canonical, a category tree flattened too aggressively, missing meta descriptions, a theme that lost internal links, or content truncated in the import. Go and find it rather than waiting.

One more variable worth naming. Shopify themes are not automatically fast, and a store that got slower in the move has an extra problem stacked on the URL change. Theme performance is ordinary front-end development work rather than something the migration app handles. Page speed is a weaker ranking input than most agencies claim, but it is a real one. We looked at what Core Web Vitals actually do for rankings separately, and the honest version is less dramatic than the sales pitch.

When you should not migrate

Nobody writes this section, because most migration articles are written by people selling migrations. We sell custom Shopify development and we still turn this work down regularly.

Stay on WooCommerce if your plugins are doing real business logic. Complex B2B pricing tiers, quote-to-order flows, bespoke shipping rules, membership gating. Shopify apps will approximate these. Approximation in checkout logic is expensive.

Stay if the store is a small part of a large content site. If WooCommerce is bolted onto a WordPress property with hundreds of ranking articles and a custom taxonomy, you are proposing to migrate an entire publication to solve a storefront problem.

Stay if your catalogue has unusual variant depth. Shopify caps variants per product, and the cap has changed over time. Check the current limit against your actual SKU structure before committing, because the workaround — splitting one product into several — destroys the URL plan you just built.

Stay if the real problem is neglect rather than the platform. A WooCommerce store on cheap shared hosting with thirty plugins and no maintenance is slow because of those things, not because of WooCommerce. Fixing hosting, cutting plugins and rebuilding the theme is cheaper than a migration and carries none of the ranking risk. If you want that judged honestly first, a technical SEO and performance audit is the cheaper starting point.

Migrate when the platform itself is the constraint. When your team cannot ship a change without a developer. When hosting and security consume real money and attention. When your payment and fulfilment stack already lives in the Shopify ecosystem. When you have outgrown what a self-hosted store can be trusted to do on your busiest trading day.

The decision rule

Migrate for operational reasons and treat the SEO work as risk management rather than upside. Nothing about moving to Shopify makes you rank better on its own. What a careful migration buys is arriving on the new platform with the rankings you already had, which is the entire goal. Budget the redirect map like a feature, because it is the only part of this project that is genuinely irreversible.