Ecommerce SEO Migration Checklist: Protect Discovery When Moving Platforms

A new ecommerce platform can improve operations, but moving an incomplete catalogue does not automatically improve search performance. An SEO migration needs an inventory, a tested destination for important URLs and a release plan that protects the customer's route to useful products. A redesigned homepage is only one part of that work.

This checklist uses a hypothetical home-office store selling lamps, keyboards and desk accessories. It is a planning framework, not a promise of unchanged rankings. First decide whether the move solves a real constraint. If the problem is missing product information or unclear ownership, a different platform may carry the same problem into a more expensive project.

Define the move before estimating the work

Record what will change: domain, URL paths, platform, theme, catalogue structure, content, hosting or all of them. These changes have different risks. Moving to a new theme on the same URLs is not the same project as replacing the domain and every product path.

Use the ecommerce platform comparison to identify requirements the proposed system must demonstrate. Include awkward products, variants, regional selling conditions and existing editorial content. Do not approve a move based only on a clean demonstration catalogue.

Assign a release owner, rollback decision-maker and people responsible for catalogue data, redirects, analytics and customer support. Write down what “ready” means before launch day. A deadline is not a substitute for agreed acceptance criteria.

Inventory the current website from several sources

Collect important URLs from a crawl, sitemap, analytics, Search Console and the catalogue where available. Include guides, categories, products, images and useful support documents. No single source necessarily contains every address customers or search engines know.

For each URL, record its purpose, current response, important content and intended future state. Keep original titles, descriptions and product information as reference material. Preserve dated exports in a project folder rather than relying on a live system that may be replaced during the move.

Prioritise the pages that matter to customers and the business, but do not confuse prioritisation with permission to ignore the rest. A low-traffic manual may still be essential to existing owners, while a seasonal product may look unimportant in an off-season report.

Build the mapping before building redirects

Map each changed URL to its most relevant new destination. Preserve a useful page's purpose and content where possible. Do not map every removed product to the homepage or one broad collection simply because that is easy to implement.

Google's site-move documentation recommends preparation, URL mapping, redirects and monitoring. It advises keeping redirects for as long as possible, generally at least a year. Treat this as continuing infrastructure, not a temporary launch-day patch.

Use explicit mapping statuses: unchanged, moved, retained as reference or removed without replacement. Have the catalogue owner approve ambiguous cases. A redirect file should be the output of those decisions, not the place where an engineer is forced to guess them.

Check platform-specific redirect rules early

The destination platform may restrict which paths can be redirected or how valid existing pages are handled. Shopify's redirect documentation describes its rules, including reserved paths and existing-page behaviour. WooCommerce's permalink documentation explains configurable product and taxonomy structures.

Test the actual proposed setup rather than assuming a feature works identically on every platform. Use a sample containing old product URLs, categories, guides and unusual characters or parameters. Confirm the final response and destination, including trailing-slash and hostname variations where relevant.

Avoid unnecessary URL changes purely for visual neatness. A shorter address may not justify the extra mapping, testing and maintenance it creates. Preserve stable paths when the new platform can support them sensibly.

Protect content and product relationships

Check more than product counts after import. Compare names, specifications, images, alt text, variants, prices, availability and relevant documents. A successful import can still put the wrong photograph on a colour variant or separate a product from its category.

Move useful guides with their contextual links. Update links to final destinations so visitors do not travel through avoidable redirect chains. The internal-linking guide helps review the relationship between editorial content, categories and products.

For the home-office example, a desk-lamp buying guide should still connect to a relevant lighting range and accurate product specifications. Do not replace it with a generic collection introduction and assume the original information survived because the URL redirects somewhere.

Test discovery signals in the new environment

Review canonical URLs, indexability, robots directives, sitemap contents and structured data. Check that production output does not retain development hostnames or accidental noindex instructions. At the same time, keep the development environment protected until it is intended to be public.

Inspect representative rendered pages, not only configuration files. A theme, app or caching layer can produce output that differs from the settings screen. Include product variants, pagination, empty categories and retired products in the sample.

If the domain changes, review Search Console's applicable site-move procedures and ownership requirements. Do not assume every migration needs the same tools. A path change on the same domain has different administrative steps from a domain move.

Run the customer journey before announcing the store

Open the new site on a small phone and desktop. Test navigation, product selection, basket and the supported checkout path in an appropriate test mode. Check search, filters and back navigation, including products reached from old URLs.

Keep payment and order testing controlled. Use the platform's test facilities and authorised procedures rather than creating unintended real transactions. Confirm that support links, delivery information and return policies match the business's actual operation.

Preserve measurement configuration where appropriate, then verify the events rather than assuming an imported identifier proves tracking works. A purchase event must not fire when someone merely views a product or clicks a link. Keep observed orders distinct from website interactions.

Launch with a bounded acceptance checklist

Use this checklist as a release gate:

1. Confirm the migration scope, owners, backups and rollback criteria.
2. Preserve a dated inventory of URLs and important page information.
3. Approve every changed URL's relevant destination or removal decision.
4. Test redirects directly and avoid chains or broad irrelevant mappings.
5. Compare imported product data, variants, images and useful guides.
6. Verify production canonicals, indexability, sitemap and structured data.
7. Test mobile navigation, filtering and the authorised transaction flow.
8. Check measurement events against the actions they actually represent.
9. Monitor errors and search activity after release, with owners assigned to exceptions.

Plan a post-launch review cadence appropriate to the store. Inspect old URL samples, new page responses, unexpected not-found reports and catalogue issues. Keep the old-to-new mapping accessible to support staff as well as developers.

Expect that search systems need time to process changes. Compare dated baselines while considering seasonality, promotions, stock and measurement changes. A successful deployment proves the site was released; it does not establish indexing, ranking recovery or extra revenue.

Improve your ecommerce SEO with 1Rank

Explore 1Rank's SEO workflow to organise website priorities before and after a platform move. Create your 1Rank account to begin with the available website baseline, then review the scope of paid ongoing services. Registration does not activate a paid plan. A migration still needs platform-specific testing and an accountable release owner; rankings, traffic and recovery dates are not guaranteed.

Frequently asked questions

Should I redesign, rewrite and change domains at once?

Only when the benefits justify the combined risk and the team can test the changes properly. Separating changes can make problems easier to identify. Document what is moving and why instead of treating every improvement as part of one unavoidable release.

Can I redirect all old products to the homepage?

That is not a useful default. Map to genuinely relevant replacements where they exist, retain valuable information where appropriate and make explicit removal decisions for the rest. A working redirect is not sufficient if its destination does not answer the original request.

Will a migration preserve every ranking?

No responsible checklist can guarantee that. Testing reduces avoidable mistakes, but search systems reassess changed pages and wider conditions still matter. Keep accurate baselines, monitor the release and investigate evidence rather than promising a fixed recovery timeline.