Playbook + workbook · Free to use

Ecommerce SEO migration playbook

Plan URL decisions, prove staging readiness, and check an ecommerce migration after launch. Includes an editable mapping workbook and completed example.

URL decisionsFour routes through a migration
KeepSame purpose, same URL
Tent care/guides/tent-care
unchanged
Tent care/guides/tent-care200 · retained
MoveSame product, new address
Cedar 2/product/cedar-2
301
Cedar 2/products/cedar-2200 · destination

Product ID A-CD2 stays the same.

MergeTwo useful guides, one home
Cleaning tents/guides/cleaning-tents
+ existing tent-care guide
301
Complete care guide/guides/tent-care200 · combined

Move the cleaning advice before redirecting.

RemoveNo successor or support value
Obsolete peg/product/obsolete-peg
retired
410Page removedNo unrelated redirect

Match the page’s purpose before choosing its destination.

Alder and all supplied figures are fictional practice material. Apply the reasoning to verified evidence from your own store.

1. Define the change before collecting URLs

Write down what is changing: hostname, platform, paths, templates, catalog, languages and infrastructure. Keep a deliberate list of what must survive, including images, manuals, product IDs, variant selection, customer accounts and checkout. A platform change can break discovery without changing a single URL.

Assign a release owner, an SEO reviewer, a commerce operator and a recovery decision maker. Choose a quieter trading period using your own demand history. Avoid combining unnecessary changes: a new domain, rewritten catalog and redesigned templates make failures harder to isolate.

Alder practice scopeDecision
PlatformWooCommerce to Shopify; domain stays alder.example
Product paths/product/ becomes /products/
CatalogKeep sellable items; review discontinued pages individually
Data that must stay currentOrders, customers, prices and inventory
Separate later projectNew market and new language launch

2. Build an inventory from several sources

Combine the catalog export, crawled internal links, XML sitemaps, recent server logs, analytics landing pages and available Search Console exports. Record the source and date on every observation. Include valuable orphan URLs, documents and images; a navigation crawl cannot find every forgotten URL.

Search Console examples and exports have limits. Its indexed-page examples are not a complete inventory. Normalize host and fragments deliberately, but preserve query parameters and letter case until you know whether they change the resource. Deduplicate exact normalized URLs while retaining their source memberships.

  1. Export old URLs before the switch, with status, canonical, page type and product/variant identity.
  2. Add traffic and revenue context from comparable periods, clearly separated from crawl observations.
  3. Join on stable product or content IDs, not just similar titles.
  4. Mark uncertain records for investigation; prioritize important URLs without deleting the long tail from the map.

3. Choose keep, move, merge or remove

A mapping is an editorial decision before it is a redirect file. Keep a URL when its purpose and address survive. Move it when the same resource has a new address. Merge only when the destination meaningfully covers the old purpose. Remove content with no remaining purpose or relevant successor using a real 404 or 410.

A permanent redirect does not inherently lose PageRank. Relevance, content continuity, access and processing still matter. Avoid blanket homepage redirects, loops and chains. Check every destination in the final environment, including slash and case behavior.

Old URLActionFinal destination / responseReason
/guides/tent-careKeepSame URL · 200Same maintained guide
/product/cedar-2Move/products/cedar-2 · 301 then 200Same product ID A-CD2
/guides/cleaning-tentsMerge/guides/tent-care · 301 then 200Cleaning instructions incorporated
/product/obsolete-pegRemove410No successor or support value
/manuals/cedar-2.pdfKeepSame URL · 200 PDFStill linked from product support

4. Prove the new site is ready

Protect staging with authentication or equivalent access control. Robots.txt is not confidentiality protection. Record how testing is allowed and how production protection differs. Before release, test the production configuration in a controlled environment: public product templates must not inherit staging noindex, authentication or disallow rules.

Compare representative old and new pages by type and exception. Record title, primary heading, buying content, specs, image and manual access, product links, canonical, rendered directives and response status. Check both HTML and rendered output where scripts change the page. A green HTTP status alone cannot demonstrate parity.

  1. Validate one-hop redirects and final destinations against the complete URL map.
  2. Check canonicals, internal links, hreflang equivalents and XML sitemaps point to final URLs.
  3. Place a test order using the platform's safe test facility; verify stock, variant, price, currency and confirmation behavior.
  4. Compare visible offers with structured data and feeds; preserve identity where the product is unchanged.
  5. Document unresolved exceptions with an owner, impact and explicit release decision.

Platform checks that change the implementation

Shopify redirect controls are constrained by Shopify's own routes and response behavior. A redirect generally cannot override a URL that still serves a valid page. Test old paths after import and review reserved paths, query strings and market subfolders in the current Shopify documentation.

For WooCommerce, inspect product, variation, stock-management and visibility settings separately. A variation can be unavailable while other variants remain purchasable. WordPress permalink, theme, caching and extension choices affect the final output: inspect the actual response rather than assuming one universal plugin setting.

These are implementation checks, not prewritten server rules. The workbook is deliberately platform independent; your engineer should translate approved URL decisions into the platform's supported mechanism.

5. Launch with checkpoints and a recovery owner

Freeze the agreed content and mapping configuration, while keeping live commerce data authoritative. Record the version, start time and people on call. At the switch, check critical journeys and representative URLs immediately, then widen verification to the full map and template groups.

If an incident affects one rewrite or template, a targeted repair may be safer than a whole-site rollback. If a rollback is necessary, explicitly preserve or reconcile orders, payments, customer changes and inventory created since launch. Never restore an old commerce database merely to recover an SEO setting.

CheckpointOwner roleEvidence required
Before switchRelease leadApproved map, tests, recovery authority
Immediately after switchEngineer + commerce operatorFinal responses, crawl controls, buying path
After initial verificationSEO reviewerSitemap, links, canonical, offer consistency
During monitoringSEO + analytics ownerURL-group trends and timestamped exceptions

6. Separate defects from processing delays

Monitor old and new URL groups together. Compare crawl and index evidence, organic landing traffic, purchase behavior and feed diagnostics using aligned periods, page groups, countries and devices. Record changes in promotions, availability and tracking. Do not add old and new URL totals when the measurement method already consolidates them.

A correctly redirected URL still appearing in a search report shortly after launch is different from a new product returning noindex today. Repair observed defects promptly. For correct pages awaiting processing, retain the evidence and check again; no fixed traffic-loss percentage or recovery deadline is universally normal.

Keep permanent redirects for at least a year, and longer when useful to visitors or existing links. Maintain old-domain control, TLS and hosting needed to serve them. Use Search Console's Change of Address only for supported domain or subdomain moves, not a path-only move such as this Alder example.

Sources and maintenance

Check current platform documentation before implementation. Review these instructions when your platform, catalog behavior or source guidance changes.