Articles ·
How to explain website problems to small-business owners: 7 lessons from building a plain-language checker
We spent the autumn turning technical website checks into reports that a dentist, a shop owner or an NGO director can read in two minutes. Most of what we learned has nothing to do with code — it is about how to talk about problems. Here are seven lessons any agency can use with its own clients.
1. Owners ask one question, not thirteen
Developers think in metrics. Owners ask: “Is my site OK, and what do I fix first?” Every report we write now starts with that answer in one sentence, before any detail. If the first screen of your client report is a table of scores, most owners will never scroll further.
2. A false alarm costs more than a missed issue
Our first versions flagged things that were not real problems: an analytics tag “without consent” when a cookie banner loaded it correctly, an “old” WordPress that had in fact been patched, a redirect we misread. Each false alarm made the owner doubt every other finding. We now exclude any check that we cannot make reliable, and label the rest with what exactly was checked and when. When in doubt, leave it out.
3. Use a traffic light, not a percentage
“72/100” means nothing to an owner, and invites the question “why not 100?”. Green / yellow / red per item, plus one overall letter, is understood instantly. Keep the numbers for the developer’s appendix.
4. Translate every finding into a consequence
“No DMARC record” is meaningless to a client. “Anyone can email your customers an invoice that looks like it came from you” is not. We write every finding as: what it means for customers, how urgent it is, and roughly how long the fix takes. The last part matters — owners fear that “fixing the website” means months and a new budget.
5. Three actions, in order
A report with twelve red items paralyses people. We end with three actions only: this week, this month, next redesign. Everything else goes into an appendix. Clients act on short lists.
6. Say what you did not check
An automated, passive check cannot see inside the server, cannot detect every hack and cannot judge content quality. We say so plainly in every report. Paradoxically, admitting limits made owners trust the rest of the report more — and it protects you when something outside the scope goes wrong later.
7. Fear sells once; trust sells for years
It is tempting to lead with lawsuits, fines and hackers. Some accessibility vendors built whole businesses on that — and in 2025 the US Federal Trade Commission ordered one of them, accessiBe, to pay $1 million over misleading claims. For a small agency, a calm, accurate report is the better long-term asset: clients come back when the next problem appears.
A practical template
- One sentence: overall state of the site and the single most important fix.
- A traffic light per area: speed, security, email, software age, accessibility, search and AI visibility.
- For each red or yellow item: consequence for customers, urgency, rough effort.
- Three actions: this week, this month, next redesign.
- What was not checked, and the date of the check.
Written by Bohdan Khomyn, OLBO web studio, Lviv. These lessons come from building the free OLBO Website Checker and from our own study of 71 clinic websites.