A redirect map is the list of every old URL that matters and the new URL it should permanently redirect to after a replatform. It decides how much of your search traffic, backlinks and bookmarked links survive the move. The maps that work are built from several data sources, not just a crawl; match products and categories by ID or SKU rather than by guesswork; handle the awkward URLs (parameters, pagination, files, old campaigns) explicitly; and are tested automatically before and after launch.
Why replatforming breaks URLs
Every platform has its own URL conventions. Shopify uses fixed prefixes such as /products/, /collections/, /pages/ and /blogs/. WooCommerce defaults to /product/ and /product-category/ unless changed. BigCommerce lets you customise product and category URL formats. Moving between them almost always changes most of your URLs, even when every product and category survives.
Search engines treat a changed URL as a new page. A permanent (301) redirect from the old address to the new one is how you tell them, and every visitor with an old link, where the page went. Google’s guidance on site moves with URL changes is the reference for how to do it and what to expect while the change is processed.
Step 1: collect every URL that matters
A crawl of the current site is the starting point, not the whole list. Old URLs that are no longer linked internally still receive traffic and links. Combine:
- A full crawl of the current site, including products, variants with their own URLs, categories, pagination, content and files.
- Search Console: every page with impressions or clicks over the last 16 months.
- Analytics: landing pages with sessions over the last year or more.
- Backlink data: pages other sites link to, including ones that already return errors.
- Existing redirects on the current platform, so old redirects keep working after the move.
- The XML sitemaps and any feeds (shopping, marketplaces) that point to product URLs.
- Campaign URLs from email, ads and printed material that may still be in circulation.
Deduplicate, normalise (lowercase, consistent trailing slashes, protocol and host), and keep a column for where each URL came from and how much traffic and how many links it has. That column is what lets you prioritise when time runs short.
Step 2: match old to new by identity, not by name
Match products by SKU or product ID, and categories by their ID or an agreed mapping table, then look up the new URL for that record on the new platform. Matching by title or by guessing a slug pattern fails as soon as a product has been renamed or two products share a name.
This is also why catalog cleanup and URL mapping should be planned together. If you merge duplicates, retire old products or restructure categories during the migration, the map needs to know. Our guide to cleaning a catalog before you migrate it covers the data side.
Rules for the target of each redirect
- Product to the same product; category to the same or closest category; article to the same article.
- Discontinued products with no equivalent: the closest category, or a helpful 404 page if nothing is relevant. Do not redirect everything to the homepage.
- Merged products: the surviving product.
- Every redirect goes directly to the final URL in one hop, never through another redirect.
Step 3: handle the awkward URLs
Most failed maps fail on the edge cases rather than the main products. The ones we plan for on every migration:
| URL type | Common problem | What we do |
|---|---|---|
Query parameters (?colour=red, ?page=2) |
Ignored or dropped by redirect rules | Decide per parameter: preserve, map or drop; test with real examples |
| Pagination | Page 2+ redirected to page 1 or to nothing | Map to the new category’s pagination, or to the category |
| Case and trailing slashes | Half the map fails on /Product/ vs /product |
Normalise before matching; test both forms |
| Variant URLs | Old platform had a URL per variant, new one does not | Redirect to the product, preselecting the variant if the platform supports it |
| Images and PDFs | Linked from other sites and forgotten | Redirect important files to their new location |
| Blog tags, archives, author pages | Generated in bulk, low value | Map the few with traffic; let the rest go to the blog index or 404 |
| Customer account and checkout URLs | Bookmarked by returning customers | Redirect to the new login and account pages |
| Old campaigns and vanity URLs | Still printed on packaging or in emails | Collect from marketing; keep them working |
Step 4: implement redirects on the new platform
Each platform handles redirects differently. Shopify has a built-in URL redirects feature with bulk import; BigCommerce manages 301 redirects in its admin and via its API; on WooCommerce, redirects are usually handled by the web server or a redirect plugin. Check the platform’s limits and how it treats query strings before you import thousands of rows, and keep the master map in a spreadsheet or repository, not only inside the platform.
Use permanent redirects. Google’s documentation on redirects explains how different redirect types are treated.
What a map row looks like
A map that others can check and maintain has the same columns on every row. Ours usually include:
- Old URL, normalised, and the new URL it redirects to.
- Type: product, category, content, file, account, campaign.
- Record ID or SKU used to match it, so anyone can see why it points where it does.
- Source: crawl, Search Console, analytics, backlinks, old redirect.
- Value: clicks, sessions and referring domains, to prioritise review.
- Decision: same item, closest equivalent, merged, retired to category, or 404.
- Test result on staging and on production, with the date.
Rows with high value and a decision other than “same item” get a person’s review. Everything else can be generated and tested in bulk.
Who signs off the map
Three people should agree on it before launch: whoever owns SEO (the decisions for retired and merged pages), merchandising (which products and categories survive, and their closest equivalents) and the developer who implements and tests the redirects. Marketing adds campaign and vanity URLs. A map built by one person in isolation usually misses one of those lists.
Step 5: test before and after launch
Never rely on spot checks. Before launch, run the whole map against the staging site and check that every old URL returns a single redirect to a URL that returns 200. After launch, run it again against production on day one, and repeat weekly for the first month.
- Every mapped URL: one 301, to a live page.
- No chains or loops.
- Query strings behave as planned.
- No 404s for URLs that had traffic or links (check Search Console and server logs daily at first).
- Internal links on the new site point to new URLs directly, not through redirects.
- The new XML sitemap lists only new URLs, and it is submitted.
How long to keep redirects
Keep them for as long as you reasonably can. Google’s site move guidance recommends keeping redirects in place for at least a year, and in practice old links on other sites and in emails keep arriving for much longer. Removing redirects to “clean up” is one of the ways stores lose traffic a year after a successful migration.
What to expect in the weeks after launch
Some fluctuation in rankings and traffic is normal while search engines recrawl and process the redirects. What matters is the direction over several weeks and whether any drop is concentrated in a group of pages, which usually points to a mapping problem. Compare organic clicks by page type against your pre-launch baseline weekly. The monitoring plan in redesigning without losing rankings or revenue applies to migrations too.
Our store migration team builds the redirect map from all of these sources, tests it on staging and in production, and monitors the first weeks after launch. Search visibility after the move is covered by our ecommerce SEO work.