Ecommerce Replatforming SEO Checklist

Platform Migration Without Traffic Loss: The Ecommerce Replatforming SEO Checklist

Every ecommerce brand hits the moment. The Shopify store that got you to $5M can't handle your B2B wholesale portal. The WooCommerce site that worked at 500 SKUs buckles at 5,000. The Magento monolith your dev team inherited is burning $15K/month in hosting and maintenance.

You need to replatform — and the VP of Marketing just asked the question nobody in the room can answer: “What happens to our organic traffic?”

The honest answer? If you don't plan for it, organic traffic drops significantly — sometimes catastrophically. We've seen brands lose 30-50% of organic sessions in the first month after a poorly executed migration.

The recovery timeline? Three to six months if you catch the mistakes quickly. Twelve months or more if you don't. For a DTC brand where organic search represents 20-40% of total site traffic (per Semrush), that's a revenue hit no amount of incremental ad spend can offset.

This checklist exists because the migration vendor won't tell you this. They want to sell the replatform. We want to help you protect the ecommerce SEO equity you've spent years building — and the B2B SaaS SEO infrastructure that supports it.

Ecommerce platform migration SEO requires a systematic pre-migration audit, 1:1 URL redirect mapping, structured data preservation, and a 30-day post-launch monitoring protocol. Skip any step, and you risk significant organic traffic loss that takes months to recover.

Before You Touch Anything: The Pre-Migration SEO Audit

The single most expensive mistake in platform migration is starting the build before completing the audit. Once your dev team is three months into the new platform and discovers that the URL structure can't accommodate your existing category hierarchy — you're either rewriting the architecture or accepting the SEO hit. Neither is acceptable. The audit prevents both.

1. Complete URL Inventory

Export every indexed URL from your current site. Not just the pages you think matter — every URL Google has in its index. Use Google Search Console's Index Coverage report, Screaming Frog, or Ahrefs Site Audit to pull the full list. You're looking for:

• Product pages — every active and discontinued product URL
• Collection/category pages — including filtered and sorted variations
• Blog posts and content pages — including paginated archives
• Image URLs — if images are indexed separately (common with image-heavy product photography)
• Canonical URLs — the canonical version of every page, not just the variant URLs
• Parameterized URLs — search result pages, filter combinations, tracking parameter variations

For a typical Shopify store with 2,000 SKUs, expect 5,000-15,000 indexed URLs once you count product variants, collection filters, blog posts, and policy pages. For a WooCommerce or Magento store with complex filtering, that number can exceed 50,000.

2. Link Equity Audit

Not all URLs are created equal. Before migrating, identify which pages carry the most link equity — because those are the pages where a broken redirect means the most damage.

Pull your backlink profile from Ahrefs or Semrush. Map every referring domain to the specific page it links to. Sort by domain rating of the linking site. The top 50-100 pages by link equity are your highest-priority redirect targets. If you get those right and everything else wrong, you'll preserve the majority of your organic authority.

Pay special attention to:

• Old blog posts that earned links years ago but still pass equity
• Press mentions linking to specific product pages that may have been discontinued
• Resource pages from industry sites linking to your category pages
• Brand mentions with links pointing to your homepage or about page

3. Indexed Page Count Baseline

Record the exact number of pages Google has indexed via Search Console. This is your baseline. After migration, if the indexed count drops by more than 10% within the first two weeks, something went wrong with either your redirects, your sitemap, or your robots.txt.

4. Canonical Tag Inventory

Document every canonical tag on the current site. Pay attention to:

• Self-referencing canonicals (page points to itself — the standard pattern)
• Cross-domain canonicals (if you're consolidating domains during migration)
• Product variant canonicals (color/size variants pointing to a parent product)
• Paginated series canonicals

If your current site has inconsistent canonical tags, the migration is actually an opportunity to fix them — but you need to know the current state first.

5. Structured Data Inventory

Export every page's structured data. For ecommerce, this typically includes:

• Product schema — name, price, availability, images, SKU, brand, aggregateRating
• BreadcrumbList — site navigation path
• Organization — brand entity information
• FAQ schema — on product and category pages with FAQ sections
• Review/Rating schema — aggregateRating and individual reviews

The new platform needs to output equivalent structured data. If you're moving from Magento (where structured data is often plugin-generated) to Shopify (where it depends on your theme), this is where details get lost.

6. Current Rankings Snapshot

Export your current keyword rankings for at least your top 200 keywords. This becomes your comparison baseline post-migration. Without it, you're guessing whether rankings changed. Tools like Ahrefs, Semrush, or STAT provide historical tracking, but a manual export before migration gives you a clean reference point.

7. Content Inventory

Document all non-product content on the current site:

• Blog posts (titles, URLs, word count, internal links)
• Category page copy (unique descriptions vs. template text)
• Landing pages and campaign pages
• Customer reviews and Q&A content (this is often platform-specific and doesn't migrate automatically)

Customer reviews are especially critical. A product page with 200 reviews has significant SEO value — both from the unique content the reviews provide and from the Product schema with aggregateRating. If your review platform (Yotpo, Judge.me, Okendo, Stamped) doesn't migrate cleanly to the new platform, those reviews — and their SEO value — disappear.

URL Structure Decisions: When to Preserve, When to Improve

Here's the most consequential SEO decision in any migration: do you keep the same URL structure, or do you use the migration as an opportunity to improve it?

The conservative answer — keep everything the same — is usually right. Every URL change requires a redirect, every redirect passes slightly less authority than a direct link, and the more URLs you change, the more opportunities for something to break. But there are cases where changing URLs during migration is worth the temporary ranking disruption.

When Keeping URLs Is the Right Call

• Your current URLs are clean, descriptive, and keyword-rich (e.g., /collections/womens-running-shoes)
• Your site has strong organic rankings you can't afford to risk
• Your link equity is concentrated on a small number of high-authority pages
• You're migrating between platforms that support flexible URL structures (e.g., BigCommerce to Shopify Plus with custom URLs)

When Changing URLs Is Worth the Risk

• Your current URLs contain parameters, IDs, or gibberish (e.g., /product.php?id=4829&cat=12)
• Your URL structure is flat and doesn't reflect category hierarchy
• You're consolidating duplicate or near-duplicate pages during migration
• Your current URLs are excessively long or contain irrelevant path segments

Platform-Specific URL Constraints

This is where platform knowledge becomes critical. Each ecommerce platform has URL structure opinions — and some of those opinions are non-negotiable.

Shopify forces specific URL paths:

• Products: /products/[handle]
• Collections: /collections/[handle]
• Blog posts: /blogs/[blog-name]/[post-handle]
• Pages: /pages/[handle]

You cannot remove /products/ or /collections/ from the path. If your current Magento store uses /running-shoes/mens-trail-runners and you migrate to Shopify, that URL becomes /collections/mens-trail-runners — a redirect is unavoidable.

BigCommerce offers flexible URL customization. You can set custom URL paths for products, categories, and content pages. This makes BigCommerce a lower-risk migration target from an SEO perspective because you can often replicate your existing URL structure exactly.

WooCommerce uses WordPress permalink settings, giving you full control over URL structure. The challenge with WooCommerce isn't URL flexibility — it's the complexity of maintaining SEO performance at scale (plugin conflicts, server-side caching requirements, database optimization).

Headless Commerce (Hydrogen, Next.js Commerce, custom) gives you complete URL control since the frontend is decoupled. But this freedom comes with responsibility — there's no platform default handling canonical tags, generating sitemaps, or managing redirects. You build all of it.

The Redirect Strategy: Where Migrations Succeed or Fail

Redirects are the single most important technical element of any platform migration. Get them right, and organic traffic survives the transition. Get them wrong, and months of recovery follow.

The 1:1 Redirect Map

Every URL on the old site needs a corresponding destination on the new site. This is not optional, and it cannot be automated without human review.

Build a spreadsheet with four columns:

1. Old URL — the full path from your URL inventory
2. New URL — the equivalent page on the new platform
3. Redirect Type — 301 (permanent) for everything unless you have a specific reason for 302
4. Status — mapped, no equivalent, merged, discontinued

For pages with no direct equivalent on the new site — discontinued products, removed categories, expired campaign pages — redirect to the nearest relevant parent. A discontinued running shoe should redirect to the running shoes collection page, not the homepage. Redirecting everything without an equivalent to the homepage is a common mistake that Google treats as a soft 404.

Handling Discontinued Products

Ecommerce sites have a unique challenge: products come and go. A migration that happens alongside a product catalog overhaul means hundreds or thousands of product URLs that won't exist on the new site.

For each discontinued product URL:

1. If the product has backlinks — redirect 301 to the most relevant active product or category page
2. If the product has organic traffic — redirect 301 to the category page and monitor for ranking transfer
3. If the product has neither links nor traffic — redirect 301 to the parent category (not the homepage)
4. If the entire category was removed — redirect all products in that category to the nearest remaining category

Never return a 404 for a page that had external links pointing to it. That link equity evaporates.

Category Restructuring During Migration

If you're restructuring your category taxonomy during migration — collapsing subcategories, renaming categories, adding new category levels — map the redirect chain carefully.

Old: /shoes/mens/running/trail redirects to new /collections/mens-trail-running-shoes

This works. What doesn't work: redirect chains where /shoes/mens/running/trail redirects to /shoes/mens/running which redirects to /collections/mens-running which redirects to /collections/mens-trail-running-shoes. Each hop in a redirect chain loses authority and increases crawl latency. Keep redirects to a single hop.

Regex Patterns for Common Migrations

For large catalogs, individual redirect mapping isn't practical for every URL. Use regex patterns for predictable URL transformations:

• Magento to Shopify: /catalog/product/view/id/[id]/ to /products/[handle] — requires a lookup table mapping Magento product IDs to Shopify handles
• WooCommerce to BigCommerce: /product/[slug]/ to /[slug]/ — straightforward path simplification
• Shopify to headless: /collections/[handle] to /shop/[handle] — simple path prefix swap

Test regex patterns against your full URL list before deploying. A regex that works for 95% of URLs but breaks 5% will create thousands of broken redirects you won't discover for weeks.

Technical SEO Preservation Checklist

Beyond URLs and redirects, a platform migration can silently break technical SEO elements that took years to build. This section covers each one.

Canonical Tags

The new platform must implement self-referencing canonical tags on every page. Verify:

• Product pages canonicalize to the main product URL (not variant URLs with parameters)
• Collection pages canonicalize correctly, especially when filters or sort parameters modify the URL
• Paginated pages (page 2, page 3 of collections) handle canonicalization properly — either self-referencing with rel=prev/next or canonicalizing to page 1 depending on your strategy
• Blog post URLs with and without trailing slashes resolve to the same canonical

Hreflang Tags (International Stores)

If you operate multiple storefronts by country or language, hreflang implementation must survive the migration. Common failure points:

• Hreflang tags pointing to old domain URLs after migration
• Missing hreflang self-references on the new platform
• Country-specific storefronts that were subdirectories (/uk/, /de/) becoming subdomains (uk.store.com) — requires updating hreflang across all storefronts simultaneously

Structured Data Migration

Compare the structured data output of the old site against the new site for every page template:

Page Type	Required Schema	Common Migration Failures
Product pages	Product, Offer, AggregateRating, Review, BreadcrumbList	Missing aggregateRating (reviews didn't migrate), incorrect price format, missing availability
Collection pages	ItemList, BreadcrumbList	Missing ItemList for product grids, broken breadcrumbs reflecting old category hierarchy
Blog posts	Article, BreadcrumbList	Missing author information, incorrect datePublished (set to migration date instead of original)
Homepage	Organization, WebSite, SearchAction	Missing SearchAction for sitelinks search box, incomplete Organization schema

Sitemap Updates

The new platform must generate an XML sitemap that:

• Includes all live product, collection, blog, and content page URLs
• Excludes redirected, noindexed, and canonicalized-away URLs
• Updates dynamically as products are added or removed
• Is submitted to Google Search Console on the new property within 24 hours of launch

Robots.txt

Verify the new platform's robots.txt doesn't accidentally block critical paths. Common mistakes:

• Blocking /collections/ filter pages that should be crawlable
• Blocking /cart, /checkout, and /account (these should be blocked — verify they are)
• Missing sitemap reference in robots.txt
• Overly aggressive crawl-delay directives

Also verify that AI crawlers (GPTBot, ClaudeBot, PerplexityBot) are not blocked. If your old robots.txt allowed them and the new platform's default robots.txt blocks them, you've just removed yourself from AI search indexes. This matters for AEO optimization — brands visible to AI search tools have an additional discovery channel that blocked brands forfeit entirely.

Internal Link Audit

Internal links break silently during migrations. Every internal link on the site — in navigation, in product descriptions, in blog posts, in footer links — needs to point to the new URL structure. Common failure points:

• Blog posts with hardcoded links to old product URLs
• Product descriptions linking to old category pages
• Footer and navigation links not updated
• Sitemap links pointing to old URLs

Run a crawl of the staging site before launch and fix every broken internal link before going live.

Headless Commerce: SSR, SSG, and the JavaScript Rendering Problem

Headless commerce — Shopify Hydrogen, Next.js Commerce, custom builds with a headless CMS — introduces SEO complexity that traditional platforms handle by default. If you're migrating to headless, this section is mandatory reading.

The JavaScript Rendering Problem

When Google crawls a page, it first processes the raw HTML (the “first wave” of indexing). JavaScript-rendered content gets processed later in a “second wave” that can be delayed by hours or days. If your headless storefront renders product information, pricing, reviews, and structured data entirely via client-side JavaScript, Google may index an empty shell.

This is not theoretical. Brands that migrate to headless without server-side rendering frequently discover — weeks later — that Google deindexed thousands of product pages because the initial HTML contained no meaningful content.

SSR vs. SSG vs. ISR for Ecommerce

Rendering Strategy	SEO Impact	Best For	Trade-offs
Server-Side Rendering (SSR)	Full HTML on every request. Google crawls complete content immediately.	Pages with frequently changing data: pricing, inventory, personalized content	Higher server costs, slower TTFB under load, requires robust caching layer
Static Site Generation (SSG)	Pre-rendered HTML served from CDN. Fastest TTFB, fully crawlable.	Content pages, blog posts, category pages with stable content	Build times grow with catalog size. 10,000 products = long build times. Stale data between builds.
Incremental Static Regeneration (ISR)	Pre-rendered with background updates. Best of SSR and SSG for dynamic catalogs.	Product pages with moderate update frequency (daily price/inventory changes)	Complexity in cache invalidation. Stale pages possible between regeneration windows.
Client-Side Rendering (CSR)	Relies on Google's JavaScript rendering. Delays indexing. High risk.	Authenticated pages only (account, cart, checkout)	Never use for product, collection, or content pages. Organic visibility at risk.

For Next.js-based headless builds, the recommended approach is ISR for product pages (revalidating every few hours) and SSG for category pages, blog posts, and static content. This gives you the crawlability of static HTML with the freshness of server-rendered data.

Edge-Side Rendering

Edge rendering (Vercel Edge Runtime, Cloudflare Workers) serves HTML from the nearest CDN node with server-side logic. For ecommerce, this means fast TTFB globally while still rendering dynamic pricing and inventory server-side. It's the emerging best practice for headless commerce SEO — but it requires the development investment to implement correctly.

Headless Migration SEO Checklist Additions

Beyond the standard migration checklist, headless builds require:

• Verify Google can render your pages — use Google Search Console's URL Inspection tool on the staging site (via a temporary public URL) before launch
• Ensure structured data is in the initial HTML — not injected via JavaScript after page load
• Implement proper meta tags server-side — title, description, canonical, OG tags must be in the initial HTML response
• Handle pagination server-side — infinite scroll with client-side rendering breaks Google's ability to discover products deep in collection pages
• Build XML sitemaps programmatically — headless platforms don't auto-generate sitemaps like Shopify or BigCommerce

Post-Launch Monitoring: The First 30 Days

The migration isn't done at launch. The first 30 days determine whether your SEO investment survives.

First 24 Hours

• Crawl the entire live site with Screaming Frog. Flag any 404s, redirect chains, or pages returning unexpected status codes.
• Verify all 301 redirects are working by testing a random sample of 100 old URLs.
• Submit the new sitemap to Google Search Console. Request indexing for your top 50 pages.
• Check robots.txt on the live site (not staging) to confirm it matches your intended configuration.
• Verify structured data using Google's Rich Results Test on key page templates.
• Monitor Core Web Vitals — a new platform with slower page load times will compound the migration's ranking impact.

First Week

• Monitor indexed page count in Search Console daily. A sudden drop indicates crawl or redirect issues.
• Track keyword rankings for your top 100 terms. Expect some fluctuation — a 5-10 position drop in the first week is normal. A 20+ position drop for multiple keywords signals a redirect or canonical problem.
• Check Google Merchant Center if you run Shopping ads. Product feed URLs that changed need to be updated, and disapproved products need immediate attention.
• Monitor 404 errors in Search Console. New 404s appearing after migration indicate missing redirects.
• Verify Google Shopping feed accuracy — product URLs, image URLs, pricing, and availability must all point to the new site.

First Month

• Compare organic traffic week-over-week against the pre-migration baseline. Expect a 10-20% dip in the first two weeks, recovering to within 5% of baseline by week four. If you're still 20%+ below baseline after four weeks, investigate specific page types losing traffic.
• Monitor crawl stats in Search Console. Google should be crawling the new site at a similar rate to the old site within two weeks. If crawl rate drops significantly, check for robots.txt issues or server performance problems.
• Track featured snippets and rich results — these are often the first to disappear after migration and the slowest to return.
• Run a comprehensive backlink check — verify your top 100 backlinked pages are resolving correctly through the redirect chain.

Common Migration Disasters and How to Prevent Them

These are real failure patterns we've observed. Each one is preventable with the right pre-migration work.

Disaster 1: The Mass Homepage Redirect

What happens: The agency or dev team redirects every old URL that doesn't have an exact match on the new site to the homepage. Google treats mass homepage redirects as soft 404s — the link equity effectively evaporates.

How to prevent it: Every URL gets a destination-specific redirect. Discontinued products go to their parent category. Removed blog posts go to the most relevant remaining blog post. The homepage is never a redirect target except for old homepage URLs.

Disaster 2: The Staging Site Goes Live Without noindex Removal

What happens: The new site was built on a staging subdomain with noindex meta tags to prevent premature indexing. At launch, someone forgets to remove the noindex tags. Google dutifully deindexes the entire site within days.

How to prevent it: Add a launch-day checklist item: verify that no page on the live site returns a noindex directive. Check both the meta robots tag and the X-Robots-Tag HTTP header.

Disaster 3: The HTTP/HTTPS Mismatch

What happens: The old site ran on HTTP. The new site runs on HTTPS (as it should). But the redirect map only covers path changes, not protocol changes. Old HTTP URLs return 404s instead of redirecting to the HTTPS equivalent.

How to prevent it: Implement a blanket HTTP-to-HTTPS redirect at the server level, independent of your URL-specific redirect map. Then layer your path-specific redirects on top.

Disaster 4: The Canonical Tag Catastrophe

What happens: The new platform's default theme includes canonical tags that point to incorrect URLs — often the staging domain, or a URL with parameters, or a URL without the correct trailing slash handling. Google follows the canonical and deindexes the actual page.

How to prevent it: Audit canonical tags on every page template of the staging site. Verify they point to the correct production URLs with the correct protocol, domain, and path.

Disaster 5: The Review Data Loss

What happens: Customer reviews stored in the old platform's native review system (Shopify Reviews, Magento native reviews) don't migrate to the new platform. Thousands of product pages lose their review content, aggregateRating schema, and the unique SEO content those reviews provided.

How to prevent it: If you're changing review platforms during migration, export all review data from the old system before decommissioning it. Work with the new review provider (Yotpo, Judge.me, Okendo, Stamped) to import historical reviews before launch.

Disaster 6: The Forgotten Blog

What happens: The migration focuses entirely on product and collection pages. The blog — which may drive significant organic traffic for informational queries — either doesn't migrate, migrates without redirects, or migrates with broken internal links throughout every post.

How to prevent it: Include blog content in your URL inventory from day one. Map every blog post URL. Audit every internal link within blog posts to ensure they point to new URLs.

How to Evaluate SEO Impact Before Committing to Migration

Not every replatforming is worth the SEO risk. Before committing engineering resources, run this evaluation.

Step 1: Quantify Your Organic Revenue at Risk

Calculate the revenue attributed to organic search over the past 12 months. Use GA4's channel grouping or your attribution platform. This is the maximum downside if the migration goes badly.

For a $15M DTC brand where organic drives 30% of site sessions and converts at 2.5% with a $75 AOV, the annual organic-attributed revenue is roughly $2.8M. A 30% traffic drop for three months during a botched migration costs approximately $210K in direct organic revenue — plus the paid media spend required to backfill the lost traffic.

Step 2: Map Platform Limitations to URL Impact

Identify every URL that will necessarily change due to the new platform's URL structure. Count them. Each changed URL is a redirect that carries incremental risk.

Migration Path	URL Impact Level	SEO Risk
Magento to Shopify	High — Shopify forces /products/ and /collections/ paths	High — most category and product URLs will change
WooCommerce to BigCommerce	Low — BigCommerce supports custom URL paths	Low-Medium — URLs can be preserved if planned
Shopify to Shopify Plus	None — same URL structure	Minimal — focus on theme performance, not URLs
Any platform to headless	Variable — you control URL structure	Medium-High — depends on SSR implementation and redirect accuracy
Magento to BigCommerce	Low — URL preservation possible	Low-Medium — fewer forced URL changes
Shopify to headless (Hydrogen/Next.js)	Variable — can replicate Shopify paths or restructure	Medium — depends on rendering strategy and redirect completeness

Step 3: Estimate Recovery Timeline

Based on the number of URL changes, the current site's authority, and the redirect implementation quality:

• Minimal URL changes + clean redirects: 2-4 weeks to baseline
• Moderate URL changes + clean redirects: 4-8 weeks to baseline
• Major URL changes + clean redirects: 8-16 weeks to baseline
• Any URL changes + broken redirects: 3-12 months, depending on severity

Step 4: Build the Business Case

Compare the migration's expected benefits (faster site speed, better checkout conversion, reduced hosting costs, new functionality) against the SEO risk. If the migration will improve conversion rate by 15% but organic traffic will drop 20% for three months, the net revenue impact over 12 months might be positive — but only if the redirect strategy is executed correctly.

This calculation should happen before the migration is approved, not after the dev team is three months into the build.

---

We help ecommerce brands protect their organic traffic during platform migrations and build ecommerce SEO strategies that compound across both Google and AI search. If you're planning a replatform, start with a conversation.

---

The Complete Platform Migration SEO Checklist

This is the consolidated checklist. Print it. Share it with your dev team, your agency, and your platform vendor. Every item should have an owner and a completion date before launch.

Pre-Migration (4-8 Weeks Before Launch)

1. Export complete URL inventory (all indexed URLs)
2. Export backlink profile with page-level link equity mapping
3. Record indexed page count baseline in Search Console
4. Document all canonical tags by page template
5. Export structured data for every page template
6. Snapshot current keyword rankings (top 200+ keywords)
7. Inventory all non-product content (blog, landing pages, policy pages)
8. Export customer reviews from current platform
9. Build 1:1 redirect map (old URL to new URL, every page)
10. Define handling for discontinued products (redirect destinations)
11. Map internal links in blog posts and content pages to new URLs
12. Verify new platform's robots.txt configuration
13. Generate new XML sitemap on staging
14. Test structured data output on new platform's page templates
15. For headless: verify SSR/SSG renders full HTML for Google

Launch Day

16. Deploy redirects before DNS cutover
17. Remove noindex tags from all live pages
18. Verify HTTP-to-HTTPS redirect at server level
19. Submit new sitemap to Search Console
20. Request indexing for top 50 pages
21. Full crawl of live site (Screaming Frog or equivalent)
22. Test 100 random old URLs for correct redirect behavior
23. Verify canonical tags on every page template (production domain)
24. Confirm Google Merchant Center product feed URLs are updated
25. Verify AI crawler access (GPTBot, ClaudeBot, PerplexityBot) via robots.txt

Post-Launch (First 30 Days)

26. Monitor indexed page count daily for first two weeks
27. Track keyword rankings daily for top 100 keywords
28. Monitor 404 errors in Search Console and fix immediately
29. Compare organic traffic week-over-week against baseline
30. Check crawl rate in Search Console (should match pre-migration within 2 weeks)
31. Verify featured snippets and rich results are returning
32. Audit top 100 backlinked pages for correct redirect resolution
33. Monitor Core Web Vitals for any degradation
34. Check Google Merchant Center for disapproved products
35. Run a structured data validation on key page templates

Platform migrations don't have to be SEO disasters. With the right pre-migration audit, a comprehensive redirect strategy, and disciplined post-launch monitoring, you can replatform without surrendering the organic traffic that took years to build. The brands that treat SEO as a migration workstream — not an afterthought — are the ones that come out the other side stronger.

Ready to protect your organic traffic during a platform migration? Talk to us about ecommerce SEO strategy.