Lead with the business finding
A report should begin with a meaningful observation, such as inaccurate integration information or weak coverage of an important buyer task. Avoid opening with a proprietary score that requires several pages of explanation. State the scope in the first paragraph: product, audience, surfaces, language, dates, and method. Identify whether results come from your own prompt sample or a platform's aggregate report. These sources can complement each other, but they should not be presented as interchangeable. Readers need to know which conclusions they can verify from individual answers and which are aggregated.
Attach an evidence record
For each consequential finding, save the exact prompt, response, visible citations, collection time, and relevant context. Include the raw text when permitted and a screenshot when presentation matters. Give records stable identifiers so a reviewer can move from a claim in the report to its supporting observation. Avoid storing unnecessary personal information from customer examples or logged-in contexts. A compact evidence table is often enough: observation ID, finding, source URL, classification, confidence, and proposed action. Separate the raw output from the analyst's interpretation to prevent later confusion.
Show denominators and exclusions
Percentages need counts. State how many requests were attempted, how many were valid, and how many were excluded for collection errors. Explain whether a citation metric counts answers, URLs, or occurrences. Hypothetical example: a report finds six product mentions among 24 valid answers after four requests failed. The mention rate is 25% of valid answers. Displaying six out of 28 would turn infrastructure problems into apparent product absence. Include the four failures in a collection-quality note so the reader still sees that the sample was incomplete.
Distinguish evidence from explanation
An answer can prove that a statement appeared in the observed response. It cannot prove why the system chose that statement. Label causal explanations as hypotheses unless supported by an appropriate study. Bing explicitly presents citation activity as observational; apply the same discipline to your own report. If a page edit precedes a citation increase, record both facts without claiming that the edit caused the change. Offer alternative explanations when material, such as changed prompts, different sources, product updates, or an adjustment to the collection method.
Finish with reviewable actions
Assign each recommended action an owner, expected output, and review date. Examples include correcting a pricing page, adding missing integration limitations, or investigating blocked documentation. State what successful implementation looks like separately from any hoped-for visibility effect. Keep a short limitations box covering sample selection, variance, missing contexts, and attribution. Archive the report and methodology together so future comparisons do not depend on memory. A useful report does more than display a problem: it gives someone enough evidence to make a justified change and enough context to assess that change later. Include a named reviewer and review date for each material factual finding before sharing it beyond the team.
Build reports with inspectable answers, clear denominators, and decisions tied to evidence.
Sources & further reading
Official documentation informs this guide. Examples are illustrative, and product interfaces or limits can change.
From search signals to a useful first draft.
SERP.so is in development. Join the waitlist for a workspace that connects research, content review, and publishing.
Join early access ↗