Organic search is usually the largest single channel on a commerce site and the easiest one to destroy in a replatform. It does not get destroyed by a bad redirect map. It gets destroyed by treating the redirect map as the last task in the plan.
Treat it as a work package, not a checklist
On every migration we run, search visibility has its own owner, its own acceptance criteria and its own place on the delivery board from week one. It is not a line in a launch checklist that somebody picks up in the final sprint, because by the final sprint the decisions that break it have already been made.
The decisions that break it are usually made early and quietly: a URL structure chosen for developer convenience, a facet implementation that generates a million crawlable combinations, a decision to render category content on the client, a content model that drops the copy nobody thought anyone read.
Inventory first, from three sources
You cannot map what you have not measured, and one source is never enough.
- A full crawl of the live site. Tells you what exists and how it links together.
- Server access logs, ninety days. Tells you what search engines actually request and how often. This is where you find the twelve thousand URLs nobody knew were indexed.
- Search Console and analytics export. Tells you what earns impressions, clicks and revenue.
Join those three into one inventory with traffic, revenue and crawl frequency per URL. On the last migration we did, the crawl found 297,000 URLs, the logs found another 115,000 that were still being crawled from links on external sites, and about 4,000 of those were still earning revenue.
Map every URL to exactly one destination
The rule is simple and unpopular: every old URL maps to one new URL, or gets an explicit documented decision. What you are avoiding is the default that destroys migrations, which is redirecting anything unmatched to the home page. A mass redirect to the home page is treated as a soft error, the equity does not transfer, and it hides the size of the problem from you.
Categories that no longer exist redirect to the nearest surviving parent. Discontinued products redirect to their category, not to a generic page, and only if there is no replacement product. Anything that genuinely has no destination returns a 410, deliberately, so it drops out of the index cleanly rather than lingering as a soft error for months.
| Old URL type | Destination | Status |
|---|---|---|
| Product, still sold | New product URL | 301 |
| Product, replaced | Replacement product URL | 301 |
| Product, discontinued with no replacement | Parent category | 301 |
| Category, renamed | New category URL | 301 |
| Category, merged | Surviving category | 301 |
| Facet or filter combination | Clean category URL, facets not indexable | 301 |
| Internal search results | No destination | 410 |
| Expired campaign landing page | Relevant category, or 410 if none | 301 or 410 |
Table. The mapping rules we agree with the client before build, so the decisions are made calmly rather than during cutover week.
Parity, template by template
Redirects preserve the address. They do not preserve the reason the page ranked. Before cutover we compare the old and new templates on titles, meta descriptions, heading structure, body copy volume, internal link count and destination, structured data, canonical behaviour, hreflang and pagination. Every difference goes in a report with a reason. Some differences are intentional improvements. The ones that are not intentional are the ones that cost you.
The most common finding is body copy. A legacy category page has three hundred words of copy under the grid that nobody in the business remembers writing, and the new content model has no field for it. That copy is often doing more work than anyone realises.
Ship redirects with the release, at the edge
Redirects belong in the same release as the change, applied at the edge, in a single hop. Chains are the quiet killer: an old URL redirecting to a URL that itself redirects, three or four times, until search engines stop following. We test the map as part of the pipeline, with an automated suite that asserts a single hop and the correct status for every entry, and that suite keeps running after launch.
Then watch it for eight weeks
Cutover is not the end of the work package. For eight weeks after, someone owns a daily check on index coverage, crawl errors, log file status codes, ranking for a fixed keyword set and organic revenue by template. Thresholds are agreed in advance and one of them is a rollback trigger, because the worst version of this story is the one where everyone notices in week six.
Across our last five migrations the median ranking change at week eight was zero positions. The worst case was a loss of two positions on one template, caused by exactly the missing body copy problem described above, and it recovered inside six weeks once the copy went back.
Next step
Put this in front of your own numbers
We run a fixed scope technical assessment of your storefront, checkout and integration layer, then hand back a prioritised plan with effort and expected impact.