You test a migration before going live by building the new site on a private staging environment and systematically comparing it against the old site, item by item, so you find gaps while they are still cheap to fix. The mindset that makes this work is treating launch as the deadline for a comparison, not the moment you start checking. The comparison has a clear checklist. Confirm URL coverage: every old URL either exists on the new site or has a redirect mapped to a real equivalent. Confirm content parity: no page is missing or thinned. Confirm metadata parity: titles, descriptions, and canonicals carried across. Confirm images are present and not still loading from the old site. Confirm internal links point at new addresses. Confirm crawl rules: no leftover staging noindex or blocking robots.txt. Test that redirects resolve in a single hop to the right page, and crawl the staging site to catch broken links and errors. Fixing these on staging costs minutes, while fixing them after launch costs rankings, because search has already seen the broken state. WPBuildAI scans your old site and returns the URL list, content, and metadata, giving you the baseline to compare the new site against.

Add the host variants to the test plan, because Google’s June 2026 guidance treats all subdomains and both the www and non-www forms as part of the same move, and variants are the thing most staging checklists never exercise.

Why testing before launch matters so much

The economics of a migration are lopsided, which is the whole argument for testing first. A gap caught on staging is a quiet edit nobody outside the team ever sees. The same gap caught after launch is expensive, because search engines and visitors have already encountered it: pages have 404ed, rankings have started to move, and the recovery takes weeks even after you fix the cause. Migrations are also where many things change at once, which is why they carry real risk, as the risks of migrating to a new CMS lays out. Testing before launch converts that risk into a checklist you complete in private, instead of a series of public incidents you scramble to fix. The goal is to launch a site that has already been proven complete.

Start from a baseline of the old site

You cannot test parity without something to compare against, so the first step is to capture the old site as a baseline. That means a complete record of its URLs, its content, and its metadata, taken while the old site is still live. Memory is not a baseline; sites carry more URLs than anyone remembers, as Web Almanac 2024 (HTTP Archive) shows, so a remembered checklist misses exactly the pages that break silently. An objective baseline turns testing from guesswork into a comparison: here is what existed, now confirm each item survived. WPBuildAI scans the old site and returns its URL list, content, and metadata, which is the baseline the rest of the testing checks against, the same inventory you would build for a content audit before a migration.

Build and check on private staging

Do the building and the checking on a staging environment that is private, meaning kept out of search with a noindex or access control while it is in progress. Staging lets you assemble the full new site, run the comparison, and fix problems without any of it being visible to search or visitors. The one rule that matters most here is to remember that staging is private on purpose, which sets up the most important launch check later: removing that privacy. While on staging, you can crawl the new site freely, click through it, and compare it to the baseline section by section, all without consequence. This safe space is what makes thorough testing possible, which is why understanding staging is foundational, as covered in how pushing staging to live affects SEO.

The comparison checklist

With a baseline and a staging site, work the checklist. URL coverage: every old URL must either exist on the new site or have a redirect mapped to a true equivalent, so none becomes an orphaned 404. Content parity: each page present and complete, not thinned in the rebuild. Metadata parity: titles, descriptions, and canonicals carried across, since these invisible signals carry rankings, as the Backlinko analysis reflects. Images: present on the new site, not still loading from the old one. Internal links: pointing at new addresses, not relying on redirects. Each line is a comparison against the baseline, and each gap you find is one fewer post launch incident. Work the list completely rather than spot checking, because the items you skip are the ones that break.

Test the redirects specifically

Redirects deserve their own testing pass, because they are both critical and easy to get subtly wrong. For a representative set of old URLs, and especially your highest value ones, confirm that each returns a redirect, that it is a permanent 301, that it resolves in a single hop rather than a chain, and that it lands on the correct equivalent page rather than the homepage, all as the site move guide describes. Traffic and links concentrate on a minority of pages, as the Ahrefs study shows, so test those first and most carefully. A redirect that exists but points wrong, or chains through extra hops, is a quiet failure that this pass is designed to catch before launch rather than after.

The launch-moment check: make it indexable

The single most dangerous gap is the one that comes from staging itself: the noindex or blocking robots.txt that kept staging private being carried to production. So the final, non negotiable check at launch is to confirm the live site is indexable: the staging noindex removed, and a robots.txt that allows crawling of your real content. This is the check that, if missed, can deindex the entire site, the failure described in detail elsewhere, and it is the reason staging privacy must be deliberately reversed rather than assumed off. Build a step into your launch that explicitly verifies indexability on the live URLs, because everything else you tested is worthless if search is told not to index the result.

Steps to test a migration before launch

  1. Capture the old site as a baseline of URLs, content, and metadata.
  2. Build the new site on private staging, kept out of search.
  3. Compare against the baseline: URLs, content, metadata, images, internal links.
  4. Test redirects: present, 301, single hop, correct target, top pages first.
  5. Crawl staging to catch broken links and error pages.
  6. At launch, confirm indexability: remove staging noindex, allow crawling.

Worked example: a tested launch that held

Imagine a team migrating a content site who refuse to launch untested. They capture the old site as a baseline of URLs, content, and metadata, then build the new site on private staging. Comparing against the baseline, they find a batch of old articles whose URLs changed with no redirect mapped, two pages that came across thinned, and a set of images still loading from the old server, and they fix each on staging. They test the redirects for their top fifty pages and catch three that pointed at the homepage instead of the real article. They crawl staging and clear a handful of broken internal links. At launch, they remove the staging noindex and confirm the live pages are indexable. The result is a launch with no traffic dip, because every gap was found and fixed in private, exactly what a launch checklist is meant to ensure.

Limitation: testing reduces risk, it cannot eliminate it

It is honest to say what testing does and does not promise. Thorough pre launch testing catches the avoidable, mechanical failures, missing redirects, lost content, stray noindex, broken links, which are the causes of most migration damage. It cannot guarantee zero ranking movement, because some reconciliation by search happens only after the new URLs are live and recrawled, and that settling is normal. Testing also reflects the site at the moment you check it, so a late change after testing can reintroduce a gap, which is why the launch indexability check is separate and final. Treat testing as removing the known failure modes, not as a promise of a perfectly flat launch, and pair it with monitoring afterward to catch anything that only appears live.

Common mistakes

  • Testing from memory instead of an objective baseline of the old site.
  • Launching without a private staging environment to check on.
  • Spot checking a few pages instead of working the full comparison.
  • Confirming redirects exist without checking they are 301, single hop, and correct.
  • Forgetting the launch check to remove the staging noindex.

Key points

You test a migration before going live by building the new site on private staging and comparing it against a captured baseline of the old site: URL coverage and redirects, content and metadata parity, images, internal links, and crawl rules, plus a crawl for broken links. The economics are the whole point, since fixing a gap on staging costs minutes while fixing it after launch costs rankings. Test redirects specifically for being present, permanent, single hop, and correctly targeted, prioritizing your highest value pages. Make the final, non negotiable launch check the removal of any staging noindex or blocking robots.txt, because that alone can deindex the site. Testing removes the known failure modes; pair it with post launch monitoring for what only appears live. WPBuildAI scans your old site and returns the URL list, content, and metadata, giving you the baseline to compare the new site against. Send your web address for a free analysis.

Not affiliated with WordPress, Lovable, Webflow, Shopify, Wix, or Squarespace.