Migrations that merge pages need a staging crawl before launch

A question in r/TechSEO asks when a site migration justifies a full staging environment rather than a redirect map and a launch. The case in the thread is a mid-sized ecommerce store moving from a custom CMS to Shopify on the same domain. The URL structure, the navigation and the information architecture (how pages are grouped and linked) all change, and some content is being merged or removed. The answer most of the thread agreed with came from one commenter: “For any site with decent traffic I’d go the thorough route. It doesn’t actually take that much extra time.”

The better rule turns on how much of the site’s structure changes, not on traffic. A redirect map records where each old URL goes. When only URLs change and the structure stays put, that covers most of the risk, and mapping redirects then watching Search Console after launch is reasonable. Once pages are merged, menus are rebuilt and a new platform writes its own tags, the risk moves to what Googlebot finds at the destination. A spreadsheet cannot show that. Post-launch monitoring catches those problems only after they are live, and Search Console reports them after a variable delay.

Three problems a staging crawl finds first

The Shopify move in the thread carries three kinds of failure that a crawl of the staging site surfaces before launch:

• Redirect chains. An old URL that redirects to an intermediate URL, which redirects again, still works in a browser. Google’s site move documentation says permanent redirects don’t cause a loss in PageRank, but it still advises redirecting straight to the final destination. The cost of a chain is mostly operational. Chains are harder to audit, and they hide mapping errors where the intermediate URL was meant to go somewhere else. Before launch they are cheap to flatten.
• Merged pages sent to a page that is not equivalent. When a specific product or article redirects to a broad category page, the category returns a 200 and no audit flags it as broken. Google treats a redirect as a signal that two pages are equivalent and may judge whether they really are. The safer assumption is that such a redirect passes no ranking signals at all, not a reduced share.
• Shopify’s own canonical tags. Shopify writes canonical tags on product variant and collection URLs, and those can conflict with redirect rules. A correctly mapped redirect can land on a page whose canonical tag points somewhere the map never intended.

Faceted navigation (filter pages for size, color or price) makes the last two problems worse. Shopify’s filtered collection URLs vary with the theme and with any search or filter app installed, so redirects from legacy facet URLs have to be built from the patterns the new store actually produces. When a facet combination no longer exists, its redirect lands on a thin filtered page.

Google’s documentation also advises changing one thing at a time, and names a new domain, a new CMS and a new layout as changes to make separately. The migration in the thread changes platform, URLs and architecture together, which is the case where a pre-launch crawl earns its cost. Google tells site owners to prepare and test the new site thoroughly, but it does not say when a separate staging environment becomes necessary.

What to do

For a URL-only change, a redirect map plus monitoring is enough. When navigation, content hierarchy or consolidation changes, work through these in order:

1. Crawl the staging site and the current production site with a crawler such as Screaming Frog or Sitebulb and compare the two, with JavaScript rendering turned on. Screaming Frog defaults to static HTML mode, and Shopify themes and apps can inject or change canonical tags and internal links through JavaScript. Look for redirects longer than one hop, internal links on the new site that point to old URLs, canonical tags that disagree with the redirect destination, and staging pages with no internal links pointing to them. Search Console can also check a staging site before launch.
2. Open product variant URLs directly on staging and compare the rendered canonical tag with what the redirect map expects.
3. Check every consolidation target against the topic the old page ranked for, starting with high-traffic and high-backlink pages. Keep unique pages or send them to a closer match, and merge only content that is truly redundant. For content that is not moving at all, Google’s documentation says the old URLs should return a 404 or 410.
4. Export crawl stats, indexed page count and top landing pages from Search Console before launch. Compare against them daily for the first month, then weekly for three to six months, because ranking loss from consolidation often appears weeks after the first recrawl. Agree traffic and revenue loss limits before launch so a normal dip is not read as a failure.

Watch out for

A staging site that differs from production gives a clean crawl of the wrong site. If staging lacks the apps, lazy-loading or plugins the store will run once live, its canonical tags and links will not match what Googlebot meets after launch. Mirror the production Shopify configuration as closely as possible, then crawl.