A founder reads your monthly report, gets to "canonicalisation issues on parameterised URLs", and skims the rest. A few months later they cancel, and the reason they give is that they weren't sure what they were getting. The fixes were real. The account was lost in translation, and translation is a skill you can practise.
Why the plain sentence keeps the account
A client keeps paying for work they can explain. When the founder's co-founder asks what the agency did this month, the answer has to survive a sentence. "They fixed the thing where Google was seeing two copies of every product page" survives. "They addressed canonicalisation" doesn't, and the founder knows it doesn't, which is why they stop asking questions, then stop reading reports, then stop renewing.
Jargon also moves the risk to the wrong place. If the client doesn't understand a finding, they can't tell you how much the affected pages matter to them, and you end up prioritising blind. The plain sentence is how you get the business context back.
The sentence has three parts
Every finding can be said in one sentence with three parts: what's wrong, in terms of what a searcher or Google sees; what it does to the client; and what you'll do about it.
Take the canonical problem, because most founders have never heard of it. A canonical tag is the line in a page's code that names the page's official address, so that when the same page exists at several URLs Google knows which one to count. Said to a founder: "Your product pages exist at two addresses each, one with a filter in the URL and one without, and nothing tells Google which is the real one, so it splits the page's credit between them; we'll add a line to the product template that names the real address." One sentence. They can repeat it.
The same shape works for everything. A stray noindex: "One line of code on your pricing page tells Google not to list it, so it can't appear in results however good it is; we'll remove the line and ask Google to re-check the page." Duplicate titles: "All your service pages show the same headline in Google's results, so searchers can't tell which one to click; we'll write one that names each service." A slow page: "Your category pages load slowly enough that Google's Core Web Vitals measurements rate them as poor, and page experience is one of the things Google says it weighs; we'll compress the hero images and defer the scripts that aren't needed on first view."
Two words to avoid entirely. Never say "penalty" for duplicate content: Google's own documentation on consolidating duplicate URLs describes picking one version, not punishing the site, and a founder who hears "penalty" will panic and then distrust you when nothing was penalised. And never say "error" for a warning; say what it is.
Show it before you describe it
A founder believes what they can see. Open the affected page in a browser, view the source, and point at the line. For a canonical, a checker's output with the canonical URL next to the page's actual URL makes the mismatch obvious without any explanation. For a title problem, show the search result as Google would display it. For a noindex, the line is right there in the head of the page.
Use one analogy per finding at most, and only one that survives a follow-up question. "A canonical is the page's registered address when it trades from several" holds up. "It's like a signpost" invites "a signpost to what?", and you're back in the jargon.
Write the report so the founder can forward it
Page one is the findings in order of impact (the previous lesson covers the ranking), each as its three-part sentence. Put the technical word in brackets after the plain version the first time, so the founder learns it rather than being excluded by it: "the page's official address (its canonical tag)". The developer's detail, meaning affected URLs, what to change and how it will be verified, goes in an appendix or a separate ticket.
Say what the report didn't cover. An audit checks the pages it crawled, and a report that doesn't measure backlinks should say off-page wasn't assessed. Founders forward honest reports; they file the ones that seem to claim too much.
Then decide what the founder receives. A PDF is true on the day you print it, which suits a monthly review. A live link shows whatever the latest report says, which suits "what's the state of things". Send the PDF for the record and the link for the current truth, and say which is which.
The questions a founder asks next
"Is this why our traffic dropped?" Say yes only when the timing and the affected pages match; otherwise say it's one of several candidates and name the one you'd check first. "How long until it's fixed?" Give the date the change ships, and explain that Google re-crawls on its own schedule, which it doesn't publish, so the proof is the re-audit and the Search Console data after it. "Did the last agency miss this?" Describe what you found and when it appears to have started, and leave the verdict to them.
Each answer is honest and specific. That combination is what a founder remembers at renewal, long after they've forgotten what a canonical is.
What to take away
- A client keeps paying for work they can explain to someone else, so every finding needs a sentence they can repeat.
- The sentence has three parts: what's wrong as Google sees it, what it does to the client, and what you'll do.
- Show the evidence live before describing it, use one analogy at most, and never say "penalty" for duplicates, because Google's own documentation describes consolidation rather than punishment.
- Put plain findings on page one, technical detail in an appendix, and state what the audit didn't measure.
Next
With the audit sold, prioritised and explained, the next chapter turns to strategy: Keyword strategy per client builds a repeatable path from a client's offerings to a keyword map.