Replatforming a large catalogue is not a design project with an SEO task at the end. The URL map is the project — here is the order the work goes in, drawn from moving a 118,000-product flooring store off WooCommerce with 36,786 indexed URLs on the line.
A replatform is usually justified by what the new platform will do: search that copes with the size of the catalogue, a pricing model that can hold what the products actually cost, one API behind the web store and the app. All of that is real, and none of it is the risk.
The risk is that a catalogue site's value is not held in its design or its content but in an address space. Years of rankings, links and crawl history are attached to specific URLs, and replatforming changes URLs. Every URL you fail to account for is a page that stops existing without telling anybody.
On Shopflooring, the old WooCommerce store served 36,786 URLs. The store that replaced it holds a catalogue of 118,651 rows, 117,873 of them live. Everything the first number knew about had to land somewhere in the second, and the mapping had to be finished, checked and deployed before the DNS record changed. After a cutover there is no old site left to read.
1. Inventory every URL before you touch anything
No single source enumerates an address space, and each has a blind spot:
- The old platform's sitemap. The most convenient list and the least trustworthy: it reflects what the platform thinks it publishes today, not what it published years ago and search engines still remember.
- Server access logs, as far back as they go. The only source that shows what is actually being requested, including URLs nothing has linked to in years.
- Search Console's page indexing report. Exportable, and it gives you the state the engine currently has each URL in, not just the URL.
- Analytics landing pages, over the longest window you can still query. Anything that received a session deserves a destination.
- A full crawl of the live site, which catches what the platform generates and nobody wrote down: filter combinations, sort orders, print views, feed endpoints.
- Backlinks, from whichever tool you use. A URL with an external link on it keeps being requested long after you have forgotten it.
Union all of it, then normalise: host, protocol, trailing slash, case, and a decision on each query parameter about whether it changes the page or only the view. Record what every URL returns today — status, any redirect already in place, the canonical it declares, whether it is indexed. Then freeze the list with a date on it. That file is the specification for the rest of the project, and it needs to stop moving.
2. The redirect map is data, not a config file
The instinct is to open the new platform's redirect settings and start typing. Resist it. Build the map as a table — one row per old URL, its destination, the rule that produced that destination, and whether a person has checked it — then generate the platform configuration from the table, so every regeneration produces a reviewable diff.
The map is built rules first. Wherever an identifier survives the move, the rule writes itself: same SKU, same product ID, same slug. On Shopflooring that identifier work had already been done for other reasons — twenty-plus supplier price lists normalised into one schema, 2,257 supplier photos matched on exact SKU. Over 23,000 of the 36,786 old URLs resolved to a 301 straight at the same product, mechanically, because the thing on both sides of the move had the same name.
The remainder is the actual work: categories that split, brands that merged, blog posts, static pages, filtered views, paginated views, and products that no longer exist. For those the rule is simple and expensive — the map has no blank cells, and no cell says "homepage".
A bulk redirect to the homepage is worse than a 404. It tells the person who clicked nothing about what happened, and a redirect to an irrelevant page gets treated as a soft 404 anyway, so you collect both bad outcomes at once. On Shopflooring the URLs with no like-for-like product went to a search result or a brand landing somebody had checked the catalogue could actually answer. That checking is most of the hours in this phase.
3. A canonical is a hint. A 301 is not.
A canonical tag is a request. It tells a search engine which of several near-identical URLs you would prefer it to index. The engine weighs that against your internal links, your sitemap, your redirects and its own reading of the evidence, and it is free to disagree. It disagrees often enough to plan for, and when it does you find out weeks later in a report rather than at deploy time.
A 301 is not a request. It removes the choice: the old URL stops being a place, and everything pointed at it is pointed at the new one instead.
The failure this produces is specific. The new site launches with tidy canonical tags on the new URLs while the old ones are still answering 200 — on an old subdomain, on a staging host nobody locked down, or on a legacy platform still running behind the same domain. Now there are two live addresses for one product and a tag politely asking for one of them to be ignored. Which one gets indexed is out of your hands.
The mild version happens to plenty of sites, including this one: www and the apex both answered 200, both carried canonicals, and Google picked the hostname we had not chosen. www now 301s to the apex, which settled it in one deploy. If two URLs should be one URL, redirect. Save canonicals for cases where both genuinely need to stay live: a sort order, a view toggle, a product reachable through two category paths.
4. Pagination and facets
Two rules cover nearly all of pagination. First, each page of a series is its own URL and should carry a self-referencing canonical. Canonicalising page two to page one is a common and damaging tidy-up: it tells the crawler page two is not a place, so products only reachable from page two are not discoverable along that path. On a catalogue this size there is no "view all" to fall back on.
Second, old paginated URLs need destinations but do not need preserving page for page. Their value is almost entirely internal — they are a crawl path, not a landing page — so a 301 from an old page-two URL to the equivalent category is honest and sufficient.
Facets are the opposite problem: not too few URLs but too many. Colour, width, finish, price band and stock status multiply into an address space that is effectively unbounded, and it is not the crawler's job to guess which combinations you meant. Decide which facets have real search demand and give those a genuine landing page, linked in navigation and present in the sitemap. Everything else is a view: usable, filterable, fast, and kept out of the index. In flooring terms, "waterproof vinyl plank" is a page; "waterproof vinyl plank, 7mm, in stock, sorted by price" is a view of it.
Split the old faceted URLs by evidence. Those with impressions, links or logged traffic get a 301 to the nearest real landing page; those generated, crawled once and never mattering can go to 404 or 410 without ceremony. You are not obliged to carry every URL your old platform emitted.
5. Products that no longer exist
Every large catalogue moves with a tail of discontinued products, and this is where maps get filled in carelessly. Three cases:
- Discontinued with a genuine successor. Redirect to the successor, but apply the test first: would the person who clicked accept this as the same purchase? A newer model in the same range, yes. A different brand at a different price, no.
- Discontinued with no successor. Often better to keep the URL alive at 200 with an explicit "no longer available" state and real alternatives underneath. The page keeps its links, answers the question the visitor arrived with, and can sell the replacement.
- Gone, with nothing close. Return 410 rather than 404 when you are certain. Both remove the page; 410 says you meant it.
The failure to avoid is the mass redirect of a few thousand dead products onto their parent category. It reads as tidy in the map and lands as a soft 404 in the report.
6. Verify before the DNS change, not after
The map has to be complete and tested while the old site is still serving: once the DNS record moves, your ability to compare disappears.
Run the whole map as an assertion suite against the new site on its pre-cutover host. For each row: the source returns 301 — not 302, not 200 — the location header matches the expected destination exactly, and that destination returns 200. Anything that fails is a row in a table, not a mystery. This catches two things eyeballing does not:
- Chains. If the old site already carried redirects you now have two generations of them, and http-to-https or host normalisation adds a third hop. Collapse every chain to one hop at build time by resolving the map against itself.
- Loops. Rare, obvious in hindsight, and capable of taking a category tree offline on launch day.
On Shopflooring every one of the 36,786 URLs was mapped before the DNS cutover, and the sampled verification came back 300 for 300 against production. Keep the suite afterwards: it becomes the regression test that stops a later routing change quietly reopening the hole.
Two cutover details worth stating plainly:
- Do not block the old paths in robots.txt. A disallow stops the crawler fetching the URL, which means it never sees the 301. This is a common self-inflicted wound in a replatform.
- Leave the old sitemap reachable for a while. It is the fastest way to get old URLs re-crawled so the redirects are found. The new sitemap should contain only canonical URLs that return 200 — never a redirect.
7. What to watch for the following month
Expect movement. A large address space is re-crawled unevenly and over weeks, deep URLs last, and rankings wobble while the engine reconsolidates. The question is not whether anything moved but whether the shape is right. The page indexing report is the instrument that matters:
| Reason | What it means | What to do |
|---|---|---|
| Page with redirect | Old URLs are being re-crawled and the 301 seen | Nothing. It should climb, then settle |
| Not found (404) | A URL you did not map, or a link you did not know about | Add the row; find where the request came from |
| Soft 404 | A destination that does not answer the request, usually a redirect to something unrelated | Re-point it at something the catalogue can answer |
| Duplicate without user-selected canonical | Two live URLs for one thing, and the engine chose | Treat it as a missing 301, not a missing canonical |
| Crawled — currently not indexed | Thin category or facet pages with nothing to distinguish them | Decide whether the page should exist at all |
Watch crawl stats too. Request volume should spike as the old surface is re-crawled, and average response time should not climb with it: a site that slows under crawl load gets crawled more slowly, which stretches re-indexation out.
Then run one check worth more than any sitewide chart. Take the top URLs by clicks from your last full quarter before the cutover and, for each, confirm either that it still ranks or that its redirect target now ranks for the same queries. It is a short list, checkable in an afternoon, and it tells you whether the map did its job long before the aggregate lines have stopped moving.
Resist unwinding decisions early: the expensive mistake after a clean cutover is a second, panicked migration on top of an incomplete re-crawl.
The part that is not optional
All of the above is unglamorous data work, and it is the difference between a replatform and an outage with a new design on it. The engineering is what the business is buying: a pricing engine that resolves a room to boxes and waste, search that stays usable across 118,000 products, real-time freight, one API behind the web store and the native client. The URL map is what makes any of it survivable. On Shopflooring that map was 36,786 rows, built and checked before the DNS record moved, so no ranked URL became a 404 on the day the new store went live.
Catalogue Engine is the system that came out of that work. If you are moving a deep catalogue and the rankings are the thing keeping you awake, tell us what you are moving — the URL inventory is the first thing we would ask for.