The worst time to discover that half your product pages dropped out of the index is three weeks after a migration, when the traffic graph has already flattened and nobody can say for certain what the site looked like before. Once the old environment is gone, so is your reference point. That is why the real work of a migration happens before launch, when you still have both the current site and the time to record exactly how it behaves.
A migration doesn’t need expensive software to survive. What it needs is a disciplined set of before-and-after measurements, and free tools cover almost all of it if you assemble them deliberately rather than reaching for whatever is open in a browser tab.
Map What You Actually Need to Verify
Start by writing down what “nothing broke” actually means for your site. It is rarely one thing. Indexable URLs should still resolve and still be indexable. Redirects from old paths should land on the right new paths in a single hop. Canonical tags, meta robots directives, and the robots.txt file should carry over intact. Structured data and hreflang, if you use them, should survive the template rebuild.
Turn that into a short checklist of verifiable claims. Each line is something you will confirm as true both before and after the move. This list, not any particular tool, is the backbone of the whole exercise. Tools are just how you collect evidence against it.
Capture a Pre-Migration Snapshot of Every Indexable URL
Your first snapshot is the complete inventory of what the site currently exposes to crawlers. Pull your XML sitemaps and extract every URL they declare, then cross-check that against a full crawl so you catch pages that are indexable but missing from the sitemap. You want both lists because migrations often break the ones that were never in the sitemap to begin with.
A lightweight XML sitemap checker and URL extractor from RapidIndexChecker turns a sitemap file into a plain list of URLs you can save, diff, and re-run after launch, which is exactly the kind of durable artifact a migration audit depends on. Export the results to a spreadsheet with the response code and canonical for each URL. That flat file is your ground truth, and it costs nothing to keep.
Do this for staging too if you have access. Comparing the staging inventory to production early can surface missing pages before they ever reach live users.
Line Up Free Tools Against Each Migration Risk
With the checklist in hand, assign a tool to each risk rather than running everything and hoping the important thing shows up. A desktop crawler handles the bulk inventory, status codes, and redirect chains. A browser’s built-in developer tools let you inspect rendered HTML and confirm that canonical and robots tags survive JavaScript rendering. Search Console gives you coverage and the current index state you’ll want to watch afterward. A rich results test confirms structured data still validates.
The point is coverage without overlap. When two tools measure the same thing, decide in advance which one you trust for that measurement so you are not debating readings on launch day.
Save Baseline Directives and Redirect Behavior for Comparison
Directives are where silent damage hides. Save the exact contents of the live robots.txt file, a list of which URLs carry a noindex, and the canonical target for every important page. Record the current redirect map too, mapping each old URL to where it currently points, so you can confirm the new redirect layer reproduces it.
Keep these as dated files, not screenshots. A migration in a fast-growing market like the Denver metro often ships under real deadline pressure, and a text file you can run a diff against beats squinting at two images when something looks off at midnight.
Run a Post-Launch Verification Pass the Same Day
The moment the new site is live, re-run every capture using the identical process. Extract the sitemap URLs again and diff them against your saved list. Re-crawl and compare status codes and canonicals line by line. Spot-check the redirect map by requesting a sample of old URLs and confirming single-hop, correct-target responses.
Discrepancies at this stage are cheap to fix and expensive to ignore. Catching a broken redirect pattern on launch afternoon, while a Denver team still has the deployment fresh in mind, is a different situation entirely from finding it after rankings have already slipped.
Assemble the toolkit before you touch the DNS, and the migration stops being a leap of faith and becomes something you can simply confirm, page by page.