The audit comes back with a long list of recommendations, and the client's developer has a few hours a month for SEO. Whatever sits at the top of the list gets done. Everything below it waits for next quarter, if it happens at all. The order you hand over is the work.
Severity is not the same as impact
An audit tool ranks findings by how serious the check is. A page blocked from indexing is critical, a long title is a warning, and a well-built report also scales each finding by how many of the crawled pages it affects. That gives you a list sorted worst first.
What the tool can't know is which pages matter to the business. It hasn't seen the client's analytics, so a missing canonical on a support article and a missing canonical on the page that takes orders look identical to it. Severity tells you how broken something is. Impact is severity multiplied by what the affected pages do for the client, and only you can supply the second half.
One class of finding jumps the queue regardless: anything that stops Google reaching or indexing pages. A robots.txt block, a stray noindex, a sitemap listing the wrong URLs. Fix those before weighing anything else, because nothing else counts until a page is indexed.
Find the traffic at stake with data you already have
Open the client's Google Search Console and look at the Pages report under Performance. It lists every URL with its clicks and impressions. Sort by clicks. The top of that list is where the client's organic traffic lives today, and the pages just below it with high impressions and few clicks are where it could live. If GA4 has conversions set up, its landing page report tells you which of those pages lead to enquiries or orders.
Now take each finding's affected URLs and sort them into three buckets: pages that earn money or rank today, pages that support those (category hubs, the pages that link into them), and everything else. A finding that touches the first bucket has traffic at stake. A finding that only touches the third bucket can be critical on paper and still wait.
Reach matters too. A problem in a template affects every page built from it; a problem on one page affects one. The report tells you how many crawled pages each finding covers. Use that as a multiplier rather than the whole answer, because reach across pages nobody visits is still no traffic at stake.
Estimate effort by who has to do it
Effort is a question of who, more than of hours. Some fixes you can make in the CMS yourself: titles, meta descriptions, a heading, an internal link, thin copy. Some need a developer to change a template: canonical tags, structured data, redirects, a navigation change. Some need a platform decision: moving to HTTPS properly, restructuring URLs, replacing a theme that renders content only in JavaScript.
Template fixes are the best value on most lists. One change to the product template corrects the canonical on every product page, which is high reach for a single ticket. Page-by-page fixes across a whole catalogue are the opposite: small each, enormous in total.
Be honest about the client's side of effort too. A fix that needs their copywriter, their legal sign-off or their developer's next sprint has a lead time you don't control, and the brief should say so.
Put it on a grid and hand over the top of it
Score each finding high, medium or low on impact and again on effort. Words are fine here; a number would suggest a precision you don't have. Then:
- High impact, low effort goes first. Do these in the first week, most of them yourself.
- High impact, high effort goes to the developer as scheduled work, with a date.
- Low impact, low effort gets batched and done when there's slack, or handed to the client's team as a checklist.
- Low impact, high effort gets written down and declined, with the reason. A client who sees you say no to work trusts the work you say yes to.
An example, fictional: a store selling trail shoes. The audit finds filtered category URLs with no canonical (a template fix that touches the category pages bringing most of the clicks: high impact, low effort, first), product titles all ending in the same long brand string (template fix, high reach, medium impact, second), thin blog posts from years ago (low impact, high effort to rewrite, declined for now), no llms.txt file (low effort, impact uncertain, batched), and mixed content on one old landing page nobody visits (low on both, batched).
The developer brief for each item at the top is four lines: the affected URL or template, what's wrong in one sentence, what to change, and how you'll verify it. Then re-run the audit after the fix ships. A report that compares against the previous run shows whether the finding actually cleared, which is the only proof that the developer's ticket is done.
When the developer pushes back
Developers push back on SEO tickets for two reasons: the ticket is vague, or the list is long enough to look like a reorganisation of their quarter. The four-line brief fixes the first. Handing over only the top of the grid fixes the second.
Bring the affected URLs and the verification. A developer who can open the URL, see the missing canonical and see how you'll check it afterwards has nothing to argue with. Agree the top few items rather than the whole list, and keep the rest for the next conversation, after the first fixes have cleared in a re-audit and the client has seen the movement.
What to take away
- An audit ranks findings by severity and reach; impact adds what the affected pages do for the business, and only you can add it.
- Crawl and index blockers jump the queue, because nothing else counts until a page is indexed.
- Effort is about who has to make the change, and a single template fix usually beats page-by-page edits across a catalogue.
- Hand the developer the top of the grid with a URL, a one-sentence problem, a change and a verification step, then re-audit to prove it landed.
Next
The ranked list still has to be explained to someone who doesn't know what a canonical is. Presenting findings without jargon covers the sentence that does it.