How to Present an SEO Audit to a Client: Evidence and Decisions
Key Takeaways
- Send a concise agenda with scope and the decisions needed; choose the detail level with the client.
- Present observed evidence, your priority judgment and unmeasured business hypotheses separately.
- Give each proposed action an owner, sourced effort estimate, approval state and acceptance check.
- Close with approved, deferred and declined decisions plus a re-check date; avoid ranking or revenue promises.
To present an SEO audit to a client, prepare a meeting in which the client can make decisions about the work. The report remains the evidence record. Your presentation explains what was assessed, what is uncertain and which actions you recommend.
Use the editable blank client report to prepare the action table. The filled illustrative sample shows a bounded assessment; its findings and score are fictional, not customer results.
Prepare the client and implementation owner
Agree the purpose of the meeting: approve repairs, clarify intentional configurations or request missing data. Identify who can approve budget and who can confirm implementation feasibility. Send an agenda and summary in advance; offer the full report when that helps their preparation.
Choose a meeting length that fits the decision count and participants. A short executive discussion and a separate technical review can work better than one long walkthrough, but no fixed thirty-minute format fits every engagement.
Start with scope, then the decision
In a few sentences, state the website, audit date, analyzed boundary and major exclusions. Keep material limitations visible before showing the score. Then summarize the actions you want approved. This prevents a client from interpreting a sampled assessment as a complete inventory.
For the public sample, say: “This fictional assessment analyzed 10 of 12 discovered pages. Two pages were not checked, and the score summarizes only the disclosed Technical and On-Page checks.” Do not say that the website is 81% optimized or that the remaining pages passed.
Separate three kinds of statements
| Statement | Evidence needed | How to present it |
|---|---|---|
| Observation | Captured source or measurement, rule, URL and timestamp | The captured HTML has no non-empty title on this URL |
| Agency recommendation | Observation plus business context and reviewer judgment | We recommend repairing this page before the agreed launch |
| Business hypothesis | Client data and a defined method to assess the hypothesis | We will investigate whether this issue contributes to the observed trend |
Use documentation for technical explanations, not as proof that this client will receive an effect of a particular size. For performance, explain the difference between lab and field data. A single lab run can justify investigation without proving all users had that experience.
Turn findings into reviewable actions
Group findings only when they share the same implementation change. Keep their IDs and URLs so the developer can inspect each observation. Ask the implementation owner to estimate effort and name dependencies before presenting the estimate as a commitment.
The following is a hypothetical meeting table, not a customer project or a MendMySEO audit result. No effort or business outcome is asserted.
| Decision | Evidence to attach | Estimate and owner | Approval and acceptance |
|---|---|---|---|
| Add a document title to the affected page | Missing-title finding with captured HTML and date | Developer estimate pending; owner to be named | Approve after review; verify non-empty title in a comparable check |
| Review the page-template viewport setting | Missing-viewport finding on the assessed URLs | CMS/template owner; scope estimate pending | Confirm intended device behavior and captured viewport presence |
| Investigate the homepage mobile lab result | Lighthouse result, run conditions and timestamp | Performance owner; diagnosis estimate pending | Repeat measurement and agree the repair after investigation |
| Assess the two unchecked pages | Coverage inventory with exclusion reasons | Reviewer to confirm access and supported scope | No passing conclusion until the required evidence is captured |
The sample's six-rule assessment does not validate title length, uniqueness, canonicals or JSON-LD. If a broader project has those findings from another source, attach that source and review them separately. Do not show an illustrative code block as evidence that your current scanner detected or verified the issue.
Handle questions with evidence and ownership
“We already knew about this.” Confirm whether the new evidence changes scope or priority. If it does not, avoid treating a rediscovered issue as new value; agree who owns the existing task.
“Our developer says this is intentional.” Ask whether they dispute the observation, proposed change or priority. Preserve the observation while recording the rationale for accepting, deferring or rejecting the recommendation.
“What return will this produce?” Explain what you can verify: the repair and its agreed technical acceptance checks. Rankings, clicks and revenue need separate measurement and have other drivers. A completed repair is not a causal forecast.
Close with a written decision record
Record each action as approved, deferred or declined, with an owner and reason. Add target dates and a comparable re-check plan for approved work. Retain unresolved and unchecked items in the next report rather than allowing them to disappear from the agenda.
Send the report version discussed in the meeting with the decision record. If the action plan changes, label the revision and preserve audit dates. The white-label delivery workflow explains how to keep hosted and PDF copies consistent.
Frequently Asked Questions
How technical should the presentation be?
Use enough detail to let the approving person understand the action and the implementation owner inspect the evidence. Keep URL lists and source excerpts accessible in the report.
Should I send the report before or after the meeting?
Ask how the client prepares. A short agenda and decision summary in advance help; provide the full report before the meeting when they need technical review time.
What if nothing is approved?
Document the blocker: budget, disputed evidence, implementation capacity or a different priority. Agree a concrete next step and leave the technical status unchanged.
What if the client asks me to implement?
Define a separate implementation scope with permissions, owner, estimate and acceptance checks. Do not treat report delivery as automatic authorization to change the website.
Inspect the report before choosing
Open the complete illustrative client report, download its matching sample PDF, or try the branding preview. These examples use fictional data; they do not crawl your website or demonstrate a customer result. Check current access and pricing before planning client delivery.