Ecommerce Replatforming SEO Checklist: Migrate Without Losing Visibility
An ecommerce replatforming SEO checklist is a plan for moving a store to a new platform without losing the search visibility it earned. It covers the redirect map, page parity, internal links, the sitemap, launch-day checks and the monitoring that follows.
- 301 redirect map
- Page parity table
- Launch-day checks
- Post-launch monitoring
An ecommerce replatforming SEO checklist is a step-by-step plan for moving an online store to a new platform, theme or URL structure without losing the search visibility the old store earned. It covers the redirect map, the titles, descriptions and structured data that must carry over, the internal links, the sitemap, the checks on launch day and the monitoring afterwards.
A migration does not fail because the new platform is worse. It fails because something that search engines relied on quietly disappeared: a set of URLs without redirects, a noindex tag left on from staging, titles replaced by defaults, or category pages that lost their descriptions. Almost all of those are preventable with a plan and a few hours of checking at the right moments.
This guide follows the order in which I would run a migration. Where a point is my judgment rather than a rule, I say so, and I make no promise about how rankings will behave afterwards.
I review migration plans before launch and check the new site against the old one, so the redirect map and the page data are right the first time.
Talk to an Ecommerce SEO ConsultantWhat a Replatform Actually Changes for Search
A replatform can change four things at once, and each is a separate risk. The URLs may change. The templates and markup may change. The content may be rebuilt or trimmed. The server and the way pages are rendered may change. Search engines have to relearn all of it.
My own preference, and it is a judgment, is to change as few things as possible in the same launch. If the content rewrite can wait until after the move, it usually should. That way, if something goes wrong, there are fewer suspects.
Before You Build: Record the Old Site
You cannot check parity with a site you did not record. Before development ends, capture the following from the live store.
- A full crawl of the live site with every URL, status code, title, meta description, H1, canonical, robots directive and internal link count.
- The list of URLs that get organic traffic and the pages that earn links, from Search Console and your link data.
- The current XML sitemaps and robots.txt, saved as files.
- Screenshots or exports of structured data for a sample of each template.
- Rankings and organic clicks for your main category and product terms, dated, so you can compare later.
- Analytics and tag settings, so tracking is not lost in the move.
Save the crawl somewhere safe. After launch it becomes the reference you compare against.
The 301 Redirect Map
The redirect map is the most important document in the project. It lists every old URL and the new URL a visitor and a search engine should land on. A 301 redirect is the status code for a permanent move, and it is how you tell search engines that the old page has a new home.
Build it from the crawl, the sitemap and the pages with traffic or links, not from the new site’s list of pages. The old site is the source of truth for what needs a destination.
| Old URL type | Where it should go | Watch out for |
|---|---|---|
| Product that still exists | The matching product on the new platform | Changed handles or SKUs breaking the match |
| Product that is gone | The closest equivalent product or category | Sending everything to the home page, which search engines may treat as a soft 404 |
| Category or collection | The matching category | Merged or split categories that need a decision |
| Filtered or parameter URLs | The parent category, or let them drop | Mapping thousands of parameter URLs one by one |
| Blog posts and guides | The same post on the new site | Changed dates or paths in the blog structure |
| Images and documents with links | The new file location, where they earned links | Forgetting media that other sites link to |
Avoid redirect chains. If an old URL redirects to a URL that redirects again, point the old URL at the final destination directly. Test the map in bulk before launch against a staging copy, using a crawler in list mode with the old URLs.
Parity: What Must Carry Over
Parity means that, for each page, the things search engines used to see are still there on the new site unless you chose to change them. Compare old and new page by page for each template, using the crawl you saved.
| Element | What to compare | Common failure |
|---|---|---|
| Title tag and meta description | Same text, or a deliberate improvement | Platform default titles replace the custom ones |
| H1 and body copy | Category intros, product descriptions, guides | Category descriptions dropped in the new theme |
| Canonical tags | Self-referencing on indexable pages | Canonicals pointing at staging or at the wrong URL |
| Robots directives | Indexable pages have no noindex | The staging noindex or password left on |
| Structured data | Product, breadcrumb, organization output | Missing fields, duplicated markup, wrong price |
| Internal links | Navigation, breadcrumbs, related products, footer | Links to old URLs that now redirect |
| Images and alt text | File names and alt text | Missing alt text, images behind scripts |
| Hreflang and markets | Language and country versions | Pointers to URLs that no longer exist |
| Pagination | Paged category URLs are crawlable | Pages that load only by scrolling script |
Parity does not mean copying mistakes. If the old titles were weak, improve them, but do that as a separate, tracked change so you can tell it apart from migration effects.
Staging: Test Without Exposing It
Keep the staging site out of search results while you test. Password protection is the safest way, because a noindex tag alone only works if the page can be crawled and the tag is read. Whatever you use, write down how it is removed at launch, because staging protection that travels to production is one of the most common launch mistakes.
Test on staging with the same crawler settings you used on the live site. Check status codes, redirects, canonicals, titles, structured data and robots directives against the saved crawl, and send every difference to the developers before launch day.
Launch Day: The First Hours
Have your developer and the person doing the SEO checks available at the same time. These are the checks I would run first, in this order.
- 1Is the live site open to search engines? No password, no noindex, robots.txt does not disallow the siteAny staging protection left on is an emergency
- 2Do the redirects work? Old URLs return one 301 to the right new pageChains, loops or redirects to the home page need fixing
- 3Do key pages look right? Titles, canonicals, structured data and internal links match the planDefaults or staging URLs in the markup
- 4Are the sitemap and robots.txt right? Sitemap lists only live, indexable, canonical URLsOld URLs or redirected URLs in the sitemap
- 5Is tracking working? Analytics and conversion events record on the new siteMissing tags make the comparison impossible
Submit the new sitemap in Search Console and use the URL Inspection tool on a sample of important pages. If the domain changed, use the Change of Address tool as Google’s site move guidance describes.
After Launch: What to Monitor
Search engines need time to recrawl and reprocess a site, and I cannot tell you how long that will take for yours. What you can do is watch the right signals and fix problems early.
| Signal | Where to look | What a problem looks like |
|---|---|---|
| Indexing | Page indexing report in Search Console | Important pages excluded or marked as duplicates |
| Crawl errors | Crawl stats and a fresh crawl | Growing 404s or server errors |
| Redirects | A re-run of the old URL list | Old URLs no longer redirecting, or chains forming |
| Search performance | Performance report compared with your dated baseline | Sharp losses concentrated on one template or section |
| Structured data | Merchant listings and Product snippets reports | New errors or warnings after the move |
| Speed | Core Web Vitals report | Template regressions on product or category pages |
Compare against the baseline by section, not just in total. A loss that sits in one template points straight at the cause, while a total hides it. Keep a log of what you changed and when, so that later fixes do not blur the picture.
Frequently Asked Questions
Will my rankings drop after a replatform?
Some movement is common after a migration, and no one can promise how large it will be or how long it will last. The risk is mostly in the details: missing redirects, changed URLs, lost titles and content, and pages accidentally blocked from indexing. Careful preparation reduces the chance of a lasting drop but does not remove it.
Should I keep the same URLs on the new platform?
Where you can, yes. Every URL that stays the same is one fewer redirect to get wrong. Some platforms force a different structure, such as fixed prefixes, and in that case a complete redirect map matters even more.
How long should I keep the redirects?
Google’s site move guidance advises keeping redirects in place for at least a year. In practice I would keep redirects for any URL that still has links pointing to it or traffic arriving at it, for as long as the store runs.
Do I need to use the Change of Address tool?
Only if the domain name changes. Search Console’s Change of Address tool is for moving from one domain to another. A platform move that keeps the same domain does not use it.
When is the best time to launch a migration?
Pick a quiet period for the business and avoid your busiest sales season, since a problem found during a peak is expensive. Launch on a day when your developers and your SEO support are both available to fix issues quickly.
Replatforming SEO Checklist
- Crawl, sitemaps, robots.txt and top pages are saved from the live site.
- A redirect map covers every old URL that has traffic, links or a sensible equivalent.
- Redirects point straight at the final URL, with no chains or loops.
- Titles, descriptions, H1s and category copy match the old site or were changed on purpose.
- Canonicals, robots directives and structured data are correct on every template.
- Internal links point at the new URLs, not at redirects.
- Staging protection is removed at launch and the live site is open to search engines.
- The sitemap lists only live, indexable, canonical URLs and has been submitted.
- Analytics and conversion tracking work on the new site.
- Indexing, crawl errors, redirects and performance are reviewed by template after launch.
The Shopify technical SEO audit is a good follow-up check once the new store is live, and the duplicate product URLs guide covers the problems new platforms commonly create.
Book a call and we will go through your redirect map, page parity and launch plan together, then agree on what to fix first.
Book a CallMore SEO guides
Shopify Technical SEO Audit
Run a Shopify technical SEO audit in ten steps. Real admin paths, exact thresholds, and the Shopify specific problems generic checklists miss.
Faceted Navigation and Crawl Budget
Filters can create millions of URLs and slow Google's crawl of the pages that sell. See what really saves crawl budget, what doesn't, and how to fix it.
Shopify vs WooCommerce for SEO
Shopify vs WooCommerce for SEO compared on URLs, themes and plugins, speed, structured data and technical control, and where each platform helps or hurts.
Moving platforms and want it checked first?
Get the redirect map, page parity and launch plan reviewed before the new store goes live.

I’m an awarded SEO expert and seo consultant with 11+ years of experience. I have generated over $100M in tracked organic revenue by SEO for my clients like you 👉 See Case Study
