Treat an E-commerce Migration as a Commercial Change Programme

A platform migration often replaces internal database keys, field names, templates, feeds, and application logic. Those internal changes are acceptable when the public catalogue continues to describe each product accurately.

The migration inventory should capture Product IDs used internally for reconciliation, plus public identifiers such as SKU, GTIN, brand, manufacturer, model, variant attributes, price, availability, review associations, and canonical URL.

The objective is not to preserve every database detail. It is to prevent the new site, feeds, and structured data from contradicting each other or assigning one identifier to several products. Existing JSON-LD Schema should be exported by template and compared with the staging output.

Product, Offer, AggregateRating, BreadcrumbList, Organization, and other implemented types should match visible page content and supported vocabulary. A 1:1 mapping is appropriate where an old public identifier remains valid, while changed or corrected identifiers require documented merchandising approval rather than silent substitution.

The same review applies to brand and manufacturer relationships, organisation details, logo references, and any sameAs links already used. Hosting or server changes do not automatically erase trust, but inconsistent names, product facts, currencies, or review associations can make the new catalogue harder to interpret.

Test representative products, variants, bundles, sale items, unavailable items, and international versions before launch, then reconcile search feeds and merchant systems against the same source of truth.

A common piece of advice during e-commerce site migration is to 'prune' the site. The logic is that by removing thousands of old blog posts, discontinued product pages, or thin category pages, you improve your Crawl Budget.

While this sounds efficient, it often leads to a catastrophic loss of Internal Link Equity. In my work, I have identified these as 'Ghost URLs': pages that receive almost no organic traffic but serve as critical nodes in your site's Backlink Profile.

Before any migration, I conduct a Ghost-URL Audit. We use tools to identify every page on the site that has at least one external backlink, regardless of its current traffic levels. If a page has Referring Domains but is slated for deletion, we must intervene.

Simply redirecting these pages to the homepage is a mistake: it is a 'Soft 404' signal that tells Google the content is gone and the link equity should be discounted. Instead, we map these Ghost URLs to the most Semantically Relevant category or parent page.

For example, if you are deleting a blog post about 'how to clean leather boots' that has ten backlinks, you should redirect it to your 'Leather Boot Care' category page, not the homepage. This preserves the Topical Authority and ensures the 'juice' from those old links continues to support your commercial keywords.

I have found that skipping this step is the primary reason sites see a 'permanent' 15-20% drop in total domain authority after a move.

E-commerce SEO relies heavily on Category Hierarchy. The way you group products and link between them tells search engines which terms are most important. During a migration, many brands change their URL Folders or their breadcrumb logic.

If the old site had a structure like /shoes/mens/running and the new site uses /products/mens-running-shoes, you are not just changing a URL: you are changing the Semantic Distance between entities.

I use the Semantic Bridge Test to compare the internal link counts and click-depth of core category pages before and after the move. What I have found is that many modern e-commerce themes use 'Mega Menus' that are powered by JavaScript.

If these menus are not rendered correctly by search engines, your deep category pages may suddenly find themselves 5 or 6 clicks away from the homepage, rather than 2 or 3. This increase in Click Depth often results in a significant drop in rankings for competitive head terms.

Furthermore, you must ensure that your Breadcrumb Navigation remains consistent. Breadcrumbs are not just for users: they provide clear Topical Clusters that Google uses to understand your site's breadth.

If your new platform simplifies breadcrumbs or removes them entirely, you lose a powerful internal linking signal. In practice, I recommend crawling both the staging site and the live site using a tool like Screaming Frog to compare the 'Inlinks' and 'Link Score' for your top 100 revenue-generating pages.

Large catalogues can generate extensive URL combinations through size, color, price, brand, availability, sort order, pagination, search, and tracking parameters. A migration may change which combinations are linked, rendered, canonicalised, indexed, or included in sitemaps.

During recrawling, an uncontrolled facet system can divert attention toward low-value or duplicate pages while priority products and categories wait to be processed. The solution is not a universal blocking rule.

The team should classify facets by customer value, search demand, stock stability, content uniqueness, and operational maintainability. Some filtered pages may deserve stable indexable destinations; others should consolidate to a main category, remain unlinked, use noindex where appropriate, or be disallowed from crawling when that control fits the objective.

Google Search Console's URL parameters tool is mentioned in the source, but teams should not rely on an unavailable or deprecated interface as the core control. Canonical tags are signals, not directives, and robots.txt prevents crawling rather than guaranteeing deindexation.

Server capacity is equally important. Load testing should cover page generation, APIs, inventory calls, image delivery, cache behaviour, redirects, and bot traffic under launch conditions. XML sitemaps should contain only preferred 200 OK canonical URLs, exclude filtered and redirected addresses, and separate templates where monitoring benefits from it.

Track crawl responses, server errors, discovered URLs, and sitemap processing during the first two weeks, but prioritise incident thresholds over checking a report for its own sake.

The staging environment should be evaluated as a release candidate, not only as a visual preview. Development, SEO, analytics, merchandising, accessibility, security, customer service, and operations need a shared acceptance process.

Crawl representative templates and the full accessible staging inventory where feasible. Check titles, descriptions, headings, canonicals, status codes, hreflang, structured data, robots directives, pagination, internal links, sitemaps, images, product facts, prices, availability, reviews, and checkout routes.

For JavaScript-heavy or headless builds, compare initial HTML, rendered HTML, browser behaviour, and server logs to confirm that product descriptions, menus, links, offers, and policy content are available without fragile client-side dependencies.

Test the 301 Redirect Logic against the actual staging or release routing layer rather than trusting a spreadsheet alone. A sample of 500-1000 old URLs can reveal patterns, but the full map should be validated automatically where possible.

Resolve chains so A reaches the intended C directly rather than A to B to C, and confirm a clean 1:1 destination when the old and new pages represent the same purpose. Staging access controls must prevent unintended public indexation while still allowing authorised crawls; launch procedures must then remove temporary noindex or blocks at the correct moment.

Performance testing should include cache-warm and cache-cold behaviour, APIs, search, filters, login, carts, payments, feeds, and failure recovery.

Some volatility can occur after a migration, but teams should not assume every loss is temporary. The first 48 hours focus on release integrity: redirects, robots.txt, canonical output, sitemaps, server responses, analytics, feeds, payments, inventory, search, and critical customer journeys.

The first week focuses on error patterns, crawl discovery, indexation, duplicate access to old and new hosts, template performance, and revenue-critical pages. Avoid broad content or architecture changes made only because average positions move during early recrawling.

Instead, compare observed failures with the pre-launch baseline and release log. Use URL Inspection for representative pages, but combine it with crawling, logs, analytics, merchant data, and template checks because one inspected URL cannot represent the catalogue.

In the second week, review performance by category, product, market, device, and template. Compare the top 50 tracked queries where they remain useful, while prioritising impressions, clicks, landing sessions, conversion behaviour, assisted revenue, inventory, and margin.

If one category underperforms, inspect redirects, internal links, content parity, canonicals, rendering, stock, pricing, and page speed before changing unrelated pages. Escalation rules should identify which issues trigger an immediate fix, rollback, development incident, analytics incident, merchandising correction, or monitored observation.

The objective is a controlled diagnosis with documented evidence rather than a promise that every migration dip can be avoided.

Many migration plans reduce SEO to URL Mapping and a launch-day crawl. That view misses the commercial system around each URL. A low-traffic article may support a category through internal links or backlinks.

A discontinued product may still answer comparison demand or attract referral visits. A category can keep its address yet lose visibility because the new navigation places it deeper, removes descriptive content, or exposes competing filtered URLs.

Generic cleanup advice can therefore remove useful assets without examining why they exist. Modern platform changes also introduce JavaScript Rendering, API, cache, feed, consent, personalisation, and server behaviour that a spreadsheet cannot validate.

A complete migration service should join technical SEO, merchandising, analytics, development, content, paid media, customer service, and operations around one release plan with clear owners, evidence, rollback criteria, and post-launch thresholds.

Early in my career, I assisted with a migration for a high-end furniture retailer. The design team wanted a 'minimalist' look and convinced the stakeholders to remove all the long-form text from the category pages, claiming it was 'cluttered.' We moved the site with perfect 301 redirects, but the rankings for every major category collapsed within three weeks.

What I learned then, and what I practice now, is that Contextual Relevance is the foundation of authority. The redirects moved the users, but the removal of that 'cluttered' text removed the signals Google used to understand the depth of the brand's expertise.

Now, I insist on a 'Content Parity' rule: if a page ranks well today, its core content and internal linking structure must be preserved or improved on the new site. Never sacrifice Information Density for aesthetics during a migration.

Day 1-7

Complete the URL, backlink, internal-link, revenue, conversion, inventory, and content inventory; finalise the 301 Redirect Map around page purpose and relevant destinations.

Outcome: A governed migration inventory that identifies what must remain, redirect, consolidate, update, or retire.

Day 8-14

Reconcile product, offer, review, organisation, language, and regional data in staging, including Schema and GTIN consistency where the source data remains valid.

Outcome: The staging catalogue presents consistent public facts across pages, feeds, analytics, and structured data.

Day 15-21

Compare internal links, breadcrumbs, navigation, rendering, performance, analytics, feeds, checkout journeys, and implemented redirects across the old and new builds.

Outcome: Technical and commercial blockers are documented, assigned, and resolved or accepted before cutover.

Day 22-25

Run the final Pre-Flight review of robots.txt, sitemaps, canonicals, hreflang, status codes, monitoring, rollback criteria, release ownership, and production configuration.

Outcome: The launch team has an approved release state, incident thresholds, and rollback decision path.

Day 26-30

Execute launch and Post-Migration Triage, checking redirects, customer journeys, revenue, feeds, analytics, crawling, indexation, templates, and priority categories against the baseline.

Outcome: Material visibility, measurement, and transaction issues are identified quickly and routed to the correct owner.