/ GUIDE — 6 Min. Lesezeit

How to audit a site migration (before and after it goes live)

Use list mode, redirect chains and crawl comparison with URL mapping to make sure a redesign or domain move loses nothing.

The two moments that matter

A migration goes wrong in one of two ways: old URLs stop resolving, or the new site lost pages, titles or links the old one had. The first shows up as 404s and redirect chains; the second only shows up if you compare. Nosy Bat covers both — the audit is two crawls and a list.

Before launch: baseline crawl, URL list, staging compare. Launch day: list-mode check, full crawl and compare. After: a scheduled crawl for the first month.

Before launch

1. Baseline the old site

Run a full spider crawl of the live site and Pin it in History, so retention never drops its data (up to 5 pinned crawls are kept in full). This is the reference everything is compared to.

2. Export the URL list

From that crawl, Exports → Pages (CSV). Its URL column is your list of everything that must still resolve after launch.

3. Crawl staging

If the new site is on a staging host, crawl it too — HTTP auth user, HTTP auth password and Custom request headers are in Advanced options → Configuration. Then, on the staging crawl, open Compare, pick the baseline under Compare with, and add a rule under URL mapping (optional): Find (regular expression) ^https://www\., Replace with https://staging.. The mapping rewrites the baseline's URLs, which is why it runs from production to staging. Pages removed then lists the pages the new site lost, Pages changed the titles and canonicals that changed, and New issues what the redesign introduced.

Compare rewrites the baseline's URLs before matching. On the staging crawl, ^https://www\. → https://staging. lines each production page up with its staging twin.

Launch day

4. Check every old URL

In New crawl, set Mode to List (check URLs) and paste the list from step 2 into URLs to check, one per line. Nosy Bat fetches each one and records every hop. Then look for:

Internal client error (4xx) on Issues — old URLs with no redirect: the most urgent fix
Redirect chain — old → interim → final, listed under Links → Redirects → Chains; collapse each to a single 301
Redirect loop — under Loops
Temporary redirects — Exports → Redirect chains (CSV) gives each URL's first status and every hop, so a 302 that should be a permanent 301 is one filter away

Before: /old redirects to /interim, which redirects to /new — two hops. After: /old goes straight to /new with a single 301.

5. Crawl the new site in full

Run a spider crawl of the new site and Compare it with the pinned baseline — no mapping needed now. Confirm Pages removed is empty or explained, Indexable pages hasn't dropped, and the Sitemaps family is clean (generate one from this crawl if needed).

Staging on another host? URL mapping compares it to production before anyone else sees it. See plans →

After launch

6. Schedule the crawl for the first month

Add a schedule under Schedules — weekly from Growth up, monthly on Starter — with Email to workspace owner under Export targets, so late-appearing problems (cached old links, a CMS re-publishing old slugs) are caught. Keep the baseline pinned until the comparison has been clean twice.