Ecommerce SEO

The migration checklist that protects organic revenue

Platform and domain migrations lose organic revenue through missed redirects, dropped content and untested launches. The checklist that prevents each of those.

By CartKernel · Published September 6, 2026

Migrations lose organic revenue in four predictable ways. URLs change without a redirect. Content that ranked is dropped in the rebuild. Technical settings that were right on the old platform are different on the new one. And the launch goes out with a development setting still switched on. Each is preventable, and the prevention is a checklist run in a fixed order. This is ours, organised around revenue rather than traffic: the pages that earn money get the most scrutiny, and the pages nobody visits get a pattern rule.

Know which URLs earn money before anything is built

The first deliverable of a migration is a spreadsheet, not a design. Build it before the new platform is chosen if you can.

Export twelve months of organic sessions and revenue by landing page from GA4.
Export clicks, impressions and average position by page from Search Console for the same period.
Crawl the live site completely, including images, PDFs and paginated URLs, and capture the title, meta description, H1, canonical, robots meta, structured data types, hreflang and word count for each URL.
Pull referring domains per URL from your link tool.
Merge all four on the URL and sort by organic revenue, then by clicks, then by referring domains.

Every URL with revenue, clicks or links gets a one-to-one mapping to a new URL, decided by a person. The long tail with none of the three can follow a pattern rule. Record the ranking positions of the top few queries per template as well, because after launch you need to know whether a category term slid three places or thirty.

Map every URL, including the ones you would rather forget

The redirect map covers more than products and categories.

Products. Handle and slug rules differ between platforms. Shopify handles are lowercase with hyphens, and a WooCommerce slug with accented characters or underscores will not carry across untouched. Generate the new handle from the import, then diff it against the pattern you expected.
Categories and collections. Include the paginated URLs. /category/boots/page/3/ should redirect to the new boots page, not return a 404.
Filter URLs that got indexed. Redirect them to the parent category, or to the new landing page if the filter was worth one.
Blog posts, images and PDFs. Image URLs that rank in image search and PDFs linked from forums are missed on most migrations.
Existing redirects. The old site already has redirects from an earlier migration. Point their sources straight at the final destination so you do not build a chain.
Discontinued products. Redirect to the nearest category or the replacement product. Sending everything to the homepage is treated as a soft 404 and passes nothing.

Google’s guidance on site moves asks for permanent redirects, one hop, from every old URL to its equivalent. The redirects documentation explains which redirect types count as permanent. Whether a page that is out of stock should exist at all after the move is a separate decision, covered in should out-of-stock product pages be deleted.

Carry the content, not just the pages

A rebuild that recreates the page but not what was on it loses the rankings the content earned. Check parity for:

Category introductions and buying guidance, including anything a plugin rendered that the new platform has no equivalent for, such as size guides and comparison tables.
Product descriptions, specification tables and the fields feeding structured data.
Reviews, migrated with their product association so aggregate ratings return.
Titles, meta descriptions and image alt text, exported from the crawl and imported as fields, not retyped.
Internal links inside content, updated to the new URLs. A body link that points at an old URL works through the redirect but wastes a hop on every crawl.
Primary category for products filed in more than one, so breadcrumbs and canonicals agree.

Technical parity, item by item

The new platform makes different default decisions from the old one. Go through them on staging and write down the answer for each.

Item	What to confirm on staging
Canonicals	Self-referencing on products, categories and paginated pages; filtered URLs pointing to the base (canonical tag)
robots.txt	Sort, search and filter parameters handled; nothing important blocked
Sitemap	Contains only indexable URLs; excludes noindexed templates
Not-found pages	Return a 404 status, not a 200 with an error message
Hreflang	Every language and market pair present and reciprocal (hreflang)
Structured data	Product, BreadcrumbList and Organization present and valid
Rendering	Product content in the HTML source, not injected after load
URL hygiene	One case, one trailing-slash rule, one hostname
Speed	Product and category templates measured on mobile before launch

Staging must be unreachable to crawlers. Password protection is safer than a noindex tag, because a noindex left in place on launch day is the most common way a migration loses its first two weeks.

Feeds, ads and tracking move on the same day

Search is not the only channel that depends on URLs. On launch day these switch too, and each one needs an owner.

Merchant Center. The feed’s link and mobile_link values must point at the new URLs and match the page canonical, or products are disapproved for landing page mismatches. If the feed source changes with the platform, set the new feed up in advance and switch at launch. The Merchant Center diagnostics page explains how to read the first day’s disapprovals.
Google Ads and Meta. Final URLs in campaigns, the Meta catalogue source, and any affiliate or email links that hardcode a URL.
Analytics. The data layer is rebuilt on the new platform, and the purchase event is the one to test with a real order before launch. GA4 purchase event not firing lists the usual reasons it does not.

Launch day, in order

Freeze content changes on the old site two days out, so the redirect map matches what is live.
Run the final import of products, customers and order history.
Switch DNS and confirm the certificate.
Remove the staging password, check robots.txt on the live domain, and confirm no template still carries a noindex.
Crawl the full list of old URLs and confirm each returns a permanent redirect to the mapped URL, which itself returns 200.
Submit the new sitemap. If the domain changed, use the change of address tool in Search Console; if only the paths changed, you do not need it.
Place a test order and confirm it appears in GA4, Google Ads and the feed fetch in Merchant Center.
If the domain changed, keep the old domain’s hosting live to serve the redirects. Google’s site move documentation recommends keeping them in place for at least a year.

The first month

Daily for the first week: the 404 log, redirect errors in Search Console, crawl stats, index coverage and Merchant Center diagnostics. Weekly for the month: rankings on the benchmark set by template, and organic revenue by landing page against the pre-migration baseline, compared page pair by page pair rather than in total. Some movement is normal while Google recrawls and reprocesses; Google’s documentation describes that period in weeks for a medium-sized site and longer for a large one. A drop that goes beyond that, or one template that falls while the others hold, is a defect in the map or the parity checks, and organic traffic dropped after migration walks through finding it.

How long the whole thing takes

The mapping and parity work is most of the calendar time, and it runs in parallel with the build. How long does a Shopify migration take gives honest ranges by catalogue size, and does migrating platforms hurt SEO sets expectations for the dip and the recovery. We run migrations as one project across development and SEO because the two cannot be separated without one of them losing; the platform migration service describes how that works.