Why do migrations lose traffic?

Three causes account for nearly all of it: URLs that changed without redirects, metadata and content that didn't survive the move, and technical regressions on the new platform (canonicals, schema, internal links, page speed). None of these are mysterious. All of them are preventable with an inventory taken before anything moves.

Phase 1 — Before: inventory everything

  1. Crawl the current site completely. Every URL — products, categories, content pages, images that rank, PDFs. This crawl is your source of truth; take it before anyone touches anything.
  2. Export analytics and Search Console baselines. Twelve months of organic landing pages, queries, and conversions. You can't diagnose a post-launch dip against data you didn't keep.
  3. Rank the URL inventory by value. Traffic × revenue per page. The top slice gets hand-checked redirects; the long tail gets pattern rules.
  4. Inventory metadata and content. Titles, meta descriptions, H1s, category copy, alt text, review content, and structured data. Migration tools move products; they routinely drop the SEO layer around them.
  5. Map the URL architecture decision. BigCommerce supports fully custom URLs — you can usually preserve existing paths exactly, which turns thousands of redirects into zero. Decide per URL class: preserve, or change-with-301. Changing structure "while we're at it" is how migrations double their risk.

Phase 2 — During: build the new store right

  1. Keep staging out of the index. Password-protect or noindex the staging store. A crawlable staging site competes with your live one and leaks the launch.
  2. Build the 301 map. Old URL → new URL, one hop, no chains. Pattern rules for structural changes, hand-mapped rows for the high-value slice. Redirect to the equivalent page — a product 301'd to the homepage is a soft 404 in Google's eyes.
  3. Carry the metadata. Titles, descriptions, and category copy land with their pages. Verify on the rendered staging pages, not in the import spreadsheet.
  4. Re-implement schema. Product markup (price, availability, brand, SKU, ratings), BreadcrumbList, Organization. Validate the rendered output — this is a classic silent-loss item.
  5. Check canonicals and faceted navigation. Platform defaults differ. Confirm category filters canonicalize correctly on BigCommerce and that your theme didn't override it (we wrote a separate guide on faceted navigation SEO).
  6. Rebuild internal links. Menus, footer links, in-copy links, and merchandising blocks should point at final URLs — not at old paths that bounce through your own redirects.
  7. Benchmark performance. The new theme should beat the old site's Core Web Vitals, not inherit its carousel bloat. (Our target on Stencil builds is Lighthouse 95+ — the Stencil performance guide covers how.)

Phase 3 — Cutover: launch day

  1. Deploy the 301 map with the DNS change, not after it. The gap between "new site live" and "redirects live" is measured in lost rankings.
  2. Remove the noindex. Obvious, and still the most famous way to zero out a launch. Check the rendered homepage and a sample of PDPs within the hour.
  3. Submit the new sitemap in Search Console and keep the property continuity (same domain = same property; domain changes need Change of Address).
  4. Spot-check the top-100 URL list live. Old URL → 301 → correct new page, one hop, 200 status.

Phase 4 — After: the 90-day watch

  1. Monitor 404s daily for the first two weeks. Search Console's Not Found report and server logs surface the redirects you missed; patch them while it's cheap.
  2. Watch "Page indexing" for canonical surprises — duplicate clusters and "crawled, not indexed" spikes mean a template problem, not a Google problem.
  3. Compare landing-page traffic against the baseline you exported in Phase 1, page class by page class. A dip isolated to one template is diagnosable; "traffic is down" isn't.
  4. Hold the old redirect map for at least a year. Redirects aren't a launch-week feature; equity transfers over months.

This checklist is the SEO half of a migration. The data half — products, customers, orders, ERP wiring — is its own discipline, and both live inside our migration service. Platform-specific notes: Shopify, Magento, WordPress/WooCommerce.