SEO
What actually happens to your organic traffic when you leave WooCommerce for Shopify
Table of contents
The 40 percent traffic loss story, and what actually causes it
You have read the thread. A merchant moves off WooCommerce, organic traffic falls off a cliff over the following month, and the conclusion is that Shopify is bad for SEO. When you can get into the site afterwards, the cause is usually visible inside ten minutes. Old product URLs return 404. The redirect file covered products and forgot the blog. The new collection pages carry forty words of copy where the old category pages carried six hundred. The blog side is the easiest of those to miss, because the export everyone maps from carries products and customers and nothing else, so the article, tag, category and archive paths never reach the list in the first place.
None of it is the platform. Shopify does impose real constraints and this article is specific about every one of them, but the constraints are knowable in week one. What costs merchants traffic is that every URL on the site changes at the same moment, and the work of mapping the old set onto the new set is tedious and usually the first thing squeezed when a launch date slips.
Every URL changes, and Shopify decides the shape
WooCommerce inherits WordPress permalinks, so you control the whole path. On any non-plain permalink setting the default product base is /product/ and the default category base is /product-category/. WooCommerce also offers a shop base, which serves products at /shop/blue-parka, a shop base with category at /shop/jackets/blue-parka, and a fully custom base. Different WooCommerce stores therefore look nothing like each other, which is why generic migration advice tends to be useless. The first job is to write down which of those four shapes your store actually uses.
Shopify has none of that flexibility. Products sit at /products/{handle}, collections at /collections/{handle}, pages at /pages/{handle}, and blog articles at /blogs/{blog-handle}/{article-handle}. Those prefixes are fixed on every plan, Plus included. You can change the handle. You cannot change the prefix, and no app or theme changes that, so do not spend a planning meeting on it.
The change that catches people out is nesting. WooCommerce categories are hierarchical, so /product-category/mens/jackets/ is completely normal and Google reads the hierarchy straight out of the path. Shopify collections are flat. There is no /collections/mens/jackets/. Every subcategory becomes its own top level collection, and the structure your URLs used to communicate now has to be carried by navigation, breadcrumbs and internal linking instead. That is a real design decision and it belongs in the build, not in a cleanup ticket afterwards.
| WordPress / WooCommerce | Shopify | What to know |
|---|---|---|
| /product/blue-parka/ | /products/blue-parka | One to one. The easiest rows in the map. |
| /product-category/jackets/ | /collections/jackets | One to one where the category is top level. |
| /product-category/mens/jackets/ | /collections/mens-jackets | Collections do not nest. The parent path is gone. |
| /shop/ | /collections/all | Generated automatically, and thin unless you give it copy. |
| /product-tag/waterproof/ | /collections/all/waterproof | Tag filtering appends a tag handle to a collection path. |
| /about-us/ | /pages/about-us | The /pages/ prefix is compulsory for every content page. |
| /2025/03/how-to-wax-a-jacket/ | /blogs/news/how-to-wax-a-jacket | The blog handle is editable. The /blogs/ segment is not. |
| /category/care-guides/ | /blogs/news/tagged/care-guides | WordPress blog categories become Shopify article tags. |
| /author/anna/ and /2025/03/ archives | No equivalent | Redirect to the blog index or the nearest single article. |
| /feed/ | /blogs/news.atom | Different path and different format. Tell anyone syndicating you. |
| /my-account/ | /account | Cart and checkout paths change shape as well. |
| /wp-content/uploads/2025/parka.jpg | Shopify CDN URL | Image paths cannot be preserved. External hotlinks will break. |
The parts that do not map one to one
Shopify raised the variant ceiling to 2,048 per product in October 2025, and a lot of merchants read that as the end of the variant problem. The option limit did not move. A Shopify product still supports a maximum of three options, and WooCommerce lets you attach as many attributes as you like. A jacket with size, colour, material, fit and sleeve length has to be split across several Shopify products or collapsed into fewer. Either way one old URL now points at several new ones, or several old URLs collapse into one, and your redirect map stops being a straight line. Find those products before you start writing rows, because they are the ones that need a human decision.
Shopify is blunt about the rest of it in its own migration documentation. Reviews cannot be exported from WooCommerce to Shopify. The CSV route moves products and customers, and it does not move orders or blog posts. Reviews matter here for a reason that has nothing to do with social proof: on a mature WooCommerce product page they are often a large share of the indexable text. Drop four thousand reviews on launch day and the page you redirect to is genuinely thinner than the page you redirected from. That is a content change, not a redirect failure, and it will still show up as a ranking change. Budget for a review import before launch.
Building the redirect map
Start from a crawl of the live site rather than from the database export. The export tells you what exists. The crawl and your analytics together tell you what earns something. Merge three sources and deduplicate.
- A full crawl of production, following internal links, including paginated archives, tag pages, author pages and attachment pages. These are the URLs a plugin created years ago that nobody remembers.
- A Search Console pages export covering the full sixteen month window rather than the three month default, so seasonal pages appear.
- Top linked pages from any backlink tool. A page with zero traffic and four referring domains is still worth a row.
- Your existing XML sitemap, which will contain URLs the crawl missed and will miss URLs the crawl found. Both lists are incomplete on their own.
Then the Shopify constraints, which shape the map more than most people expect. Native Shopify redirects match the path exactly. There are no wildcards and no regular expressions in the admin tool. You cannot create a redirect from a URL that currently resolves on the new store, which rules out pre-building rules for paths Shopify already serves. Reserved paths including /products, /collections and /collections/all cannot be redirected at all.
If your WooCommerce store uses the shop base, test this first. Shopify will not create redirects from paths beginning with /apps, /application, /cart, /carts, /orders, /services or /shop. Read that last one twice. A WooCommerce store on the shop base permalink option serves every product at /shop/blue-parka, which is exactly the shape that exclusion describes. Import a single test redirect into the new store and confirm it takes before you assume four thousand of them will. If the native tool refuses, you are looking at a redirect app or an edge rule, and that changes your build estimate rather than your launch date.
The ceilings themselves are generous. Shopify documents a limit of 100,000 redirects on standard plans and 20 million on Plus, and the whole set imports by CSV, so completeness is the constraint rather than volume. Count your own rows before you scope the work. Group the crawl by URL type and look at how much of the list is blog, tag, author and archive paths rather than products, because that split, not the product count, is what decides how long the mapping takes.
The exact match rule is what bites in practice. If your old store answered both /product/blue-parka/ and /product/blue-parka, check whether Shopify normalises the trailing slash for you before you decide whether you need one row or two. If a category ran to fourteen pages you need a row for every /page/N/ path or they all 404. Generate those rows with a script. Nobody hand types four hundred pagination redirects without making a mistake in the middle of them.
Validating the map, twice
A redirect map is a hypothesis until you have run it against a live server. Run it twice, because the answer changes between staging and production.
- Before launch, point your crawler at the staging store and feed it the full old URL list with redirect following turned on. Every row should resolve as a single 301 into a 200. Anything ending in a 404, a 302, or a chain of three or more hops goes back on the work list.
- Check destinations, not only status codes. A map that sends nine hundred product URLs to the homepage returns 301 on every row and is still a failure, because Google treats a redirect to an irrelevant page as a soft 404. Sample by hand across product, category, blog and page types.
- On launch day, run the same list against production within the hour. DNS changes and theme publishing both alter what actually resolves, and staging lied to you at least once.
- Submit the new sitemap in Search Console. Shopify generates /sitemap.xml automatically as an index pointing at child sitemaps for products, collections, pages and blogs, and refreshes it as you publish. Leave the old sitemap accessible for a few weeks so Google has a reason to recrawl old URLs and find the redirects.
- Watch the Search Console pages report for not found and page with redirect over the following six weeks. The 404 list is your missed rows list, and it will not be empty, no matter how careful the first pass was.
The Change of Address tool is not for this. Change of Address in Search Console handles a move to a different domain. A WooCommerce store replatforming to Shopify on the same domain is not a domain change, and there is nothing to submit. You keep the property, you keep the history, and the 301s do the work on their own. If you are also switching domain in the same project, do both, and accept that you have doubled the number of things that can go wrong in one weekend. Splitting the two moves apart by a month is usually the better call.
What to do with the WordPress blog
For content heavy merchants this is the decision that matters most, and it gets made in about five minutes by people who have not thought about the consequences. There are three options and only one of them is usually right.
Move it into Shopify
Articles land at /blogs/{blog-handle}/{article-handle}, and WordPress categories become Shopify article tags at /blogs/{blog-handle}/tagged/{tag}. The default blog handle is news. Change it to something a human would type, such as guides or advice or journal, before you publish a single article, because changing it afterwards means another round of redirects on your best pages. Shopify blogging is thinner than WordPress in ways your editor will notice within a week, and a three thousand word post with tables and shortcodes needs checking by hand rather than trusting the importer. It is still the right default for most stores: one platform, and one set of internal links pointing at your collections.
Keep WordPress and proxy it at /blog
Best possible outcome for link equity, hardest thing on this list to actually run. Shopify sits behind Cloudflare, so putting your own Cloudflare zone in front of the domain and proxying /blog to a WordPress origin is an orange to orange configuration, which either needs an enterprise arrangement or fails in ways that are genuinely unpleasant to debug. Merchants who try it on a free plan tend to end up looking at a permission error on their own storefront. If you have a large editorial operation and engineers who own the edge, this is defensible. Otherwise you have introduced a single point of failure in front of your checkout to save a subdirectory.
Move it to blog.yourdomain.com
The easy option, and the one I would argue against in almost every case. A subdomain is a separate host for internal linking purposes, so you have just cut the wire between the content that earns links and the pages that sell things. Merchants choose it because it takes an afternoon and nothing breaks on launch day. That is the entire argument for it.
Faceted URLs and pagination, and why most of them stay out of the map
WooCommerce layered navigation produces URLs like /product-category/jackets/?filter_size=large&query_type_size=or. On a store that has been running for years there can be tens of thousands of them and a handful will have picked up impressions. Almost none of them belong in your redirect map.
Shopify storefront filters use their own parameter scheme, filter.v.option.color for a variant option and filter.p.product_type for product type. Since 16 March 2026 those parameters carry stable identifiers rather than the readable text values they used to, so a filter that previously read filter.v.option.color=Blue now carries a gid://shopify/FilterSettingGroup/ value instead. Shopify states that existing filter URLs continue to work. The lesson stands either way: filter parameters are Shopify implementation details that Shopify changes, and they are not ranking targets you should be pointing 301s at.
If an old faceted URL genuinely earns impressions, waterproof navy jackets, size 13 work boots, then it deserves a real Shopify collection with its own handle, its own copy and a place in the navigation. Point the old faceted URL at that. Everything else redirects to the parent collection and nobody misses it. Pagination is simpler: Shopify paginates collections with a page parameter and correctly leaves those URLs out of the sitemap, so old /page/2/ archives all redirect to page one of the equivalent collection.
One collection per query, not one per filter combination. The test for whether a faceted URL earns a Shopify collection is whether anyone searches for the thing it describes. Pull the old URL in Search Console, look at sixteen months of impressions and the queries it actually ranked for, and build a collection only where you can name the demand. A store with sixty collections that each answer a real query will outrank a store with six hundred filter permutations every time. Our notes at /seo-services/site-structure cover how to plan that hierarchy before the build starts, which is considerably cheaper than rebuilding navigation in month four.
The dip, and what recovery normally looks like
Expect movement, and say so to whoever signs off the project before launch rather than after. Google is explicit about this in its site move guidance: with any significant change to a site you may see ranking fluctuations while Google recrawls and reindexes, a medium sized site takes a few weeks for most pages to move in the index, and larger sites take longer. During that window your rankings wobble because Google is re-reading the site, not because it has formed an opinion about it.
| Signal | Normal | Go and investigate |
|---|---|---|
| Organic sessions | A visible drop, flattening around week four | Still falling in week eight |
| 404s in Search Console | A spike, then a decline as you patch the map | Climbing week over week |
| Indexed URLs | Old URLs dropping out as new ones come in | New URLs not getting indexed at all |
| Which pages fell | Spread thinly across templates | Concentrated in one template or one category branch |
That last row is the diagnostic one. A drop spread evenly across the site is Google working through a large recrawl. A drop concentrated in one section is a redirect rule that missed a URL pattern, and you can usually find it in an afternoon. Export twelve weeks of Search Console clicks and GA4 sessions before you touch DNS, and split them by page type so you have a baseline per template. Either reading depends on knowing what each template was doing before launch.
Two things genuinely change underneath you and are worth knowing before you sign anything. Collection pages on a new Shopify theme almost always carry less copy than the WordPress category pages they replace, because the theme was designed around a grid and nobody wrote the intro text. Write that copy before launch. And any ranking that depended on a plugin generating pages, a store locator or a few thousand attribute landing pages, has to be rebuilt deliberately, because nothing in the Shopify admin will produce it for you and nobody will notice it is gone until the traffic report comes in.
Common questions
Will I lose SEO if I migrate from WordPress to Shopify?
Not inherently. You will lose traffic if URLs 404, if redirects point at irrelevant pages, or if the new pages carry less content than the old ones. Shopify itself is not the variable. Expect fluctuation for a few weeks while Google recrawls, and judge the migration on whether traffic flattens and recovers rather than on what week two looks like.
Do my old WordPress URLs still work after moving to Shopify?
Only if you redirect them. Every URL changes, because Shopify forces /products/, /collections/, /pages/ and /blogs/ prefixes that WooCommerce never used. Shopify has a native URL redirect tool with CSV import, but it matches paths exactly, supports no wildcards or regular expressions, and refuses several reserved paths. Build the redirect map from a crawl plus Search Console data, not from a database export.
How long does organic traffic take to recover after a Shopify migration?
Google says a medium sized site takes a few weeks for most pages to move in the index, and larger sites take longer. In practice you want to see the decline flatten around week four and recovery underway by week eight. If traffic is still falling in week eight, or the drop sits in one section of the site, that is a redirect or content problem rather than normal reindexing.
Can I keep my WordPress blog after moving to Shopify?
You can, but each option costs something. Moving articles into Shopify at /blogs/{handle}/ is simplest and keeps everything on one host. Proxying WordPress at /blog is best for link equity and difficult in practice, because Shopify sits behind Cloudflare and the proxy setup is fragile. Moving the blog to a subdomain is easy and cuts the internal linking connection to your product pages.
Can I remove /products/ or /collections/ from Shopify URLs?
No. Those prefixes are fixed at every plan level, Shopify Plus included, and no theme or app changes them. You control the handle after the prefix and nothing before it. Shopify collections are also flat, so a nested WooCommerce category such as /product-category/mens/jackets/ becomes a single top level collection and the hierarchy has to live in navigation and breadcrumbs instead.
Does Shopify import WooCommerce blog posts and product reviews?
No to both by default. Shopify documentation states that reviews cannot be exported from WooCommerce to Shopify, and the CSV route covers products and customers but not orders or blog posts. Reviews often make up a large share of the indexable text on a mature product page, so plan a review import app and a blog import route before launch rather than treating them as cleanup.