Start with the decision the client needs to make
A useful evidence report answers a specific question: approve a repair, choose an investigation or accept completed work. Put that decision at the top, followed by the observation that supports it. A client should not need to read twenty screenshots before discovering what you need from them.
Keep the opening brief: what was observed, which pages or audience it concerns, why it matters and what happens next. Use ordinary language before technical labels. For example, explain that the intended service page is missing from a navigation menu before referring to internal-link coverage or a crawl finding.
Give every important claim a traceable reference
Assign short evidence identifiers such as E01 and E02. For a page observation, record the URL, inspection time, method and relevant extract. For a performance claim, record the property, date range, search type, filters and grouping. Link each claim to the item that actually supports it, rather than attaching a large undifferentiated export.
Keep a readable summary and a supporting appendix. Share only the necessary fields with the intended recipients; remove account details or unrelated customer information from screenshots before distributing them. An evidence link should open the relevant saved view or permitted file, not require the client to reconstruct an undocumented sequence of filters.
Explain the difference between an observation and a conclusion
Label directly measured facts separately from interpretations and proposed actions. A fall in clicks is an observation. A claim that a particular deployment caused it needs further evidence. State alternative explanations when they would change the decision, and identify the check that can reduce the uncertainty.
Google notes that Search Console data may be aggregated by property or page, with different counting behavior. It also identifies some recent data as preliminary. Show these details near the affected comparison. Do not present mismatched totals as a software defect or preliminary figures as a final result simply because they fit the report narrative.
Illustrative report for an unresolved click decline
Imagine a fictional client whose matched reporting periods show 120 and 90 clicks for the same selected page group. The report states a decrease of 30 clicks, or 25 percent, and links to the saved export as E01. E02 records a navigation change during the second period. These are separate observations, not proof that the change caused the decrease.
The recommendation is to inspect affected pages and query segments before approving a wider rewrite. The client decision is whether to allocate time to that investigation. The report explicitly says that the cause is unresolved and that no recovery estimate has been established. The numbers illustrate report structure; they are not a customer case study.
End with responsibilities and a review point
List the requested decision, responsible person, agreed next step and next review date. Distinguish completed work from proposed work and ongoing measurement. If a repair is already live, reference its acceptance evidence; do not substitute a screenshot of a rising graph for verification of the technical change.
Before sending, ask a colleague to trace the main conclusion back to its evidence without your help. Check dates, arithmetic, filters, file permissions and the language used to describe uncertainty. In your next report, refer to the same evidence identifiers or clearly version replacements so the client can follow what changed without losing the earlier record.