Comparing two audit runs
A single audit tells you the state of your site today. Comparing two audits tells you the direction — what your last release fixed, what it broke, and what’s been quietly recurring for weeks. VisibilityIQ assigns every finding a status relative to the previous run so you can read a crawl as a diff, not just a snapshot.
What you’ll need
Section titled “What you’ll need”- At least two completed crawls of the same project. The comparison is run-over-run, so the second crawl needs a prior baseline to compare against.
- Access to Audit → Issues, where each finding carries its comparison status.
- Ideally a consistent crawl scope between runs (same start URLs and depth), so a finding that disappears reflects a real fix, not a page that simply wasn’t crawled this time.
Finding statuses
Section titled “Finding statuses”Every finding lands in one of four statuses when a new crawl is compared to the previous one:
| Status | Meaning |
|---|---|
| New | First detected in this run — not present in the prior crawl. Either a fresh defect or a page newly added to the crawl. |
| Recurring | Present in this run and the prior run. A standing issue you haven’t resolved yet. |
| Regressed | Previously fixed, now back. The defect was resolved at some point and has reappeared — the highest-signal status, because it usually means a deploy undid a prior fix. |
| Fixed | Present in the prior run, absent in this one. The defect is no longer detected. |
These statuses are carried on the finding itself, so you can filter the issue list to just New to triage what this release introduced, or to Regressed to catch what it broke.
Why regressions matter most
Section titled “Why regressions matter most”A recurring issue is a known debt — annoying, but stable. A regressed issue is different: something that was correct has silently gone wrong again. The classic cause is a deploy that reverted a canonical fix, re-introduced a JavaScript-injected noindex, or shipped a template change that re-broke render parity across hundreds of pages. Because the engine remembers that the finding was once fixed, it can distinguish a brand-new defect from a reopened one — and a reopened defect deserves a closer look at what changed between the two crawls.
How to read a comparison
Section titled “How to read a comparison”- Open Audit → Issues after a crawl completes.
- Filter to New to see what this run introduced. Pair this with your release timeline — new criticals that line up with a recent deploy are your first stop.
- Filter to Regressed to catch reopened defects. Treat any regressed Critical or High as a release incident.
- Scan Fixed to confirm your prior remediations actually held. A finding you fixed two runs ago that’s still Fixed is a win you can stop worrying about.
- Leave Recurring for planned backlog work — these aren’t urgent surprises, they’re known debt.
Scope interacts with status
Section titled “Scope interacts with status”A finding’s status combines with its scope to tell you blast radius. A New finding at template scope means one code change introduced a defect across every page sharing that template — far more urgent than a New finding on a single page. See Template-level vs. page-level issues for how VisibilityIQ aggregates systemic defects so a template-wide regression shows up as one finding, not hundreds.
Tie comparisons to releases
Section titled “Tie comparisons to releases”The most useful comparison is the one bracketing a deploy: crawl before, crawl after, then read the New and Regressed buckets. That turns the audit into a release gate — you ship, you crawl, and you see exactly which technical-SEO invariants the release upheld or violated before the traffic loss shows up in Search Console weeks later.
Next steps
Section titled “Next steps”- Template-level vs. page-level issues — how scope amplifies a status
- Reading your audit results — severity, confidence, scope, and evidence
- Fixing common issues — resolving the findings a comparison surfaces