Free tool · Before and after
Website launch and migration check
Compare a new site, redesign, or migrated page with the current live version before you launch. Both are audited with the same rules, so you can see which crawler-access, content, and identity checks got worse, with the evidence from each version.
Enter both versions
Compare the current site with the new version
How to use it
Check the new version before it replaces the old one
- 1
Enter the current live site or page, then the new version: a staging host, the new domain, or the new page URL.
- 2
Both versions are audited with the same rules: robots.txt access for documented AI crawlers, the public page HTML including noindex rules, structured data, llms.txt, and identity signals.
- 3
Fix the regressions first. Each one shows the evidence from both versions and an action for the new version.
- 4
Run the check again after your changes, and once more after launch against the live site.
Understand the result
What the check confirms, and what it cannot tell you
What it can confirm
- Which audit checks are weaker, stronger, or unchanged in the new version, under the same rules and at the same time.
- A robots.txt rule on the new version that blocks crawlers the live site allows, such as a staging Disallow: / carried into production.
- A noindex rule in a robots meta tag or X-Robots-Tag header on the new version that the live site does not send.
- Structured data, page content, or identity signals that the live site has and the new version lost, such as JSON-LD removed during a redesign.
- Differences in server-delivered page content, foundational HTML, business clarity, and identity signals, checked with the same rules on both versions.
What it does not check
- Pages behind a login, password, or IP allowlist cannot be checked. Use a publicly reachable preview URL.
- Redirect mapping between old and new URLs, and pages other than the two you enter.
- Whether the launch changes rankings, traffic, AI citations, or how any provider uses the site.
Related tools
After the comparison
Common questions
Questions about launch and migration checks
Can I compare a staging site with production?
Yes, if the staging site is publicly reachable over HTTPS. A staging site that requires a password or blocks unknown visitors returns an error for that side instead of a comparison.
Can I compare two specific pages instead of two homepages?
Yes. Enter a full https:// URL for either side. The page-level checks use that page, while robots.txt and llms.txt are always checked at the site level.
Why does a staging site often show a robots.txt regression?
Staging sites commonly block all crawlers with Disallow: /. That is correct on staging but harmful if the same file ships to production, so the check reports it as a regression to confirm before launch.
Does the check catch a noindex left over from staging?
Yes. Both versions are checked for a noindex or none rule in robots meta tags and the X-Robots-Tag response header. A rule on the new version that the live site does not send is listed as a regression. Rules added by JavaScript after the page loads are not checked.
What does Not comparable mean?
A check is listed as not comparable when it could not run on one version, for example because the page could not be retrieved, or when it only runs on request. Checks that report only problems count as passed on a version where they found none, so a problem added in the new version is still listed as a regression.
Is anything stored?
No. Both versions are audited for this check and the result is returned to your browser. Analytics record only that a check started and finished, never the sites you entered.