Build a complete URL inventory first
Before you can map anything, you need a full list of the URLs currently in use — not just the ones you remember, but every product page, category and collection page, blog or content page, and any custom landing pages that exist on the current site. Pull this from your sitemap, your analytics tool's page reports, and a crawl of the live site, and cross-check the three against each other, since each source tends to miss something the others catch.
Pay particular attention to URLs that get organic traffic or have external backlinks, even if they're pages you'd otherwise consider minor. A low-traffic blog post with a handful of good backlinks is worth mapping correctly; losing it silently is a small but avoidable loss.
Map every URL to its new equivalent — and decide the exceptions deliberately
For each URL in your inventory, decide its new-platform destination. Most product and category pages will have a reasonably direct equivalent once your data mapping is settled. Pages with no clean equivalent (a discontinued product, a one-off landing page, a category that no longer exists) still need an explicit decision — usually a redirect to the closest matching category, a relevant hub page, or in rare cases a deliberate, accepted 404 — rather than being left to redirect to the homepage by default or to 404 by accident.
A blanket "redirect everything to the homepage" approach is a common shortcut that actively hurts you: it dilutes relevance signals and gives users a poor experience compared to landing on the nearest relevant page.
Implement 301s, and check for chains and loops
Use permanent (301) redirects for URLs that have genuinely moved for good — that's the signal that tells search engines to transfer ranking signals to the new URL. Once your redirects are live, actively check for redirect chains (URL A → B → C, when A → C would do) and loops (A → B → A), since both are common byproducts of iterative redirect-map edits and both waste crawl budget and add latency. A one-hop redirect from every old URL straight to its final new destination is the goal.
Test a representative sample of redirects manually after launch — spot-check high-traffic pages, a handful of low-traffic ones, and a few of the deliberate exceptions — rather than assuming the map is correct just because it validated in a spreadsheet.
Handle canonical tags deliberately
Canonical tags tell search engines which URL is the authoritative version when similar content is reachable from more than one address. After a migration, make sure every page's canonical tag points to its own live, correct new URL — not to a leftover old URL, and not to a different page's URL by mistake from a copy-pasted template. Getting this wrong can confuse search engines about which version of a page to index, even when the redirects themselves are correct.
If the new platform generates canonical tags automatically, verify its default behavior rather than assuming it's right for your setup — automatic canonicalization occasionally points at unexpected URLs on parameterized or paginated pages.
Resubmit your XML sitemap and update internal links
Once the new site is live with working redirects, generate and submit a fresh XML sitemap reflecting the new URL structure through Google Search Central and other search engines' webmaster tools, so crawlers can discover the new pages efficiently instead of relying solely on following redirects from old URLs.
At the same time, update internal links across the site — navigation, footer, related-product links, blog content — to point directly at the new URLs rather than through a redirect. Internal links that still point at old URLs add unnecessary redirect hops on every click and are easy to miss since they don't break anything visibly; they just work less efficiently.
Monitor crawl and index status after cutover
Migration SEO work doesn't end at launch. In the weeks after cutover, watch Search Console (or the equivalent tool for other search engines) for crawl errors, a sudden spike in 404s, pages that aren't getting indexed, or a drop in impressions/clicks for pages that should be performing normally. Compare this against your pre-migration baseline so you're catching real regressions, not normal short-term fluctuation.
Be patient but not passive: some reindexing takes time even when everything is set up correctly, but a redirect or canonical mistake left unnoticed for weeks is much more expensive to fix than one caught in the first days after launch.
Frequently asked questions
Will a migration definitely hurt my search rankings?
Not necessarily, but rankings can change even when a migration is well executed. A complete redirect map, correct canonical tags, updated internal links and a resubmitted sitemap reduce avoidable risk. Nobody can guarantee specific positions because search performance depends on many factors beyond the migration.
Should I use 301 or 302 redirects?
Use 301 (permanent) redirects for URLs that have moved for good, which is the normal case in a platform migration. 302 (temporary) redirects signal that the move isn't permanent and search engines may not transfer ranking signals the same way, so they're the wrong choice for a completed migration's redirect map.
What if two old URLs should point to the same new page?
That's fine and common — for example, two old category URLs that got merged into one on the new platform. Redirect both old URLs directly to the single new URL. What you want to avoid is the reverse: one old URL that's ambiguous about which new page it should map to, which usually means the mapping decision hasn't actually been made yet.
How long should I keep old redirects in place?
Indefinitely, if practical. Backlinks, bookmarks, and old search results referencing the previous URLs can persist for a long time after a migration, and there's little cost to keeping a redirect rule alive. Removing redirects too early is a common way to turn what should be a one-time migration cost into a recurring source of broken links.