For a content-heavy B2B site, the scariest line in a migration plan is the one about URLs. Years of category rankings, product pages with backlinks, and blog posts that quietly feed the pipeline all live at addresses that will not exist on the new platform, and everyone in the room knows a story about a migration that lost a third of its organic traffic. This guide is the mechanical version of not becoming that story: how Magento URLs map to Shopify's structure, how the redirect build actually works within Shopify's real constraints, and what to watch in the weeks after cutover.
Quick answer: Magento lets you shape URLs freely; Shopify does not, every product lives under /products/, every category under /collections/, every page under /pages/, so preserving your exact URL structure is off the table and comprehensive 301 redirects are the whole game. The work runs in four steps: build a complete URL inventory from crawl, Search Console, analytics, and backlink data; map old patterns to new paths with explicit decisions for the messy cases; generate and import the redirect list as exact from-to pairs, since Shopify redirects are not wildcard rules; and monitor coverage, 404s, and rankings through the recrawl window with the redirects left in place permanently.
The Structural Fact Everything Follows From
Magento's URL layer is famously flexible: nested category paths, .html suffixes, custom rewrites accumulated over years in the rewrite table. Shopify's is famously fixed. Products resolve at /products/{handle}, collections at /collections/{handle}, content at /pages/ and /blogs/, and no configuration changes that.
This removes an entire debate from the project. There is no "keep our URLs" option to evaluate, and any migration plan claiming otherwise misunderstands the platform. The consequence is that redirect mapping is not an SEO nicety appended to the project; it is the load-bearing SEO workstream, which is why the migration practice implements 301s across the full URL structure before go-live rather than patching them after.
Step One: Build the URL Inventory
You cannot redirect what you have not listed, and the list has four sources because no single one is complete. Crawl the live site for every reachable URL. Export the indexed pages and query data from Search Console, which catches URLs the crawl misses and tells you which ones earn impressions. Pull the top landing pages from analytics, which ranks them by revenue reality.
And export the linked URLs from your backlink tool, because a page with referring domains deserves an explicit redirect even if it has not ranked in years. On the Magento side, the URL rewrite table is worth exporting too, since it contains the historical redirects already in flight, chains you will want to flatten rather than inherit.
Then tier the inventory, because effort should follow value. The pages that earn rankings, revenue, or backlinks get individually verified mappings. The long tail gets pattern-generated mappings. And a third category gets a deliberate decision to be let go, which is not failure, it is hygiene.
Step Two: Map Patterns to Shopify's Structure
The mapping work sorts into predictable cases.
Product URLs, whatever their Magento shape, /category/sub/product.html or a flat custom path, map to /products/{handle}. One nuance from Shopify's own redirect documentation worth knowing before it bites: a URL ending in .html cannot be redirected to the same path without .html, because Shopify treats them as one URL. Magento's .html suffixes are fine to redirect, they just have to point at the new /products/ path, not at a suffix-stripped twin of themselves.
Category URLs map to /collections/{handle}, with a decision per category tree: deep Magento hierarchies flatten, so /power-tools/drills/cordless either becomes its own collection or redirects into its parent, and that call should be made by search value, not by whoever is fastest in the spreadsheet.
CMS and blog content maps to /pages/ and /blogs/{blog}/{article}, a mostly mechanical exercise once the content migration decides what survives.
The messy residue is where plans go quiet and traffic goes missing: layered-navigation parameter URLs, on-site search results, session-stamped links. Shopify's documentation notes that URLs with query strings may not behave as expected in redirects, which forces the honest triage: parameter URLs that earned rankings or links get mapped to their clean collection equivalent, and the uncountable rest are allowed to 404, deliberately, on the record. A filtered URL that was never indexed does not need a redirect; it needs someone to have decided that on purpose.
Step Three: Build the Redirects Within the Real Constraints
Shopify's redirect engine has specific mechanics, and the build goes smoothly when the list is generated to fit them rather than discovered against them.
Redirects are exact from-to pairs. Your pattern logic lives in the spreadsheet or script that generates the list, not in the platform, so "everything under /category-x/ goes to /collections/x" becomes however many explicit rows that pattern contains. Redirects fire only from URLs that would 404, which is the correct condition for a migration, every old Magento path 404s on Shopify by definition, but matters if an old path collides with a live new one.
A handful of prefixes and fixed paths cannot be redirected from at all, and bulk import runs on CSV, with apps recommended beyond a certain scale. Capacity is a real number too: 100,000 redirects on standard plans, 20 million on Shopify Plus, which is precisely why large Magento catalogs with years of URL history belong on the Plus side of that limit.
Three practices keep the build clean. Flatten chains before importing, so a historical rewrite pointing to a page that now also redirects becomes one hop from original to final. Update internal links in migrated content to target new URLs directly rather than riding through redirects forever. And stage the whole set on the parallel environment before cutover, the parallel go-live sequence exists so things like redirect coverage are verified while the old store still carries the traffic.
Step Four: Canonicals, Sitemaps, and the Cleanup Layer
Redirects carry the equity; three supporting systems keep it. Shopify generates canonical tags automatically, including the behavior worth knowing in advance: product pages reached through a collection path canonicalize to the bare /products/ URL, which is correct for consolidation and occasionally surprises teams auditing with a crawler on day two. Shopify also generates the sitemap at /sitemap.xml, so launch housekeeping is submitting it in Search Console, keeping the existing property (the domain has not changed, only the paths), and letting the old sitemap's URLs return their 301s so recrawl discovers the mapping. Structured data is theme-and-app territory rather than platform-automatic, so product schema parity goes on the launch checklist next to everything else that renders in a template.
One international note from the documentation, pleasant for once: a single redirect automatically applies across market subfolders, so /en-ca/ and friends inherit the mapping without duplicate rows.
What the First Six Weeks Look Like
Set expectations from the honest sentence on the migration page rather than from hope: rankings can be protected with a proper redirect strategy, and search engines still need time to recrawl and reindex, so positions can wobble through the transition window even in a clean migration. The job in that window is instrumentation, not panic. Watch Search Console's coverage and redirect reporting as the new URLs replace old ones in the index, and watch the 404 log, because every hit there is either a mapping gap to fix or a deliberate let-go to confirm.
Watch the pages that carry the business, the tiered list from step one, rather than the aggregate curve, which recrawl noise makes briefly unreadable. And leave the redirects in place permanently: 301s are cached and equity consolidation is not a six-month project, so retiring redirect rows is a cost with no benefit.
For the broader project this workstream sits inside, phases, data, accounts, ERP, the B2B migration checklist is the working document, and the same redirect discipline applies to any replatform to Shopify, whatever the source platform's URL habits.
Uncap has been a Shopify Platinum Partner since 2013, with more than 380 B2B commerce projects delivered, and URL mapping with full redirect implementation before go-live is standard migration scope, not an add-on. Talk to Our Experts if you want your URL inventory assessed against this playbook, the crawl and the tiering are a first-week deliverable, not a mystery.
Related reading: Generative engine optimization for Shopify B2B.
Frequently asked questions
Will SEO rankings survive a Magento-to-Shopify migration?
They can be protected with a complete redirect strategy: every URL with rankings, revenue, or backlinks explicitly 301-mapped to its new home before go-live, internal links updated, and the sitemap resubmitted. Expect some position movement during the recrawl window even in a clean migration, since search engines need time to process the new URL structure, and judge recovery on your valuable pages rather than the aggregate curve.
Can Magento URL structures be kept on Shopify?
No. Shopify's paths are fixed, products under /products/, collections under /collections/, content under /pages/ and /blogs/, and cannot be reshaped to match Magento's free-form URLs. That is exactly why comprehensive 301 redirects are the core SEO workstream of the migration rather than an optional extra.
How do you redirect thousands of Magento URLs when Shopify has no wildcard redirects?
By generating the list outside the platform: pattern logic in a script or spreadsheet expands into explicit from-to pairs, imported in bulk via CSV or an app. Capacity accommodates it, 100,000 redirects on standard plans and 20 million on Shopify Plus, which is one of several reasons large catalogs migrate to Plus.
How long should migration redirects stay in place?
Permanently. 301s are cached by browsers and search engines, backlinks continue resolving through them for years, and removing them creates 404s with no offsetting benefit. Treat the redirect set as part of the site, not as scaffolding to strike after launch.