Search traffic drops after a replatform are common enough that many merchants treat them as unavoidable. They are not. In almost every case the loss traces back to the same thing: the redirect map was treated as a launch-day task rather than a design input.
The distinction matters because a redirect map built after the new URLs exist can only react to whatever structure the new store happened to produce. A map built before can influence that structure.
Start from the old site's URLs, not the new site's
Before anything is built, export every URL the old store has that a search engine knows about. Not the ones in the sitemap β the ones with impressions, links or traffic, which is a different and usually larger set. Old blog posts, discontinued products, category pages nobody in the business remembers, and the URLs of pages that were deleted years ago but still hold links.
Sort that list by value: organic entrances, impressions, and external links pointing at it. What you now have is a priority order, and it will not match anyone's intuition about which pages matter.
Map before you build
With the ranked list in hand, decide the target for each URL before the new store's structure is fixed. This is the step that gets skipped, and skipping it is what produces the classic failure: two hundred old category URLs with strong history mapping to a single new collection because the new collection structure was designed without looking at them.
Every mapping should be to the closest equivalent page. A discontinued product goes to its category, not the homepage. A retired category goes to the nearest current one, not the homepage. Redirecting everything to the homepage is technically a redirect and functionally a deletion β search engines treat a mass homepage redirect as a soft 404.
Permanent, not temporary
Use permanent redirects. A temporary redirect tells search engines the old URL is coming back, so the old URL keeps being crawled and the new one does not inherit the history. This sounds elementary and it is still one of the most common defects found in a post-migration audit, usually because a platform or a plugin defaulted to temporary and nobody checked.
Avoid chains. Old URL to interim URL to final URL loses signal at each hop and wastes crawl. If the migration happens in stages, rewrite earlier redirects to point at the final destination rather than layering new ones.
What else moves with the URLs
Redirects preserve the address. They do not preserve everything the old page had.
Page titles and meta descriptions have to be carried across deliberately, and a platform migration is exactly when they get replaced with template defaults. A category that ranked on a carefully written title does not keep ranking on "Category β Store Name".
Structured data has to be rebuilt on the new theme. Internal links inside body content still point at old URLs and should be rewritten rather than left to redirect. Image URLs change too, and image search traffic is real traffic for some catalogues.
The first fortnight
Rankings move after a migration even when everything is done correctly. The signal to watch is not position but crawl behaviour: which URLs are being fetched, which are returning errors, and whether the old URLs are being seen and followed.
Two checks catch most problems early. First, sample the top hundred old URLs by value and confirm each returns a permanent redirect to a live, relevant page β not to the homepage, and not through a chain. Second, watch for old URLs still being crawled weeks later, which usually means something still links to them internally.
Resist the urge to change anything else in the first month. Migrations that also redesign, restructure and rewrite at the same time make it impossible to tell which change caused which movement.