Every audit tool, ours included, greets you the same way: a number. 247 issues found. Then a list, sorted by a severity label the tool assigned without knowing anything about your business. The implied instruction is to start at the top and work down until the number reaches zero.
That instruction is wrong, and it is the reason technical SEO backlogs never close. This post is about the sort order nobody teaches — and why, once you use it, an hour is genuinely enough.
The number is not what you think it is
An audit issue count is not a count of problems. It is a count of *pages exhibiting a symptom*. Those are radically different things.
A single missing `<title>` in one Next.js layout file produces "missing title tag" on 340 pages. Your audit says 340 issues. Your codebase has one bug. One edit, one deploy, 340 issues gone. Meanwhile "fix broken outbound link" appears once, is genuinely one issue, and takes you the same five minutes as the fix that cleared 340.
Severity sorting treats those two as comparable because both are "medium". They are not comparable. They differ by a factor of 340 in return on the same five minutes.
Issues are not independent — they form a dependency graph
The second thing severity sorting hides: issues cause other issues. They sit in a graph, not a list.
Consider a paginated category listing where page 2 onward carries a canonical tag pointing back to page 1. That single directive generates, downstream:
- "Duplicate title tag" on every paginated page (they all resolve to page 1's title).
- "Duplicate meta description" on the same set.
- "Orphaned page" warnings, because your crawler now treats the canonicalised pages as non-indexable and stops counting internal links to them.
- "Thin content" flags, because the canonicalised pages are being evaluated as duplicates of a page they are not duplicates of.
- "Crawl budget waste" on the whole directory.
Five issue types, potentially hundreds of rows, one cause. Fix the canonical strategy and every one of them clears in the next crawl. But if you sort by severity, "duplicate title tag" is sitting at the top with 180 rows and "incorrect canonical on paginated set" is buried at row 60 marked *low*, because to a crawler a canonical tag is a suggestion and suggestions are rarely critical.
You would spend your hour hand-writing 180 unique titles for pages that should not be indexed at all.
The counterintuitive part: fixing things makes the number go up
This is the insight that reframes the entire exercise, and almost nobody says it out loud.
Some issues are masks. A `noindex` on a template, a `Disallow` in robots.txt, a canonical pointing elsewhere — these tell the auditor "do not evaluate this page properly", so the auditor does not. Those pages sit quietly with one issue each.
Remove the mask and those pages get fully evaluated for the first time. Now each one reports its missing title, its thin content, its broken image, its slow LCP. Your 247 becomes 380.
You did not break anything. You *un-hid* 133 pre-existing problems on pages that were previously invisible to search engines and are now eligible to rank. The number went up because your site got more honest.
The sort order that actually works: blast radius first
Replace severity with three tiers, ordered by how many other things the fix resolves.
Tier 0 — Directive-level (the masks)
Anything that controls whether a page is evaluated at all: `robots.txt` rules, `noindex`, canonical tags, `hreflang` clusters, redirect chains, and status codes. These are first not because they are severe but because every downstream fix is unverifiable until they are correct. Fix a title on a `noindex` page and you have accomplished nothing measurable.
Expect the issue count to rise here. That is the tier working.
Tier 1 — Template-level (the multipliers)
Anything where one file controls N pages: layout components, schema blocks, breadcrumb logic, image handling, the pagination pattern, internal-link modules. This is where the "200 issues in an hour" claim is actually earned. One pull request, hundreds of rows cleared.
The tell for a template issue is round-ish, repeating counts. If you see 340 pages with the exact same symptom and they share a URL pattern, that is not 340 problems. That is one component.
Tier 2 — Page-level (the genuine singletons)
The residue: a specific broken link, one over-long title on the About page, a single missing alt attribute. These are real, they are cheap, and they are last — because they are the only tier where effort scales linearly with count. This is the tier that never finishes, and that is fine. It is supposed to be a backlog.
Weighting by reach: severity without traffic is fiction
One more multiplier before you touch anything. A "critical" issue on a page nobody visits, nobody links to, and Google rarely crawls is worth less than a "low" issue on your highest-converting page.
Severity is a property of the *issue*. Impact is a property of the *issue on your site*. The conversion is:
Impact = Severity × Reach × 1 / Effort
Severity – what the tool told you (the only part most people use)
Reach – impressions, clicks, internal links in, or crawl frequency
for the affected URLs, from Search Console
Effort – 1 file, or 340 hand edits?Reach is the term everyone omits, and it is the one that changes the answer most. Join your audit export to your Search Console page-level impressions on URL. The rows where high severity meets high impressions are your actual first hour. The rows where high severity meets zero impressions across 90 days deserve a different question entirely — not "how do I fix this?" but "why does this page exist?"
The hour, minute by minute
Concretely, with an audit export and Search Console access:
| Time | What you do | Why |
|---|---|---|
| 0–10 min | Group every issue by URL pattern and by template. Do not read individual rows. | Turns 247 rows into ~15 candidate causes. |
| 10–15 min | Join to Search Console impressions on URL. Drop clusters with no impressions and no strategic intent into a "prune?" pile. | Adds the Reach term. Usually removes a third of the work. |
| 15–25 min | Fix Tier 0 directives. Re-run the crawl immediately and let it work while you continue. | Unmasks the truth. The count will rise. |
| 25–50 min | Fix the top three Tier 1 template causes. One PR each, small and reviewable. | This is where the hundreds fall. |
| 50–60 min | Read the re-crawl. Confirm the Tier 0 fixes landed and see what was unmasked. | Verification, not vibes. |
| Backlog | Tier 2 singletons, ranked by the Impact formula. | Linear effort, so it never goes first. |
Notice what is not in the hour: writing content, hand-editing meta tags, or arguing about severity labels. The hour is spent on clustering, one join, and three pull requests.
What "one-click fix" should and should not mean
Plenty of tools, ours among them, offer to apply fixes for you. Worth being precise about where that is legitimate.
Automated fixing is safe when the correct output is derivable without judgement: adding a missing canonical that points to the page itself, compressing an oversized image, collapsing a redirect chain to a single hop, adding `width` and `height` to an `<img>` to stop layout shift. There is one right answer and a machine can compute it.
Automated fixing is dangerous the moment the correct output requires knowing what the page is *for*. A generated title tag is a guess about your positioning. A generated meta description is a guess about your offer. An auto-`noindex` on "thin" pages is a guess that can silently deindex a legitimate section. These need a human, and any tool that pretends otherwise is optimising your metric, not your business.
Verify, or you did not fix it
An issue is closed when a fresh crawl says it is closed — not when the PR merged. Three specific traps between merge and reality:
- Cache. Your CDN may serve the old HTML for hours. The crawler sees the old page. Purge, then crawl.
- Render. If the fix lives in client-side JavaScript, the raw HTML may still be wrong. Check the rendered DOM, not the source — this is the single most common false "fixed".
- Staging drift. The fix works locally and did not ship, because the template lives in a package that was not rebuilt. Crawl production, always.
Then give it time. Fixing the page is instant; Google re-crawling, re-rendering and re-evaluating is not. Directive changes on important URLs can move within days. Template changes across a large site can take weeks to propagate fully, because crawl budget is allocated per-URL and your long tail is not a priority for anyone but you. Submitting the changed URLs — via sitemap and, for participating engines, IndexNow — shortens the front half of that wait.
The actual lesson
The reason "200 issues" feels impossible is that the tool presented a symptom list and called it a task list. Once you see the list as evidence pointing at a handful of causes, the arithmetic changes completely: you are not doing 200 things in an hour, you are doing about six, and the 200 are downstream of them.
So the discipline is simple and slightly boring. Cluster before you fix. Weight by reach. Unmask first and accept that the number gets worse before it gets better. Automate the mechanical, never the editorial. Verify on production, in the rendered DOM.
The number was never the point. The six causes were.
You can run this triage on your own site with the SEO audit tool — it groups by template and joins to Search Console reach by default, because sorting by severity was never going to work.