Shopify Migration SEO Checklist

Rankings are attached to URLs, not to your brand. When a furniture store moves from WooCommerce to Shopify, every URL that changes without a redirect becomes a 404, and every 404 hands back years of accumulated signals — links, engagement history, indexed status. Traffic loss after a migration is almost never mysterious: it is a mapping gap, visible in a spreadsheet, if the spreadsheet exists.

Be clear-eyed about the other truth: even a flawless migration produces temporary volatility. Google has to recrawl the site, follow every redirect, and re-evaluate pages whose templates, internal links, and load times all changed at once. A few weeks of movement is normal and recovers on its own. What does not recover on its own is a missed redirect, or an old URL pattern nobody thought to export.

The checklist below runs in six phases — two before you build anything, two while you build, one at launch, one after. The expensive mistakes happen in the first two phases, weeks before anyone touches Shopify, which is why the preparation work is the part not to compress.

You cannot measure loss without a record of what you had. Before any build work starts:

1. Export every live URL from the old platform. Its XML sitemap is a start, but pull a full page list from the platform's database or a site crawl as well — sitemaps miss orphaned pages that still rank and still earn traffic.
2. Download Search Console performance data — queries and pages, the widest date range available — so you know which pages earn impressions and which queries they earn them for.
3. Record rankings by hand for your money pages: the twenty or so collections and products that drive most revenue, and where each currently stands for its main query.
4. List the pages other sites link to, from Search Console's Links report. Those URLs must redirect somewhere sensible even if the products behind them are being discontinued.

Archive all of it somewhere outside the old platform. The day the old system is switched off, every report it could have generated goes with it — and mid-migration is exactly when you will wish you had one more export.

Shopify's URL structure is fixed, and this is where migrations go sideways: most of your paths will change whether you like it or not. Products live under /products/, collections under /collections/, informational pages under /pages/, and blog posts at /blogs/<blog>/<post>. So /product/oak-bunk-bed becomes /products/oak-bunk-bed, /category/kids-beds becomes /collections/kids-beds, and a post at /blog/nursery-safety becomes /blogs/news/nursery-safety. You cannot create arbitrary root-level paths to preserve an old structure.

Build one spreadsheet from your Phase One export: old URL in one column, new URL in the next, one row per URL. Three decisions to make as you fill it in. Keep handles identical wherever possible — the slug can usually survive even when the prefix cannot. Redirect discontinued products to their closest collection, not the homepage. And collapse the old platform's duplicate URL patterns — uppercase variants, trailing slashes, session parameters — into single rows now; that cleanup overlaps heavily with fixing duplicate content on Shopify, and a migration is the cheapest moment to do it.

Shopify's redirect manager lives under Online Store → Navigation → URL Redirects. Three properties of it shape everything else:

1. Redirects only fire on URLs that would otherwise 404. That means you can import the whole set before launch harmlessly — but also that a redirect from a path Shopify actively serves will silently never trigger.
2. There is no regex and no wildcard support. A pattern like "send everything under /category/ to /collections/" cannot be expressed; every old URL needs its own explicit row, which is why the mapping spreadsheet has to be exhaustive rather than representative.
3. Bulk import is CSV — two columns, "Redirect from" and "Redirect to" — uploaded from the URL Redirects screen. Import in batches and spot-check a sample from each batch immediately.

Point every redirect at its final destination, never at another redirect. If /product/oak-bunk-bed points to /products/oak-bunk-bed and you later rename that handle, update the original row rather than letting a chain form. Chains slow crawling, leak signals at each hop, and break entirely the day any middle link changes.

Every migrated page should keep its title tag and meta description — that phrasing has been earning your clicks for years. Shopify's product CSV import includes SEO title and SEO description columns; map the old metadata into them rather than letting titles default to bare product names. For collections and key pages, edit the Search engine listing section by hand. Tedious for the top fifty pages, and worth it.

Internal links are the quieter half of this phase. Body copy migrated from the old platform arrives with old-style links baked in — /category/ hrefs inside product descriptions, blog posts cross-referencing old blog URLs. Those still resolve through your redirects, but every click takes the extra hop, every crawl follows a chain, and one renamed handle later they break outright. Fix them at the source: export the copy, rewrite paths to the Shopify structure, re-import. Give menus and theme-hardcoded links the same pass.

Then rebuild deliberately — which guides should link to which collections, with what anchor text — using the patterns in our Shopify internal linking strategy guide. A migration is the one moment you touch every page anyway; linking well costs almost nothing extra.

The switchover list, in order:

1. Remove the storefront password under Online Store → Preferences. A password-protected store blocks every crawler; leaving it on is the classic launch mistake, and the symptom is indexing flatlining while everything looks fine to you.
2. Load /robots.txt on the live domain and confirm it is Shopify's standard file — nothing custom blocking /products/ or /collections/.
3. Submit the new sitemap in Search Console. Shopify generates sitemap.xml automatically; you only need to submit it.
4. Spot-check the top twenty pages from your baseline: load each old URL, confirm it 301-redirects in a single hop to the mapped destination, and confirm the destination returns 200.
5. View source on one product, one collection, and one blog post to confirm canonical tags and metadata survived the theme build.

Do this the hour you cut over, not the next morning. A toy store that launches at 9 a.m. with the password still on has lost a day of crawling by the time anyone notices the traffic graph.

Monitoring is the phase most merchants skip, and it is where the remaining problems surface. Watch two reports. First, Search Console's page indexing report, for 404s: each one is an old URL your mapping missed, and the fix is a new redirect row, ideally added within a day of it appearing. Old URLs you never knew existed — feed URLs, ancient campaign pages — reliably turn up here.

Second, your hand-recorded money-page rankings from Phase One. Check them weekly for four to eight weeks against the baseline. Expect movement in the first few weeks; that volatility is normal while Google re-evaluates the site and is not evidence of a mistake. What deserves investigation is a page still below its baseline after six to eight weeks — check that its redirect resolves in one hop, its title and description survived, and internal links point to the new path directly.

Rankings on that timescale are tedious to track by hand, which is where tooling earns its keep: Hushwork tracks positions on your pages continuously and attributes orders back to the pages that earned them, useful in exactly the window when you need evidence the migration paid off.