Replatform SKU Redirect Mapping
Migration checklists assume you can crawl the old site and map what you find, which fails on a large catalogue because the crawl misses orphaned and out-of-stock products that still hold links and rankings. The second failure is assuming SKUs map one to one: replatforms change variant handling, merge or split categories, and usually drop facet paths entirely, so a share of old URLs has no destination and gets bulk-redirected to the home page. That share is where the traffic loss comes from, and it is resolvable before launch if the map is built from the catalogue export instead.
FORMAT
replatform-sku-redirect-mapping.md
WHEN TO REACH FOR THIS
Use when moving a catalogue to a new platform and the URL patterns for products, variants, categories and facets are all changing at once.
The skill file
replatform-sku-redirect-mapping.md
---
name: replatform-sku-redirect-mapping
description: Use when moving a catalogue to a new platform and the URL patterns for products, variants, categories and facets are all changing at once.
---
# Replatform SKU Redirect Mapping
Migration checklists assume you can crawl the old site and map what you find, which fails on a large catalogue because the crawl misses orphaned and out-of-stock products that still hold links and rankings. The second failure is assuming SKUs map one to one: replatforms change variant handling, merge or split categories, and usually drop facet paths entirely, so a share of old URLs has no destination and gets bulk-redirected to the home page. That share is where the traffic loss comes from, and it is resolvable before launch if the map is built from the catalogue export instead.
## What you need first
- A URL inventory assembled from four sources and deduplicated: the database, the old sitemaps, 12 months of Search Console pages, 12 months of analytics landing pages
- Referring domain counts per old URL, so the linked tail can be prioritised
- The new platform URL patterns for products, variants, categories and any indexable facets, confirmed on staging rather than from a spec
- The old-to-new SKU and category identifier mapping from the migration team
## Method
1. Assemble the inventory from all four sources, not from a crawl. Search Console and analytics history is what surfaces URLs that still earn traffic but are no longer linked from anywhere.
2. Join the inventory to the identifier mapping and let pattern rules generate the bulk of the map. Rules are more reliable and more reviewable than a hand-built sheet of 40,000 rows.
3. Isolate the rows the rules could not match and rank them by referring domains and organic entrances. This tail is small in count and large in value, and it is the only part needing human decisions.
4. Resolve unmatched URLs to the nearest genuine equivalent and accept a 410 for those with nothing behind them. Sending them to the home page is read as a soft 404 and burns crawl for months.
5. Decide variant handling explicitly before generating anything. A site that had a URL per size moving to one product page is a many-to-one merge, and every old variant URL still needs its own rule.
6. Test the ruleset against the full inventory on staging, checking status code, final destination and hop count. Chains through a rule left over from a previous migration are common and each hop costs crawl.
7. Keep the old sitemaps live and submitted for a few weeks after launch so the redirects are discovered quickly, then replace them with the new ones.
8. Re-run the full inventory against production on launch day and again at day 7, tracking the unmatched and error counts rather than waiting for traffic data to reveal the gap.
## What this produces
A tested old-to-new redirect map covering the complete historic URL inventory, with every unmatched URL either individually resolved or deliberately retired.
## Where this goes wrong
- Building the map from a crawl of the live site, which omits out-of-stock and orphaned products that still hold links and rankings
- Bulk-redirecting unmatched URLs to the home page or a top category, which is treated as a soft 404 and dropped
- Launching with chains from an earlier migration still in the stack, so each legacy URL costs several fetches to resolve
- Removing the old sitemaps at launch, which slows discovery of the redirects exactly when discovery matters most
---
From the QuQi skill library - https://www.quqi.io/skills/replatform-sku-redirect-mapping
Free to download · no account, no email
What you need first
-
A URL inventory assembled from four sources and deduplicated: the database, the old sitemaps, 12 months of Search Console pages, 12 months of analytics landing pages
-
Referring domain counts per old URL, so the linked tail can be prioritised
-
The new platform URL patterns for products, variants, categories and any indexable facets, confirmed on staging rather than from a spec
-
The old-to-new SKU and category identifier mapping from the migration team
Method
-
01
Assemble the inventory from all four sources, not from a crawl. Search Console and analytics history is what surfaces URLs that still earn traffic but are no longer linked from anywhere.
-
02
Join the inventory to the identifier mapping and let pattern rules generate the bulk of the map. Rules are more reliable and more reviewable than a hand-built sheet of 40,000 rows.
-
03
Isolate the rows the rules could not match and rank them by referring domains and organic entrances. This tail is small in count and large in value, and it is the only part needing human decisions.
-
04
Resolve unmatched URLs to the nearest genuine equivalent and accept a 410 for those with nothing behind them. Sending them to the home page is read as a soft 404 and burns crawl for months.
-
05
Decide variant handling explicitly before generating anything. A site that had a URL per size moving to one product page is a many-to-one merge, and every old variant URL still needs its own rule.
-
06
Test the ruleset against the full inventory on staging, checking status code, final destination and hop count. Chains through a rule left over from a previous migration are common and each hop costs crawl.
-
07
Keep the old sitemaps live and submitted for a few weeks after launch so the redirects are discovered quickly, then replace them with the new ones.
-
08
Re-run the full inventory against production on launch day and again at day 7, tracking the unmatched and error counts rather than waiting for traffic data to reveal the gap.
What this produces
A tested old-to-new redirect map covering the complete historic URL inventory, with every unmatched URL either individually resolved or deliberately retired.
Where this goes wrong
-
Building the map from a crawl of the live site, which omits out-of-stock and orphaned products that still hold links and rankings
-
Bulk-redirecting unmatched URLs to the home page or a top category, which is treated as a soft 404 and dropped
-
Launching with chains from an earlier migration still in the stack, so each legacy URL costs several fetches to resolve
-
Removing the old sitemaps at launch, which slows discovery of the redirects exactly when discovery matters most
Use this skill in your own AI
The download is a plain markdown file with the name and trigger in its frontmatter. Where an assistant supports skills it can load itself, that frontmatter is what it reads to decide this one applies.
Claude Code
Save it as ~/.claude/skills/replatform-sku-redirect-mapping/SKILL.md and Claude loads it on its own when what you are doing matches the trigger line. Put it in .claude/skills inside a project instead if the whole team should have it.
Claude
Upload the file in the skills section of your settings. Once it is there it applies itself in any conversation where the trigger fits, so you do not have to remember it exists.
ChatGPT
There is no skills format to install into, so paste the file contents into a Project instruction or a Custom GPT instead. It then applies to every chat in that project rather than only the one you paste it into.
Anything else
Paste the markdown into the chat before your question. It works in any assistant, it just has to be pasted again each time.
Questions about this skill
When do I build the map this way rather than from a crawl of the old site?
When product, variant, category and facet URL patterns all change in one move. The standard approach, crawl the old site and map what you find, fails on a large catalogue because the crawl misses orphaned and out of stock products that still hold links and rankings. Build from the catalogue export and historic data when the tail matters, which on a big catalogue it does.
What has to go into the URL inventory before mapping starts?
A URL inventory deduplicated from four sources, the database, the old sitemaps, twelve months of Search Console pages and twelve months of analytics landing pages, plus referring domains per URL, the new platform patterns confirmed on staging, and the old to new identifier mapping. Skip the history and URLs still earning traffic while linked from nowhere never enter the map at all.
What does the finished map cover, and which rows need a human?
A tested old to new map covering the complete historic inventory, with every unmatched URL individually resolved or deliberately retired. Pattern rules generate the bulk and are more reviewable than a hand built sheet of forty thousand rows. The unmatched tail ranked by referring domains is the part needing human decisions: small in count, large in value.
What ruins a replatform most often?
Bulk redirecting the unmatched tail to the home page or a top category. It is read as a soft 404, those pages drop, and the redirects burn crawl for months while the loss gets blamed on the platform. Accept a 410 where nothing sits behind the URL, and keep the old sitemaps live and submitted for a few weeks so redirects are found quickly.
More in Ecommerce SEO