{"id":4221,"date":"2026-10-08T07:14:30","date_gmt":"2026-10-08T07:14:30","guid":{"rendered":"https:\/\/www.liquidwebdevelopers.com\/blog\/?p=4221"},"modified":"2026-10-19T09:54:34","modified_gmt":"2026-10-19T09:54:34","slug":"wordpress-woocommerce-to-shopify-the-seo-plan","status":"publish","type":"post","link":"https:\/\/www.liquidwebdevelopers.com\/blog\/wordpress-woocommerce-to-shopify-the-seo-plan\/","title":{"rendered":"WordPress + WooCommerce to Shopify: The SEO Plan"},"content":{"rendered":"

The general WooCommerce migration guide<\/a> in this cluster covers the whole project. This article covers only the SEO, in detail, because that is where migrations fail and because WordPress sites present a specific problem the other platforms do not.<\/p>\n

That problem is scale of content. A WooCommerce store is a WordPress site, and WordPress sites accumulate. Products, yes \u2014 but also posts going back a decade, category archives, tag archives, author archives, date archives, attachment pages, paginated series, landing pages from campaigns nobody remembers, and whatever plugins have generated along the way.<\/p>\n

A typical WooCommerce store with 500 products might have 4,000 indexed URLs. Most migration plans account for the 500.<\/p>\n

<\/span>Step one: know exactly what you have<\/span><\/h2>\n

You cannot redirect what you have not inventoried, and you cannot reconstruct this after launch.<\/p>\n

Crawl the entire site.<\/strong> Screaming Frog<\/a> is free up to 500 URLs and inexpensive beyond that; there are alternatives. Crawl everything, including URLs that return non-200 statuses, and export the lot: URL, status code, title, meta description, H1, canonical, word count, and indexability.<\/p>\n

Export Search Console data.<\/strong> Twelve months of performance data by page, and the full coverage report. This tells you which URLs Google actually knows about, which is not the same as what your crawl finds.<\/p>\n

Export analytics.<\/strong> Landing pages by organic sessions over twelve months, with conversions and revenue where you track them. This is how you rank URLs by what they are worth rather than by what they are.<\/p>\n

Export your XML sitemaps<\/a>.<\/strong> All of them, including the ones your SEO plugin generates for post types you forgot existed.<\/p>\n

Pull your backlink data.<\/strong> Any tool will do. You are looking for URLs with external links, because those are the ones where a missed redirect costs you permanently rather than temporarily.<\/p>\n

Cross-reference all five.<\/strong> The union of those lists is your real URL inventory. It will be larger than anyone expected, and the gap between your crawl and your Search Console<\/a> data is usually where the surprises live.<\/p>\n

Do this before you change a single thing. Once the old site is gone, this information is difficult and sometimes impossible to reconstruct.<\/p>\n

<\/span>Step two: classify every URL<\/span><\/h2>\n

Not every URL deserves a redirect, and treating them all the same produces a bloated map that hides the important entries.<\/p>\n

Tier one: individually mapped.<\/strong> Anything with meaningful organic traffic, conversions, or backlinks. Typically a few hundred URLs at most. Each gets a hand-checked destination.<\/p>\n

Tier two: bulk-mapped by pattern.<\/strong> Products, posts, and pages with a clean structural equivalent. A rule maps \/product\/x\/<\/code> to \/products\/x<\/code>, and you spot-check a sample rather than every entry.<\/p>\n

Tier three: consolidated.<\/strong> WordPress archive types that have no Shopify equivalent \u2014 tag archives, author archives, date archives, paginated pages beyond the first. Redirect these to the most relevant parent: a tag archive to a related collection, an author archive to the blog index, date archives to the blog index.<\/p>\n

Tier four: allowed to die.<\/strong> Attachment pages, parameter variations, truly orphaned URLs with no traffic and no links, and anything already returning 404 before the migration. Redirecting these adds noise without value. Let them go and stop worrying about them.<\/p>\n

That classification is most of the intellectual work. It also turns an unmanageable list of 4,000 URLs into a few hundred decisions and a handful of rules.<\/p>\n

<\/p>\n

<\/span>Step three: understand the structural mismatches<\/span><\/h2>\n

WordPress and Shopify differ in ways that create specific problems.<\/p>\n

Shopify enforces URL prefixes.<\/strong> Products live under \/products\/<\/code>, collections under \/collections\/<\/code>, blog posts under \/blogs\/<blog-handle>\/<\/code>, and pages under \/pages\/<\/code>. You cannot flatten these or choose your own structure. So a WooCommerce product at \/product\/thing\/<\/code> becomes \/products\/thing<\/code>, and a WordPress page at \/shipping\/<\/code> becomes \/pages\/shipping<\/code>. Every single URL changes shape, even when the slug stays identical.<\/p>\n

Blog structure differs meaningfully.<\/strong> WordPress supports categories and tags on posts with archive pages for each; Shopify has blogs and tags with weaker archive functionality. If your category archives rank \u2014 and on content-heavy sites they often do \u2014 you need a plan. The usual answer is creating pages or collections that serve the same purpose and redirecting the archives there, rather than pretending the traffic did not exist.<\/p>\n

Products can appear at multiple URLs on WooCommerce.<\/strong> Depending on your permalink configuration, a product may be reachable with and without its category in the path. Check which version is canonical and which version Google indexed, because they are not always the same, and redirect both.<\/p>\n

Pagination.<\/strong> WordPress paginates archives and Shopify paginates collections, but the URL patterns differ. Page two of a category archive rarely matters individually; if any paginated URL has traffic, handle it explicitly.<\/p>\n

Attachment pages.<\/strong> WordPress can generate a page per uploaded image. Most sites should have these disabled; many do not. They are almost always tier four.<\/p>\n

Plugin-generated URLs.<\/strong> Filters, comparison pages, wishlist pages, search results, and anything else a plugin created. Check your sitemaps for post types you did not expect.<\/p>\n

Trailing slashes.<\/strong> WordPress typically uses them, Shopify does not. Ensure your redirects account for both forms so you are not relying on a further redirect to resolve it.<\/p>\n

<\/span>Step four: build the redirect map properly<\/span><\/h2>\n

Every redirect is a 301.<\/strong> Permanent. Not 302, not a meta refresh, not JavaScript.<\/p>\n

Map to the closest genuine equivalent.<\/strong> The test is whether a visitor arriving at the new URL would feel they landed on the page they expected. If not, it is the wrong destination regardless of how convenient the rule was.<\/p>\n

Never bulk-redirect to the homepage.<\/strong> Google treats an irrelevant redirect as a soft 404, the equity does not pass, and you have thrown away the URL’s history for nothing. This single mistake accounts for more lost migration traffic than anything else.<\/p>\n

Avoid chains.<\/strong> Old URL to new URL, in one hop. A chain of three redirects wastes crawl budget and loses a little value at each step. Chains usually appear when a site has been migrated before and the old redirects are still in place \u2014 check for this.<\/p>\n

Preserve the slug where you sensibly can.<\/strong> It reduces the number of things changing at once, which makes diagnosis easier later.<\/p>\n

Implement in Shopify’s URL redirect system,<\/strong> which handles this natively and accepts bulk CSV import. For very large maps, import in batches and verify each.<\/p>\n

Keep the map as a document, not just a configuration.<\/strong> You will need to audit it, hand it to someone else, and check it against your crawl. A spreadsheet of old URL, new URL, tier, and traffic is the artefact that makes verification possible.<\/p>\n

<\/span>Step five: protect the content itself<\/span><\/h2>\n

Redirects preserve the path. They do not preserve the reason the page ranked.<\/p>\n

Migrate content at full length.<\/strong> The most common silent failure: a page redirects correctly, returns 200, and contains a third of what it used to. Compare word counts, before and after, for every tier one and tier two URL. It is a crude metric and it catches almost everything.<\/p>\n

Preserve titles and meta descriptions<\/strong> on ranking pages. If you want to improve them, do it three months after launch, so you can attribute the effect.<\/p>\n

Rebuild internal links.<\/strong> WordPress content tends to be heavily interlinked, and internal links are a ranking signal as well as a navigation aid. During migration, links pointing at old URL patterns either break or redirect \u2014 both worse than pointing directly at the new URL. Search your migrated content for old-domain and old-pattern links and update them.<\/p>\n

Keep image filenames and alt text.<\/strong> Image search drives real traffic for product-led sites, and alt text is routinely dropped in migration.<\/p>\n

Preserve structured data.<\/strong> Product schema, review schema, breadcrumbs, FAQ, article markup. Shopify themes cover much of this; verify with a testing tool rather than assuming. Review schema in particular disappears when reviews do not migrate, and losing star ratings from your search listings is an immediate click-through loss.<\/p>\n

Carry over your category content.<\/strong> WooCommerce category pages often hold genuine buying-guide text. Shopify collections default to bare product grids. Content that ranked must be recreated in the collection description or a section above the grid.<\/p>\n

<\/span>Step six: verify before launch<\/span><\/h2>\n

On staging, systematically.<\/p>\n

Run your redirect map through a bulk checker.<\/strong> Every entry should return a single 301 to a 200. Any 404, 302, chain, or loop is a defect.<\/p>\n

Crawl the staging site<\/strong> and compare page count and structure to your inventory. Missing page types show up here.<\/p>\n

Check canonicals.<\/strong> Every page should self-canonicalise to its production URL. Staging canonicals shipping to production is a classic and costly error.<\/p>\n

Check robots and meta robots.<\/strong> Staging must be blocked; production must not be. Getting this backwards in either direction is expensive, and it happens with some regularity.<\/p>\n

Validate structured data<\/strong> on each template.<\/p>\n

Confirm your sitemap<\/strong> generates and includes what it should.<\/p>\n

Test the tier one URLs by hand.<\/strong> A few hundred manual checks is a day’s work and worth it \u2014 these are the pages carrying your traffic.<\/p>\n

<\/span>Step seven: launch and watch<\/span><\/h2>\n

Submit the new sitemap<\/strong> in Search Console immediately.<\/p>\n

Do not remove the old sitemap<\/strong> straight away; it helps Google find the redirects.<\/p>\n

Keep the old site accessible privately<\/strong> for several months.<\/p>\n

Crawl production immediately after launch<\/strong> and compare against your inventory again. Live behaviour sometimes differs from staging.<\/p>\n

Then monitor weekly for ninety days:<\/strong> Search Console coverage for new 404s and excluded pages, performance by page for the tier one list, crawl stats, and analytics for organic landing pages against the pre-migration baseline.<\/p>\n

Expect two to four weeks of volatility. That is normal and not a reason to change anything. What is not normal is a sustained decline past week four, or a specific set of pages that never recover \u2014 both of which point to a redirect or content problem you can still fix.<\/p>\n

There is a dedicated article in this batch on the ninety-day recovery plan, including what to do when the numbers do not come back.<\/p>\n

<\/span>A worked example: 4,100 URLs and the 340 that mattered<\/span><\/h2>\n

A specialist food retailer migrating from WooCommerce had 620 products and, on crawling, 4,100 indexed URLs. Their developer’s redirect plan covered products and top-level pages: about 700 entries.<\/p>\n

Classification told a different story. Cross-referencing Search Console, analytics, and backlinks identified 340 URLs carrying meaningful traffic, conversions, or links. Of those, 180 were not products. They were recipe posts, ingredient guides, two category archives with substantial buying-guide content, and a cluster of posts about regional producers that had attracted links from food publications.<\/p>\n

None were in the original plan.<\/p>\n

We mapped all 340 individually, bulk-mapped products and remaining posts by pattern, consolidated tag and author archives to the blog index, and let roughly 2,000 attachment and parameter URLs go. The two content-heavy category archives were recreated as Shopify pages with the original text, with the collection linked from them.<\/p>\n

Post-launch, organic traffic dipped 11% in week two, recovered to baseline by week five, and was 8% above baseline by week twelve \u2014 the gain coming from a faster site and cleaner structure.<\/p>\n

The difference between that outcome and a 30% loss was one afternoon of classification work. The 700-entry plan would have 404’d every recipe post and redirected the archives nowhere.<\/p>\n

<\/span>The WordPress-specific traps<\/span><\/h2>\n

Some of these are peculiar to WordPress and catch even experienced migration teams.<\/p>\n

Your SEO plugin was doing more than you think.<\/strong> Yoast, Rank Math, or All in One SEO may be handling canonicals, noindex rules on specific archive types, redirects accumulated over years, breadcrumb markup, and schema output. Before migrating, export the plugin’s redirect list \u2014 there are often hundreds of historical redirects in there from previous site changes. Those old URLs still have links pointing at them, and if you only map your current URLs, you break every one of those older paths. This is one of the most commonly missed items in the entire process.<\/p>\n

Check for existing redirect chains.<\/strong> If the site has been restructured before, you may already have chains. Migrating without flattening them creates longer chains. Map the original<\/em> URLs directly to their new destinations, not to their current intermediate targets.<\/p>\n

Noindexed pages do not need redirects, but verify which they are.<\/strong> Your plugin may be noindexing tag archives, paginated pages, or author archives already. If Google was never indexing them, they are tier four regardless of what your crawl shows.<\/p>\n

Custom post types.<\/strong> If a previous developer created custom post types \u2014 case studies, recipes, producers, stockists \u2014 they have their own URL patterns and sitemaps, and they are easy to overlook entirely because they do not look like posts or products in the admin. Check your sitemap index for post types you were not expecting.<\/p>\n

Multisite installations.<\/strong> If your store is part of a WordPress multisite, understand which URLs belong to which site and what is moving where before you start.<\/p>\n

AMP pages.<\/strong> If you ever had an AMP plugin active, there may be indexed AMP URLs. These need redirecting to their canonical equivalents.<\/p>\n

Feed URLs.<\/strong> WordPress generates RSS feeds at predictable paths, and some have subscribers or are consumed by other services. Shopify generates feeds at different paths. Redirect the main ones.<\/p>\n

Author pages with real traffic.<\/strong> Rare, but content-led sites sometimes have author pages that rank, particularly where the author is a known figure in the niche. Check before consigning them to tier three.<\/p>\n

Comment pagination and comment feeds.<\/strong> Usually tier four, occasionally linked externally. A quick check of your backlink data settles it.<\/p>\n

<\/span>Who should do this work<\/span><\/h2>\n

A fair question, since this article describes a fair amount of specialist work.<\/p>\n

The crawl and inventory<\/strong> can be done by anyone methodical with the right tools, and doing it in-house is a reasonable way to save money. It is mechanical rather than expert work.<\/p>\n

The classification<\/strong> benefits from judgement about what is worth preserving, but a store owner who knows their content can make good decisions here \u2014 often better ones than an outside agency, because they know which pages matter to the business.<\/p>\n

The redirect mapping<\/strong> for tier two and three is rule-based and mechanical. Tier one benefits from someone who has done it before, because the failure modes are not obvious until you have seen them.<\/p>\n

The structural decisions<\/strong> \u2014 what happens to category archives that rank, how content moves into collections, how to handle custom post types<\/a> \u2014 are where experience pays most, and where most of the value of hiring someone sits.<\/p>\n

The verification<\/strong> is mechanical but must actually happen. This is the step most often skipped under launch pressure, and the one where skipping is least forgivable, because every defect it would have caught is cheap to fix before launch and expensive afterwards.<\/p>\n

The ninety-day monitoring<\/strong> needs someone whose job it explicitly is. Not “we’ll keep an eye on it” \u2014 a named person with a weekly recurring task. Migrations quietly lose traffic in month two while everyone has moved on to other work, and the difference between catching that in week three and week twelve is the difference between an adjustment and a recovery project.<\/p>\n

If budget is limited, the highest-value place to spend it is the structural decisions<\/a> and the verification. The mechanical work can be done in-house by someone careful.<\/p>\n

<\/span>The bottom line<\/span><\/h2>\n

The data migration is a task. The SEO plan is the project.<\/p>\n

Inventory everything from five sources before you touch anything. Classify by value rather than treating all URLs alike. Understand that Shopify’s enforced URL structure means every URL changes even when slugs do not. Map tier one by hand. Never bulk-redirect to the homepage. Then check that your content survived at full length, because a perfect redirect map pointing at hollowed-out pages loses rankings just as thoroughly as a missing one.<\/p>\n

Verify on staging, verify again on production, and watch for ninety days. Done properly, a WooCommerce migration costs you a few weeks of volatility and gains you a faster store. Done carelessly, it costs a year \u2014 and the recovery work<\/a> is always more expensive than the prevention would have been.<\/p>\n

<\/span>Frequently asked questions<\/span><\/h2>\n

<\/span>How many redirects do I actually need when migrating from WooCommerce?<\/span><\/h4>\n

Fewer than your URL count and more than your product count, which is the mistake in both directions. A 500-product store commonly has several thousand indexed URLs once you include posts, category archives, tag archives, author archives, attachment pages, and plugin-generated URLs. But most of those carry no traffic and no links, so redirecting all of them adds noise. Classify instead: individually map anything with traffic, conversions, or backlinks \u2014 usually a few hundred URLs \u2014 bulk-map products and posts by pattern, consolidate archive types to relevant parents, and let worthless URLs go.<\/p>\n

<\/span>Why did my traffic drop after migrating to Shopify even though redirects are in place?<\/span><\/h4>\n

The most common cause is content loss rather than redirect failure. A page can redirect correctly, return a healthy 200 status, and no longer contain what made it rank \u2014 because it was rebuilt manually and got shortened, or because category page content was not recreated when collections replaced archives. The second common cause is bulk-redirecting non-product URLs to the homepage, which Google treats as a soft 404 that passes no equity. Check word counts on your top pages before and after, and audit where your archive and content URLs actually point.<\/p>\n

<\/span>Should I redirect WordPress tag and category archives?<\/span><\/h4>\n

Yes, but consolidated rather than individually, and check whether any of them earned traffic first. Category archives on content-heavy WooCommerce sites sometimes carry substantial buying-guide text and rank for real terms \u2014 those deserve individual treatment, usually by recreating the content as a Shopify page or in a collection description and redirecting the archive there. Tag archives, author archives, and date archives rarely justify that effort and can be consolidated to the blog index or a relevant collection. What you should not do is leave them returning 404, particularly where they have external links.<\/p>\n

<\/span>How long should I wait before judging a migration’s SEO impact?<\/span><\/h4>\n

Give it four weeks before drawing conclusions and ninety days before considering it settled. Two to four weeks of volatility is normal while Google recrawls and reprocesses your URL changes, and reacting in week two usually means changing things while the picture is still forming. What warrants immediate action regardless of timing is a technical defect: new 404s appearing in Search Console, redirect chains, staging canonicals on production pages, or pages excluded for reasons you did not intend. Those are not volatility, and they do not resolve themselves.<\/span><\/p>\n

<\/span>Can I change my URL structure or slugs during a WooCommerce migration?<\/span><\/h4>\n

You can, but doing it at the same time makes diagnosis considerably harder, and Shopify already forces enough change. Its enforced prefixes mean every URL alters shape even when you keep the slug identical \u2014 so your redirect map is substantial regardless. Adding discretionary slug changes on top means that if a page loses rankings, you cannot separate the platform move from your editorial change. Keep slugs as they are through the migration, confirm things have stabilised over ninety days, then improve slugs deliberately with fresh redirects if you still want to.<\/p>\n","protected":false},"excerpt":{"rendered":"

The general WooCommerce migration guide in this cluster covers the whole project. This article covers only the SEO, in detail, because that is where migrations fail and because…<\/p>\n","protected":false},"author":7,"featured_media":4302,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[375],"tags":[],"class_list":["post-4221","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-migration-guides"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t