Nick QuirkYou run a crawl on a new client's site. Screaming Frog returns 42,000 URLs and 11,400 flagged issues across 38 issue types. Ahrefs gives the site a "Health Score" of 61. The client sees the number, panics, and asks what you're going to do about all of it.
The honest answer: most of it, nothing. The skill isn't finding issues — tools do that in 20 minutes. The skill is knowing which 6 fixes out of 11,400 actually change organic revenue, and being able to defend that ranking to a client and a dev team.
Here's the system we've seen work across agency teams.
First, understand why everything gets flagged
Audit tools flag deviations from best practice, not causes of lost traffic. Those are different things. A tool has no idea that your client's /tag/ archive isn't meant to rank, that the 2,800 "missing meta description" pages are paginated filter URLs, or that the 340 "H1 missing" warnings come from a React component the crawler couldn't render but Googlebot handles fine.
So before you prioritize anything, strip the noise. In a typical 10,000-issue audit, we'd expect roughly:
- 60–75% to be cosmetic or irrelevant to the pages that earn money
- 15–25% to be real but low-impact (worth batching into a quarterly cleanup)
- 5–10% to be genuinely worth a dev ticket this month
- 1–3% to be urgent — something is actively blocking indexation or revenue
Your job is to find the last two groups fast.
The three-question triage
Before scoring anything, run every issue type through three questions in order. Stop at the first "no."
1. Can Google reach it?
Crawl blocks, robots.txt disallows on CSS/JS, 5xx errors under load, infinite faceted URL spaces eating crawl budget, orphaned money pages. If a page can't be crawled, nothing else about it matters.
2. Can Google render and index it?
Accidental noindex, canonicals pointing to the wrong URL, soft 404s on thin pages, JS-dependent content that doesn't appear in the rendered HTML, hreflang returning the wrong locale. Check the Indexing report in Search Console, not just the crawler — "Crawled – currently not indexed" on 4,000 product pages is a louder signal than any audit score.
3. Does it degrade how the page competes?
Slow LCP on commercial templates, duplicate or competing pages (this is where keyword cannibalization hides), internal link depth of 6+ clicks to category pages, missing structured data on pages eligible for rich results.
Anything that doesn't fail one of those three questions goes in the "maybe later" bucket. Alt text on decorative images, meta descriptions that are 162 characters instead of 155, lowercase H1s — these are hygiene, not priorities.
Score what survives: Impact × Reach × Confidence ÷ Effort
Take your surviving 20–40 issue types and score each 1–5 on four axes.
Impact
If fixed, how much does it change organic performance? A broken canonical sending product pages to the homepage is a 5. Adding a missing og:image is a 1.
Reach — weighted by page value, not URL count
This is where most prioritization goes wrong. Don't count URLs; count sessions or revenue on the affected URLs. Export your crawl, VLOOKUP against GA4 sessions and GSC clicks for the last 90 days, and sum.
Real example: a client audit flagged 4,100 pages with duplicate title tags and 14 product pages with a broken canonical. The 4,100 pages were tag archives producing 190 sessions a month combined. The 14 product pages produced £38,000/month. Raw URL count said fix the titles. Weighted reach said fix the canonicals this afternoon.
Confidence
How sure are you the fix produces the result? Removing a stray noindex from a category page: 5. "Improving" content structure to help E-E-A-T: 2. Low-confidence items should never jump the queue, no matter how exciting.
Effort
Score in dev-days, not vibes. 1 = under an hour. 5 = a sprint with QA and a release window. Be realistic — if the client's dev shop ships every second Thursday, your "quick fix" has a two-week lead time baked in.
Multiply, divide, sort descending. You now have a defensible list where the top item is almost always something like "remove noindex from 220 service pages — 1 hour of dev time" and the bottom is "rewrite 4,100 archive titles."
Group by template, not by URL
The single biggest efficiency gain: stop thinking in URLs and start thinking in templates. One change to a product template can resolve 9,000 flagged URLs at once. One change to a blog template can fix heading hierarchy sitewide.
When you brief dev, collapse your scored list into template-level tickets:
- Ticket 1 (product template): fix self-referencing canonical, add Product schema, lazy-load below-fold images — resolves 9,140 flagged URLs
- Ticket 2 (robots.txt): unblock /assets/js/, disallow /?sort= and /?filter= parameter space — resolves crawl budget waste on ~18,000 URLs
- Ticket 3 (category template): raise internal link depth from 6 clicks to 3 via footer hub links — affects 212 commercial pages
Three tickets. Roughly 28,000 "issues." A dev team can actually act on that, which is the entire point. If you're already running structured phases in your SEO project management, these tickets slot into the technical phase with clear acceptance criteria instead of living in a 40-tab spreadsheet nobody opens.
Sequence by dependency, not just by score
Scores give you priority. Dependencies give you order. Two rules:
- Crawlability before anything measurable. There's no point fixing page speed on pages Google can't fetch. Unblock first, then optimise.
- Consolidation before expansion. If three pages compete for the same query, pick a canonical winner and redirect before you invest in improving any of them. Otherwise you're optimising a page you'll kill in six weeks.
Also factor in measurement windows. Don't ship a canonical overhaul and a site-wide speed change in the same week unless you're prepared to lose attribution. We stagger major template changes 10–14 days apart so GSC data can separate the effects — which matters enormously when you need to prove SEO results to the client at the next QBR.
