Migration runbook / 18 min

Ecommerce migration SEO checklist in 24 controlled steps

monkydot · 2026-09-24 · 18 min

When you migrate a store, for example from Magento to a headless ecommerce setup, you are changing a system that Google has already indexed. Before Google starts processing the new site, the meaning of each page, its URL, internal links, rendering and status codes need to carry over. This runbook gives every stage an owner and a condition for stopping.

Technical review: monkydot engineering

1. Record the baseline

Capture what Google and your customers see today, before development work starts changing it. You need this baseline for parity checks and to tell apart problems caused by the migration from problems that were already there.

Step 01: Export organic landing pages, clicks, impressions, queries and index status from Search Console for a representative period that covers known seasonal patterns.
Step 02: Crawl the current site and save the URL, status, canonical, robots directives, title, description, headings, structured data, hreflang, internal links and rendered content for each page.
Step 03: Export analytics, server log and revenue data by landing page and template, then classify critical URLs by traffic, revenue, backlinks and business role.

Baseline	Owner	Used for
Search performance and index coverage	SEO	Comparing results after launch and diagnosing changes
Technical crawl	Engineering / SEO	Checking parity and redirects
Value of each landing page	E-commerce / analytics	Setting priorities and making rollback decisions
Server logs	Platform	Crawler behaviour and finding old URLs

2. Build a complete URL inventory

Sitemaps alone do not give you a complete list. Pull in URLs known to the CMS, analytics, server logs, Search Console, backlink tools and internal search. Images, PDFs and feeds can carry search value of their own.

Step 04: Merge all URL sources into one deduplicated inventory, including products, categories, content, pagination, language versions, media, files and retired URLs that still get visits.
Step 05: Mark each URL as keep, move, merge, remove or deliberately noindex, and give it a named destination or final status.

3. Map each old page to its closest new equivalent

Redirect each old URL to the most relevant new page. Removed products and categories should not all go to the home page by default. Where there is no real equivalent, a proper 404 or 410 is often the more honest answer.

Step 06: Create a one-to-one map from old to new URLs wherever equivalent content exists, and document the approved many-to-one merges and removals.
Step 07: Generate server-side permanent redirects that point straight to the final destination, then test for loops, chains, differences in letter case, lost parameters and protocol or hostname variants.

Old URL	Preferred outcome	Avoid
An equivalent page exists	301 or 308 to that page	Redirecting to a generic parent page
Several pages have really been merged	Redirect to the combined page	Keeping thin duplicate pages
No replacement	404 or 410 with helpful navigation	A soft 404 that returns 200
URL stays the same	Serve the new page at the same URL	Adding a redirect you do not need

4. Keep content and internal links at parity

A template that looks the same can still lose crawlable text, links, headings or variant information. Compare the rendered pages rather than the records in the CMS.

Step 08: Check that critical pages keep their purpose and content: product identity, category text, specifications, availability information, reviews, editorial copy and media.
Step 09: Rebuild navigation and in-text links as crawlable HTML anchors that point directly to final URLs, and keep the important links between categories, products and articles.

5. Check rendering and HTTP status codes

Google can render JavaScript, but HTML rendered on the server or in advance means you depend less on the client-side code running successfully. This matters most in a headless migration. Indexable pages should show their main content, links and metadata in the HTML that is delivered, or in a result that renders reliably.

Step 10: Test product, category and editorial templates with JavaScript turned off and by inspecting the rendered HTML, and confirm the main content and links can still be found.
Step 11: Check that status codes and index controls are correct: 200 for valid pages, 301 or 308 for permanent moves, 404 or 410 for missing pages, and no accidental noindex or robots blocking.

Check	Passes when
First response	Indexable routes return useful content and metadata
Client-side failure	The page's purpose and crawlable links are still there
Missing product or page	The server returns a proper 404 or 410
Private route	Login requirements and the noindex policy are consistent

6. Control facets, parameters and pagination

Filters in an online store can generate an almost unlimited number of URLs. Decide which combinations deserve their own indexable pages and stop the rest from using up crawl capacity or creating duplicates.

Step 12: Define rules for sort, filter, tracking and session parameters, and align links, canonicals, robots controls and sitemap entries with the index state you want.
Step 13: Give paginated pages their own crawlable URLs and sequential links, so that later products can be reached without user interaction or URL fragments.

7. Rebuild tags and structured data from managed data

Canonical tags, hreflang and structured data have to describe the visible page and be consistent with each other. Generate them from the same product, market and URL rules the storefront uses.

Step 14: Check self-referencing canonicals, titles, descriptions, hreflang clusters, robots directives, sitemap URLs and internal links against the final production URL rules.
Step 15: Validate Product, Offer, Breadcrumb and any relevant organisation or article structured data, and make sure price, currency, availability and identifiers match what is shown on the page.

Tag or file	Migration error to look for
Canonical	Points to the staging host, an old URL or the wrong language version
Hreflang	Missing return links or inconsistent canonical targets
Product / Offer	Price or availability in the schema differs from the page
Breadcrumb	URLs do not match the crawlable navigation
Sitemap	Contains redirected, blocked, noindex or non-canonical URLs

8. Test in a production-like environment before launch

Test behind access controls that keep staging URLs out of search results. Before launch, test how the real production host behaves, either through controlled routing or an equivalent environment that includes the CDN and redirect configuration.

Step 16: Run automated parity checks on representative and high-value URLs covering status, destination, canonical, metadata, rendered content, schema, hreflang, links and performance.
Step 17: Run manual journeys and crawler tests across markets, devices, logged-out states and error cases, and get sign-off from SEO, engineering, analytics and the business.

9. Cut over one controlled change at a time

Google recommends separating major changes where you can. Avoid combining a domain move, new URL structure, rewritten content and a visual rebrand, unless the business accepts that problems will be much harder to diagnose.

Step 18: Pause non-essential releases, confirm owners and communication channels, take backups you can restore, scale up capacity in advance and schedule the switch for a quieter traffic window.
Step 19: Deploy the new site and permanent redirects, remove temporary noindex tags or crawl blocks, publish clean XML sitemaps, check analytics and confirm Search Console ownership.

Cutover owner	Immediate responsibility
Release lead	Sequence, go/no-go decision and rollback command
Platform	Routing, redirects, capacity, logs and errors
SEO	Index controls, sitemaps, canonicals and spot checks
Analytics	Landing pages, transactions and attribution
Commerce operations	Catalogue, prices, stock, cart and checkout

10. Make sure rollback can actually be done

Rolling back has to restore a working site, which usually means more than redeploying the old frontend code. Data, orders, customer accounts, redirects and caches may all have changed since the cutover.

Step 20: Define measurable and functional rollback triggers for availability, checkout, redirect coverage, index controls, rendering and data integrity, with one person authorised to make the call.
Step 21: Rehearse rolling back the application, routing, redirects, cache and integration changes, and document how orders and customer data created after the cutover stay consistent.

11. Monitor on day 1, 7, 30 and 90

Monitoring after a migration needs early technical signals as well as search results, which arrive later. Break the numbers down by page type, market and device, so that overall traffic does not hide a broken template.

Step 22 - Day 1: Crawl priority URLs and a sample of redirects, and check logs, 4xx/5xx errors, robots, noindex, canonicals, rendered output, sitemaps, analytics and checkout. Fix systemic problems straight away.
Step 23 - Day 7 and day 30: Review indexing in Search Console, sitemap processing, crawl activity, clicks, impressions, queries, rich results and Core Web Vitals by template. Extend redirect and old-URL checks using the server logs.
Step 24 - Day 90: Compare results with the approved baseline and seasonal patterns, close the remaining indexing and redirect gaps, update external links where you can, and remove migration controls only once the owner has signed off.

Checkpoint	Main decision
Day 1	Is the release technically sound, or should we roll back?
Day 7	Is Google discovering and processing the site as expected?
Day 30	Which template or market needs corrective work?
Day 90	Can the migration be closed, or are there still significant gaps?

12. Final acceptance checklist

Close the migration only when responsibility has passed from the launch team to normal operations and the evidence has been archived.

All 24 steps have an owner, a link to evidence and a completion status.
Critical old URLs redirect directly to equivalent final pages.
Indexable templates show their content and links and return correct status codes.
Facets and pagination produce the set of crawlable URLs you intended.
Canonical, hreflang, schema, sitemap and visible content are consistent.
The production-like tests passed before the cutover.
Rollback was rehearsed and data written after the cutover is protected.
The day 1, 7, 30 and 90 reviews each have a named decision owner.
Temporary dashboards, redirects and alerts have criteria for when they can be removed.

Sources and further reading

/ Related services

/ Related articles