“We fixed 40 issues this month” is one of the most common lines in an SEO report and one of the least reliable. Issue counts fall for many reasons that have nothing to do with fixes: a smaller crawl, a timeout, a changed threshold, a redirect that hid a page. Comparing audits fairly takes a little discipline. Here is the method.
1. Keep crawl settings like-for-like
Before comparing anything, check that both audits used the same:
- start URL (and host variant)
- page limit, and whether either crawl hit it
- check thresholds, such as title length range, thin-content word count and maximum click depth
- crawler behaviour, such as robots.txt handling, rendering and user agent
If the older audit crawled 1,000 URLs and the newer one stopped at 250, a lower issue count proves nothing. Put the settings of both audits at the top of any comparison you share, and note any difference.
2. Define what “the same issue” means
To match issues between audits you need a stable identity. A practical definition is:
issue type + affected URL + source URL + target URL
So “broken link from /services/ to /old-pricing/” in March and in April is the same issue. A broken link from a different page to /old-pricing/ is a different one. Avoid matching on message text, which changes when tools are updated, or on counts alone.
3. Use five groups, not two
The classic “new vs fixed” split hides the most important case. Use five groups:
| Group | Meaning |
|---|---|
| New | In the newer audit; the older audit checked the same thing and it was fine. A regression. |
| Resolved | In the older audit; the newer audit re-checked it and it’s gone. |
| Still present | In both audits. |
| First seen | In the newer audit, on pages the older audit never checked (e.g. a bigger crawl, or a new check). Not a regression. |
| Not re-checked | In the older audit, but the newer audit didn’t check it again (page not crawled, crawl cancelled, or the URL now redirects). Not a fix. |
“Not re-checked” is where honest reports differ from flattering ones. If a page wasn’t crawled this month, its old issues are unknown, not resolved.
The same logic applies to new checks. When your tool adds a check, its findings should appear as first seen the first time, not flood the report as “new problems”.
4. Explain coverage differences
Alongside the issue groups, show:
- URLs crawled by both audits, by the older only and by the newer only
- whether either audit hit its page limit or was cancelled
- URLs whose HTTP status improved (404 → 200) or regressed (200 → 500)
A short coverage line such as “11 URLs crawled by both audits, 1 only by the older one” keeps everyone reading the numbers correctly.
5. Avoid single “health scores”
Composite scores are tempting for clients, but they hide exactly the problems above. Most scores improve when the crawl gets smaller, because fewer pages means fewer issues. If you must summarise, report counts by severity alongside the coverage they come from.
6. Turn the comparison into a client narrative
A comparison is raw material. For a client report:
- Lead with regressions (new confirmed errors, URLs that started failing). They need action.
- Show verified progress: resolved issues grouped by root cause, e.g. “the footer link to
/old-pricing/was fixed on all 212 pages”. - State what wasn’t re-checked and why, in one sentence.
- List what’s still present, prioritised, as next month’s plan.
7. Make it routine
Comparisons are most useful on a fixed rhythm: weekly for sites under active development, monthly for stable ones, with the same settings every time. A scheduled audit that compares itself with the previous completed audit, ignoring failed or cancelled runs as a baseline, does most of this automatically. Then your job is interpretation rather than spreadsheet diffing.
Checklist
- Same start URL, page limit, thresholds and crawler behaviour (or differences stated)
- Issue identity = type + affected + source + target URL
- Five groups: new, resolved, still present, first seen, not re-checked
- Coverage and status changes shown next to the counts
- Never count “not re-checked” as fixed
- Regressions first in the client narrative