How to migrate a large catalog without losing search traffic

Keep every URL that earns impressions, map each old page to a specific new page rather than a generic one, and launch with at least as many indexable pages as the old site had. Most search traffic lost in a migration is not lost to broken redirects. It is lost to pages that used to exist and do not anymore. For a large catalog, where the long tail of category and product pages carries most of the traffic, that is the whole game.

Inventory before you build

Export twelve months of Search Console page data, sorted by impressions. That list is the scope of the migration. Every URL on it needs an answer: it comes across, it redirects to one specific equivalent, or you have decided to lose its traffic on purpose. Doing this after launch is possible, and it costs you the weeks between launch and the day Google finishes reassessing the site.

One to one, never many to one

A redirect from a specific page to a generic one tells Google the specific page is gone. The ranking goes with it, and the destination is often treated as a soft 404. Six service pages redirected into one services index will not rank for six clusters of queries. They will rank for none of them. The same is true of old blog posts redirected to the blog index and old category pages redirected to the home page.

If a page has no equivalent on the new site, the honest options are to build one or to let the URL return a 410 and accept the loss. A redirect to somewhere generic is the worst of the three, because it looks like it worked.

Category and filter URLs are the bulk

For a large catalog, most organic entries are not product pages. They are category pages and the faceted URLs under them: brand within category, size within brand, fitment within all of it. Decide before launch which of those combinations are indexable pages with their own canonical, and which are canonicalised back to the parent. An index-first build makes this a query rather than a platform setting, which is one of the quieter reasons to build it that way.

Keep the old site answering

Run the old site in parallel until the new one has been fully recrawled. Redirects at the edge, from old URL to new, mean that anything you missed still resolves, and the inventory export tells you what Google is still requesting. Turn the old host off only when the requests stop, and keep the DNS record out of the picture the day you do. A dead host that still has a DNS entry keeps getting crawled and keeps reporting errors against your domain.

Watch the right numbers

• Indexed page count, not sessions. Sessions lag by weeks; the index count tells you within days whether the site is being read.
• Impressions by page, compared against the pre-migration export. This is where a lost cluster shows up first.
• Search Console data arrives two days late. A dashboard that ignores this averages in an empty day.
• Expect Google to reassess the whole site three to five weeks after cutover. A cliff on that day is the reassessment, not a deploy.

What we learned doing it to ourselves

When we moved our own site, we consolidated six service pages into one. Each had ranked for its own cluster of queries, and the impressions for all of them went with the pages. Non-brand impressions fell by half in the month after the reassessment. The redirects were correct and the site was faster. The pages simply did not exist. We restored them, and the recovery is now a matter of getting them recrawled.

The lesson generalises: redirect hygiene stops the bleeding, but only the pages themselves refill the index. Build the inventory first. The rest of the series is at ecommerce for large catalogs.