Shopify migration SEO: the playbook for replatforming without a traffic crater.

Replatforming to Shopify is the moment a bad SEO decision costs the most. Every URL that currently ranks is at risk. Every internal link is about to point somewhere different. Every schema type has to be rebuilt on the destination platform. Every canonical has to be reconciled. And all of it has to be coordinated with design, engineering, data migration, and integration work happening in parallel.

Most migrations we audit post-mortem went wrong in week one — when SEO wasn’t in the room during architecture and URL-structure decisions. By week ten, the SEO consultant was brought in to “check the redirects,” which is too late.

This playbook is how we run migration SEO as a first-class workstream from kickoff through day 90 post-launch. Written for mid-market brands replatforming to Shopify or Shopify Plus, whether from Magento, WooCommerce, BigCommerce, or Salesforce Commerce Cloud. Cross-reference to the full Shopify SEO playbook for ongoing post-migration work.

Pre-migration audit

Before you touch staging, know what you have. The audit outputs are the inputs to every migration decision.

1. Full URL crawl. Screaming Frog against the source platform. Every indexable URL, every status code, every canonical, every schema block, every template. Export to CSV.

2. GSC export — last 12 months. Query data, impressions, clicks, page-level performance. Filter for URLs with meaningful organic traffic. Pay particular attention to URLs ranking 1–10 for commercial queries; those are the ones whose loss shows up in revenue.

3. Ahrefs or Semrush backlink export. Top linked URLs, anchor text distribution, linking domains. Backlinked URLs that 404 are a direct revenue leak — prioritize their 301 targets carefully.

4. Analytics export. Top revenue-driving organic pages over the last 12 months. Which URLs actually earn money, not just which ones rank.

5. Schema audit. Every structured data type currently shipping. Product, Organization, BreadcrumbList, FAQPage, Article, LocalBusiness — whatever the source platform outputs. Validate each against the Rich Results test.

Output: a matrix of URL × rank × organic traffic × organic revenue × backlinks × current schema. This matrix drives every migration decision. It also tells you which URLs deserve hand-curated 301 targets vs. which can safely ride a bulk pattern.

301 redirect strategy

Every URL in the audit gets a target. No exceptions.

Decision framework:

• Direct 1:1 map — new URL exists, content is preserved. Default case.
• Consolidation map — new URL structure rolls up multiple source URLs (e.g., Magento category + subcategory flattened to Shopify collection). Source URLs 301 to the consolidated collection.
• 410 Gone — product permanently discontinued, no reasonable parent collection. Rare; requires deliberate decision because you’re telling Google the URL is gone for good.
• Never 302 — temporary redirects signal the old URL will return, which isn’t what you want during a migration.

Shopify supports bulk redirect import via CSV in the admin. Test in staging before launch: take a sample of 100 redirects, fire them against the staging environment, confirm each returns the right 200 at the target.

For backlinked URLs specifically, the 301 target matters more than for orphan URLs. A backlink pointing to a URL that 301s to an unrelated collection loses most of its link equity signal. Invest in the manual review of high-authority backlinked URLs — the top 50 by referring domain count, roughly.

Schema and canonical parity

Every schema type on the old site needs a matching implementation on Shopify. Every canonical needs reconciliation.

Schema to verify on Shopify:

• Organization + WebSite — global, rendered from BaseLayout
• BreadcrumbList — every non-home page
• Product with offers, aggregateRating, brand, sku — every PDP
• FAQPage — wherever FAQ sections render
• Article — blog content
• LocalBusiness — if applicable

On Shopify, canonicals are mostly handled correctly by default. The exceptions that bite:

• Variant URLs default to the product canonical (correct) but parameter handling can vary by theme
• Search and filter pages — often missing canonicals entirely; decide per use case
• Tag pages — canonical to the parent collection, or noindex if the content is thin
• /pages/ content from historical migrations — review individually

We run a staging crawl comparison against the production crawl before any redirect testing: same URL, same canonical target, same schema payload. Any diff is flagged and resolved before launch.

Staging environment tests

Pre-launch test matrix:

1. Full staging crawl with Screaming Frog. Compare to production crawl by URL × status × canonical × schema types.
2. Schema validation on 20+ sample URLs (one of each template type) via Rich Results test. Any warnings or errors resolved.
3. 301 redirect testing — take a sample of 100 redirect rules, submit via Screaming Frog’s bulk list mode, confirm each returns the expected 200 at the target URL. Fix any that 404 or redirect-chain.
4. Core Web Vitals on staging — Lighthouse on key templates (home, PDP, collection, search, article). Confirm budgets met before launch.
5. Internal link check — every internal link resolves, no chains longer than one hop, no links to excluded URLs.

All findings logged. Launch gate: zero unresolved errors.

Launch day monitoring

The first 48 hours are the highest-risk window.

Within the first 4 hours of cutover:

• Spot-check 50 redirect rules against production (fire each, confirm 301 + correct target)
• Confirm robots.txt is correct (not still Disallow: / from staging — this is a surprisingly common incident)
• Confirm sitemaps are submitted in GSC; verify URL counts match expectations
• Watch the GSC Coverage report and crawl stats (even though real data lags)
• Monitor analytics for traffic anomalies by source (direct, organic, paid, email) — early signals

Day 1–7:

• Daily GSC check for new crawl errors
• Daily analytics comparison vs. pre-launch 30-day baseline (by day of week to account for weekly patterns)
• Hotfix posture — on-call engineer and SEO lead, shared Slack channel, 4-hour response SLA

Typical week-one signal: organic traffic dips 5–15%. This is expected during recrawl and reindexing. Traffic below −15% after day 5 is a signal to investigate — likely a missed redirect pattern or a canonical regression.

30/60/90 day recovery

Day 30: full retrospective. GSC Coverage report, impressions, clicks, and rank for top commercial queries. Compared to the 30-day pre-launch baseline. Expected state: recovery underway, traffic at 90–95% of baseline and trending up. Any persistent regression triaged:

• Which queries are down? (indicates content or SEO issue)
• Which pages are down? (indicates canonical or redirect issue)
• Coverage errors? (indicates technical issue — schema, robots, sitemap)

Day 60: refinements shipped based on day-30 findings. Expected state: approaching baseline on most queries. Remaining gaps isolated to 2–3 patterns, each with a named fix.

Day 90: past baseline on most key queries. If not, the audit goes deeper — missed 301s, schema regressions, content gaps (where the destination page has less content or different entity coverage than the source page). Recovery timeline extends if substantial content rebuilding is needed.

Measured each week; reported monthly. Treat the 90-day window as part of the migration engagement, not a separate post-launch retainer.

Per-platform notes

Magento → Shopify

The most common migration and the one with the deepest customization debt. URL structure: Magento’s category/subcategory/product often collapses in Shopify’s flatter architecture. Decide per store:

• Preserve hierarchy visually via breadcrumb metafields (display), even when the URL flattens
• Or flatten both URL and display (usually the right call for SEO clarity)

Magento’s layered navigation (faceted filters) generates indexed URLs that Shopify handles differently. Plan the 301 pattern for these — typically to the unfiltered collection.

Magento’s attribute system maps to Shopify variants + metafields. Where an attribute was URL-visible on Magento (color in URL, for example), decide whether to preserve that via variant-specific landing pages or flatten.

Historical orders from Magento Commerce have complex pricing records (tier pricing, catalog price rules); these don’t affect SEO but affect whether the migration feels “complete” to the ops team.

WooCommerce → Shopify

WooCommerce stores are WordPress sites with an e-commerce bolt-on. Content migration is real work:

• Blog posts → Shopify blog articles. URL pattern changes (/YYYY/MM/slug/ → /blogs/news/slug/ or custom). 301 every post.
• Custom post types (glossaries, FAQs, author bios, team pages) → Shopify pages or metaobjects. Each pattern needs a 301 target.
• Yoast SEO meta — export meta titles, descriptions, canonicals, per-post schema settings. Map to Shopify metafields on pages and articles. This is the single biggest “don’t forget” item we see.
• Plugin functionality — review plugins, map each to a Shopify equivalent (app or custom). Any plugin that wrote to the database needs a data migration plan.

WordPress permalink structures are worth mapping carefully because they vary per install: ?p=123, /YYYY/MM/slug/, /category/subcategory/, /tag/name/. Every variant needs a 301 target.

BigCommerce → Shopify

Usually cleaner than Magento. Main reconciliations:

• Product option sets — BigCommerce exposes options as URL parameters; Shopify handles via variants. 301 parameterized URLs to the product canonical.
• Native features (reviews, abandoned cart, wishlist) — map to Shopify apps.
• Category URL structure — typically flatter than Magento; fewer hierarchy collapses.

Salesforce Commerce Cloud → Shopify Plus

Enterprise migrations. Most complex URL structures (markets, locales, sites). Plan hreflang + market routing before finalizing redirects. SFCC cartridge logic maps to Shopify Functions and Flow; these don’t affect SEO directly but affect the timeline, which affects when SEO can start staging tests.

When it goes wrong

The three failure modes:

Missed 301s. Traffic drops week 1, doesn’t recover. Fix: audit the 404 report in GSC Coverage; add missing redirects; traffic usually recovers within 2–4 weeks of fix.

Schema regressions. Rich result losses in SERPs (star ratings disappear from product results, FAQ rich results drop). Fix: re-audit the Rich Results test on affected templates; reinstate missing schema; rich results return after recrawl (typically 2–6 weeks).

Content gaps. The destination page has less content or different entity coverage than the source. This is harder to recover from — it’s not a technical fix, it’s a content rebuild. Usually surfaces at day 30 when rankings on specific queries don’t recover. Fix: rewrite the affected pages to match or exceed the source content depth. Recovery timeline extends 4–12 weeks.

Prevention beats recovery. All three failure modes are caught by the pre-launch staging tests above.

Work with us on migration SEO

If you’re planning a Shopify migration and want SEO as a first-class workstream from week one: plan your migration. We’ll run the parallel SEO track alongside development — audit, 301 map, schema parity, staging tests, launch-day monitoring, 30/60/90 recovery.

Full migration service at replatforming without losing traffic. Ongoing SEO work post-migration at Shopify SEO.