Trust signals are pieces of proof placed where a visitor is deciding: named clients, reviews, certifications, a matching address, a company number, or a face and role. They work when they are specific and sit next to the claim they support. They fail as a decorative strip of unnamed logos at the bottom of an unclear page.
How those facts are marked up for search is local business structured data. This guide is the design of proof on the page.
Types of signal, and where they belong
Different claims need different proof:
- Identity: registered name and number, a real address, a photograph of a place you occupy. The footer is the usual home; repeat the address on Contact.
- Competence: a named project, an industry, a before/after constraint. These belong on the service page beside the offer, and as a short set on the homepage.
- Social proof: a review with a name, role, and company you can defend. A five-star graphic with no source is decoration.
- Authority: partner badges and certifications the visitor can check. Show the ones that apply to this offer, not every logo from a conference bag.
- Safety: payment marks on checkout, HTTPS in the browser (you do not need to announce the padlock), a privacy link next to a form.
Place the signal at the moment of doubt. A hosting badge next to “we host in Malaysia” helps. The same badge in a footer logo wall, far from any claim, does not.
Do not invent metrics. A precise “98.7% satisfaction” with no method is less trusted than two named outcomes.
Specificity beats volume
Three named clients in the industries you sell to outperform twelve grey logos a visitor cannot read. If a client cannot be named, describe the industry and the constraint (“Johor manufacturer, bilingual catalogue, 2025”) instead of a mystery mark.
Reviews should be attributable. “Sarah C., KL” on a B2B software page looks generic. “Procurement lead, regional distributor” plus a sentence about handover is usable even if the company name is withheld.
Photos of real staff and premises help when they are current. A stock handshake does not.
Placing proof next to a decision
- List the claims a first-time visitor must believe
- Attach one specific proof item to each claim
- Put that proof in the same section as the claim
- Match name, address, and number across the site
- Drop logos and scores you cannot explain if asked
Consistency and retrieval
Search engines and assistants retrieve the entity you publish. If the footer says Jalan X, the contact page says a PO box, and the map pin is a mall directory, the signal conflicts. Use one address format everywhere, including structured data.
Partner status and awards need a year or a programme name when that is how they are granted. “Award-winning” with no source is a slogan.
A practical example
A software homepage shows a “Trusted by industry leaders” row of six unreadable logos and a 4.9 star widget with no reviews visible. The revision keeps two named case notes (industry, city, outcome), the Microsoft partner line with the year, and the Johor office address next to the enquiry action. The star widget is removed until reviews can be opened and read.
Key takeaways
- A trust signal is proof next to a claim, not a logo wall.
- Specific names, roles, and constraints beat volume.
- Identity facts must match across pages and structured data.
- Drop scores and badges you cannot defend.
FAQ
Do we need a testimonial on every page?
No. Put proof on the pages where a decision happens. Repeating the same quote under every heading trains people to skip it.
Are partner logos enough?
They help when the visitor knows the programme and you are allowed to show the mark. They do not replace a project the visitor can understand.
Should reviews be on a third-party site only?
A third-party profile is useful. The website still needs one or two readable examples next to the offer, with a link to the full source if you have one.