What broke in the move?
Paste the old address and the new one. Both are crawled from outside the network with the same checks, then compared as before and after, so the regressions that a migration introduces are named instead of buried in a side-by-side.
How this works
Both addresses get the same bounded audit, then each check is compared as before versus after. A check that was clean before and is worse now is a regression and is listed first; a check that improved is listed second; ties are counted. It does not invent competitor data or claim a full crawl of either site, so a regression it names is one it actually saw.
What the site migration checker compares
Give it the old address and the new one. It runs the same bounded audit on each: a sample of pages, read the same way, covering reachability, indexation, markup, links and delivery, and catalogue signals where the site is a store. Each check produces an error and warning count for both sites, and the sample is the same size for both.
It then compares the two as before and after. A check that was clean on the old site and is worse on the new one is a regression. A check that improved is listed separately, and checks that are unchanged are counted rather than listed. The order of the before and after counts makes the direction of each change clear at a glance.
How to read the migration result
Regressions are the point: they show what the move made worse. Each entry shows the check, a sentence describing the change, and the before and after counts. Improvements show what the move fixed, which is worth confirming rather than assuming, since a move can quietly help some checks while breaking others, and both are worth knowing. A small change in count can still be worth attention.
The audit is a bounded sample, not a full crawl, on both sides. A clean result means no worsening was seen in the pages checked; it does not prove the move broke nothing elsewhere. The comparison looks at technical and content signals, and a regression is only reported when the audit actually saw it on both sides, so it is evidence rather than a guess.
What migrations commonly break
A platform or host change rebuilds templates and routing, and that is where regressions cluster: lost canonical tags, changed redirects, dropped structured data, altered titles, or a sitemap that no longer lists the same pages. Routing is the most common source, because an old address can stop resolving to its new equivalent. Capturing the before state while the old site is still live makes the comparison reliable.
These matter because a move should preserve what search engines already understood. If a new template omits markup the old one carried, the new site can look like a different, weaker site even when every page loads. Comparing before and after puts those changes in one list and makes them visible even when the new site looks fine page by page.
Fix the regressions first
Work down the regression list from the top, since it is ordered by the size of the change. For each one, fix the source template, routing rule or export rather than the individual page, so the repair applies across the new site. Confirm the old URLs still reach an equivalent page, and keep a note of each fix so a later run can check it.
Run the check again after the fixes and confirm the regression no longer appears. Then test a few key old addresses directly to ensure they reach the intended new page, and update internal links and the sitemap to the new addresses. If an old address still redirects through several hops, flatten it so it reaches the new page directly. A direct redirect is better than a chain of hops.
When to use related checks
Use redirect check for the old addresses and sitemap diff to confirm the new sitemap lists the moved pages. compare is the same engine used head to head rather than before and after, when the question is a competitor instead of your own move. Run the comparison once before the move and again after, so the two runs are comparable rather than relying on memory.
The redirect chain guide covers migrating URLs, and the free audit checklist sets the wider pass. For a page that now fails, see the not-found fix, which applies when a migrated page no longer resolves at its new address. Work from the top of the regression list, fixing the source rather than one page at a time, then run the check again to confirm the improvement holds.