Plan a Store Platform Migration With a Page-by-Page URL Map

Moving from WooCommerce or Shopify to another store platform can change product and category URLs, redirect controls, templates, and how data is rendered. Do not delete the old pages or launch redirects before you know which URL exists, which new page serves the same need, and whether the new platform can implement and test the redirect.

No migration method guarantees that every visit or keyword position will remain unchanged. Google's site-move guidance recommends preparing a mapping from old URLs to their corresponding new destinations, using permanent server-side redirects where possible, updating internal links and canonicals, submitting the new sitemap, and monitoring errors and traffic. Search visibility may fluctuate temporarily while systems process the changes. Google Search Central: site moves with URL changes · Google Search Central: redirects

Inventory the URLs and assets that matter

Collect URLs from the existing sitemap, the content system, analytics, and Search Console or Bing Webmaster Tools where available. Include product, category, article, and important image URLs; do not rely only on remembered links. Prioritize by real page value: organic visits, orders or leads, external links, customer support use, and role in the buying journey.

Record the page type, current canonical, status code, primary language and market, and any query parameters needed for variants or tracking. Preserve the source export so the team can revisit the mapping if a redirect fails.

Match each old URL to a genuinely equivalent destination

Map a product page to the same product or its clear successor, and a category to the corresponding group—not automatically to the new homepage. If no equivalent exists, decide whether a useful alternative, a relevant consolidated page, or a real 404 is the honest outcome. Do not redirect unrelated retired products to a general category merely to avoid a not-found response.

For each mapping, record why the new page meets the same user need, whether the product is still sold, and what happens to variants, language, currency, and stock. Keep unmatched rows visible until the business owner decides; do not silently drop them.

Prepare the new platform before switching traffic

Build and test important destination pages before launch. Check titles, visible content, canonical URLs, language alternates, product details, structured data, internal links, mobile display, checkout, and tracking. Make sure temporary staging restrictions will not carry into production, but keep the pre-launch environment protected while it is not public.

Create redirect rules from the approved map. Prefer direct permanent redirects to the final destination; avoid chains and loops. Test representative URLs across products, categories, posts, variants, and language paths. Confirm that a redirect does not send an Arabic page to an unrelated English page or lose an important product selection.

Launch in a controlled sequence and monitor

At launch, activate the planned redirects, update internal links and canonicals, publish the new sitemap, and check key page status codes. Inspect Search Console and Bing Webmaster Tools for crawl errors, excluded pages, and sitemap processing. Compare traffic and outcomes against the recorded baseline with the same dates and definitions.

Check the most valuable URLs first, then sample the rest of the map. Keep redirects active long enough for search engines and users to update; Google recommends maintaining them for at least a year and indefinitely from a user perspective where practical. Do not infer a technical failure from short-term fluctuation alone; verify exact destinations, crawl access, and response codes.

URL-map decision table

Old page	New page	Relationship	Redirect	Verification
Product variant	Same product/variant	Equivalent	Direct permanent redirect if URL changes	Product data, stock, currency, checkout
Category	Corresponding category	Equivalent	Direct permanent redirect	Products, title, canonical, internal links
Article	Same guide or true consolidation	Same reader task	Redirect only if equivalent	Language, content, canonical
Discontinued item	Support page or no destination	Depends on lasting value	Case-specific	Customer need and status code

Short-video script: map before migrating

Hook: “Changing store platforms? Don't redirect every old URL to the homepage.”

Value: Show one old product and its equivalent new page, then explain how to handle a URL with no true replacement.

Close: “Map, test, and preserve the customer task before launch.”

Educational carousel: five migration gates

Cover: Prepare the URL map before a store move.
Inventory valuable URLs and current status.
Map each old page to a truly equivalent destination.
Test redirects, canonical, language, product data, and checkout.
Update internal links and sitemap at launch.
Monitor errors and outcomes without promising no fluctuation.

Field experiment thread: rehearse a migration sample

1/ Select a representative sample across products, categories, articles, variants, and languages.

2/ Map each old URL to its new destination and document the equivalence reason.

3/ Test direct redirects, final status codes, canonicals, product data, and conversion paths in the new environment.

4/ Resolve mismatches before broad launch; keep rows with no destination for an explicit business decision.

5/ After launch, check the sampled pages and monitoring tools, then expand the audit based on errors. The sample does not prove every URL is correct.

Tool-neutral prompt pack: review the URL map

Prompt 1 — Normalize: “Normalize the supplied URL inventory without discarding query parameters that identify variants or markets. Flag duplicates and ambiguous rows.”

Prompt 2 — Assess equivalence: “Compare the old and new page descriptions, language, product, and user task. Classify each mapping as equivalent, consolidated with justification, no destination, or needs review. Do not invent replacements.”

Prompt 3 — Test plan: “Create test cases for representative redirects, status codes, canonicals, hreflang, product availability, and checkout. Separate verified results from planned checks.”

Stop-doing swipe file: replace mass redirects

Stop: “Send every deleted product to the new homepage.”

Use: Map the URL to a relevant successor only when it satisfies the same need; otherwise decide the correct retirement response.

Stop: “The new site looks right, so launch the redirects.”

Use: Test status codes, final destinations, canonical URLs, product data, and language variants first.

Stop: “Traffic dipped the first day, so the migration failed.”

Use: Check crawl and redirect evidence over a suitable period; report the observed fluctuation without overclaiming cause.

Hook–Value–Template: make each URL decision auditable

Hook: “Can you explain why each old page should send a visitor to its new destination?”

Value: A documented map protects useful paths, prevents irrelevant redirects, and gives the launch team concrete checks for each page type.

Template: “Old URL [ ]. Page role and user need [ ]. New URL [ ]. Equivalence rationale [ ]. Language/market/variant [ ]. Redirect and status test [ ]. Canonical/internal links [ ]. Product or form behavior [ ]. Owner [ ]. Post-launch check [ ]. Unresolved issue [ ].”

Sources for migration and URL changes

Migration behavior depends on the platform and map. This process reduces avoidable errors; it cannot guarantee unchanged rankings or traffic.