I’ve read audits with excellent analysis inside them that changed nothing, and audits with fairly ordinary analysis that produced six months of engineering work. The difference was never the quality of the finding. It was the format it arrived in.
That’s uncomfortable for anyone who takes the analysis seriously, but it’s true anyway. The deliverable is the product, and everything upstream of it is raw material. Gartner is blunter about this than most writing on audits. A 2022 survey of 377 marketing analytics users found analytics influencing just over half of marketing decisions, and a third of respondents said decision makers cherry-pick the data that supports a conclusion they’d already reached. Better analysis doesn’t fix that. Better packaging sometimes does.
Why the audit workbook is where findings go to die
The default enterprise SEO audit is a workbook. One row per issue, columns for URL, issue type, severity and recommendation, several hundred rows, a tab per category. It’s quick to produce, it looks comprehensive, and it’s close to unusable in practice.
It fails for structural reasons. Severity gets assigned by the auditor with no reference to what the affected pages earn. There’s no owner, so every row belongs to nobody. Recommendations describe a desired end state rather than work, so an engineer reading row 94 can’t tell what to build, what to test, or when it’s done. And the ratio of rows to decisions is wrong: 200 findings won’t become 200 tickets, so the document quietly delegates prioritization to the busiest person in the room.
The workbook still has a place. It’s the appendix. It shouldn’t be the deliverable.
Write an executive summary that holds up without you in the room
Assume the first page gets read alone, on a phone, three weeks after delivery, by somebody who wasn’t at the kick-off. That isn’t cynicism, it’s how budget decisions travel inside a large organization.
The one-sentence statement of what’s wrong, in business terms, with no jargon that needs a glossary. Something like “roughly two fifths of the product catalogue isn’t eligible to rank, because of the way filter URLs get canonicalized”. Google’s page indexing report gives you the vocabulary to check it, since “duplicate without user-selected canonical” means Google chose a different URL as the canonical for the page in question.
The size of the problem. Which templates, how many URLs, what those templates earned over the last twelve months, and the plausible range of change. Give a range and name the assumption behind it rather than one confident number. Google warns buyers away from anyone guaranteeing a ranking, and a single-point forecast in an audit is the same promise in a nicer font.
The three to five things you’d do first, each with an owner function (engineering, content or product) and an effort estimate in engineer-days.
What happens if nothing gets done, written as the honest counterfactual rather than a threat, and including “nothing much” where that’s the truth.
One line on what you didn’t look at, so nobody discovers in month four that the help centre was never in scope.
One page. If it runs to three, the parts after page one are appendix material that has migrated forward.
Write each SEO audit finding as an engineering ticket
The central move is writing each finding in the shape your engineering team already works in. Not “canonical tags on paginated category pages point to page one, which is incorrect”, but a ticket somebody can estimate, build and close.
Title in the imperative. “Serve self-referencing canonicals on paginated category URLs”, so your backlog reads as work rather than as complaint.
Context in two sentences. What the current behaviour does, what it costs, and the affected template named outright.
Scope. The exact templates and URL patterns, three example URLs, and an explicit line on what you’ve left out.
Acceptance criteria a QA engineer can verify knowing nothing about SEO. Every URL matching /category/*?page=N returns a rel=canonical pointing at itself, checked in rendered HTML rather than raw source. Performance tickets get the same treatment, because the Core Web Vitals thresholds already read as pass conditions: LCP at or under 2.5 seconds, INP at or under 200 milliseconds, CLS at or under 0.1, measured at the 75th percentile of page loads.
Effort and dependencies. Which team owns the template, whether the fix needs a release or ships behind a flag, and what it blocks.
How you’ll measure it after release, naming the report and the date you’ll open it. Leave room for crawl latency when you choose that date. Google’s guidance on removing pages notes that it may take months for Googlebot to revisit a page, so a verification date a couple weeks out tells you very little on a large estate (the recrawl hasn’t happened yet).
Writing a finding this way takes longer than filling a spreadsheet row, and that’s the cost. I’d rather deliver twelve findings that ship than eighty that don’t, and where an engagement will only pay for eighty rows, say so out loud instead of pretending eighty rows are a plan.
A prioritization model needs revenue numbers and engineer days
High, medium and low aren’t a model. They’re the auditor’s intuition in formal clothes, and the moment a product manager pushes back on one of them there’s nothing underneath to defend.
Score every finding on estimated annual revenue impact divided by engineering effort in days. Revenue impact comes from the per-template baseline: what these pages earn now, how many of them the finding touches, and a plausible percentage change with the reasoning written beside it. Effort comes from an engineer who has read the ticket, not from you.
The format of the deliverable decides what ships. The analysis only decides whether what shipped was worth building.
Label the impact figures as estimates, with the assumption in the cell, because an audit presenting modelled numbers as measurements loses the room the first time somebody checks one. And effort estimates drift, so re-score after the first sprint rather than defending your original ranking.
The handover is part of the SEO audit deliverable
A report you email is a report that’s finished. A report you walk through, ticket by ticket, with the engineering lead and the product owner both in the room, becomes a backlog.
Practically, this means loading the top findings into the client’s own tracker rather than your document, in their ticket format (their fields, their labels, their sprint naming), tagged to their next planning cycle. Present to engineering and product together, because the fastest way to kill a fix is for product to hear about it after engineering has already estimated it. Then turn up to the first planning session where the tickets come up, and expect to renegotiate. A good share of the value you add lands in the conversation where an engineer explains why the cheap version gets most of the benefit.
Then stay for the release. Post-launch verification belongs to whoever wrote the acceptance criteria.
How to test whether your audit format is working
Take the last audit your organization commissioned and count how many findings shipped. If the honest answer is a handful, the analysis very probably wasn’t the problem, and a second audit in the same format buys the same outcome at the same price.
Then rewrite three of those findings as tickets with acceptance criteria, put them in front of an engineer, and see whether they get estimated. That’s a cheaper test of the format argument than another engagement. If you want the whole thing delivered this way, that’s how my audits work, and the implementation that follows is technical SEO work on the same tickets.