Compare two crawls

The problem

You shipped a migration, a redesign, or a batch of redirect fixes, and now you need proof, not a hunch, that it worked. Did the redirects you added actually take effect, or are some URLs still 404ing? Did the broken-link count go down, or just move? Did the fix cycle introduce anything new — a fresh batch of redirect chains, a missing canonical, a spike in 5xx errors nobody caught in staging? Without a "before" to hold against the "after," you're left re-reading the same live site and trusting that it looks fine.

Do it in RacingRoach

RacingRoach doesn't have a dedicated crawl-diff view today — the mechanism you actually use is simpler and just as reliable: every crawl is a single reopenable file, written in crash-safe transactions, so a finished crawl is a durable snapshot you can set aside and come back to. That means the workflow is entirely in your hands:

1. Crawl the site before the change ships and let it finish. Keep the crawl file — don't overwrite it with the next run.
2. Ship the migration, redesign, or fixes.
3. Run a fresh crawl of the same site after the change is live. This is a new, separate crawl file, not a re-run of the old one.
4. Export both crawls to CSV — the whole crawl or the specific view you care about (issues, status codes, redirects) — using the same streaming export both times, so the two exports have the same columns and the same shape.

Because each export streams from disk rather than loading a crawl into memory, this works the same way whether the site is 500 pages or 500,000 — you're never blocked from comparing large crawls just because they're large.

Interpret the results

Once you have two CSVs, the comparison itself is a handful of concrete questions, not a vague "does it look better":

• Issue counts by kind. Did broken links, redirect chains, missing titles, or missing canonicals go down? A kind that didn't move is a fix that didn't land, or landed somewhere the crawl didn't cover.
• Status-code distribution. Compare the 2xx/3xx/4xx/5xx split between the two exports. A shrinking 4xx share and a growing clean-2xx share is the clearest signal a redirect or link-fixing pass actually worked; a new 5xx presence after a migration is worth chasing down before anything else.
• URL-level deltas. Match rows on URL between the two exports (a `VLOOKUP`/`XLOOKUP` in a spreadsheet, or a join if you're comparing in a notebook) to find which specific URLs are new, which disappeared, and which changed status or issue kind. This is where you catch the one redirect that was missed, not just the aggregate trend.

Fix it — a practical workflow

The habit that makes this easy later is naming the crawl files by milestone as you go, not scrambling to remember which file was which after the fact:

• site-before-migration.redb and site-after-migration.redb for a domain move or platform switch.
• site-before-redirect-fixes.redb and site-after-redirect-fixes.redb for a targeted cleanup pass.

Export the issue summary and the full URL list from each file to CSV, open both in a spreadsheet, and diff on URL and issue kind as above. There's no built-in comparison view to do this for you yet — the honest answer today is a spreadsheet, not an in-app report — but because both exports come from the same reopenable, crash-safe crawl format, the comparison is a five-minute spreadsheet task, not a re-crawl-and-guess exercise. Keep both crawl files around after the comparison; you'll want the "after" one as next cycle's "before."