Build a search report that leads to a decision

A search report is useful when somebody can make a decision from it. A collection of charts can be accurate and still leave a team unsure what to do next. The missing piece is often a small decision record: what changed, what might explain it, what action is proposed and how the team will review the result. This guide turns those parts into a practical monthly workflow.

The intended reader is a founder, agency account manager or search practitioner responsible for assigning work. Start with one business question rather than every available metric. The question could concern a group of service pages, a recently released category or a recurring reporting problem. A focused report can still link to detailed evidence for the people who need it.

Name the decision before opening the dashboard

Write one sentence describing the choice the report must support. For example, a fictional service business may need to decide which of three location pages deserves a content review this month. That is more useful than “review search performance,” which has no clear ending. The decision identifies the relevant pages, the responsible people and the amount of evidence required.

Agree on the available capacity. If the team can complete one substantial page revision, a report that recommends twenty equal priorities is avoiding the decision. Record the constraint and use it to compare options. A shorter work queue can make the reasoning clearer because each proposed item must justify its place.

Establish a reliable evidence window

Use complete, comparable periods and state the filters. Save the property, page group, device and query cohort when those matter. Check for unavailable or incomplete data before calculating a change. A connection failure should become a data-quality note with an owner, rather than a dramatic performance narrative based on a zero.

Google's Search Console guidance describes a tool for monitoring and investigating a site's search presence. Use it to answer the agreed question, with a record of the view you used. Other data sources can contribute when their definitions and scope are equally clear.

Write observations without explanations attached

An observation describes the evidence. “The selected page group received fewer recorded clicks in the comparison period” is an observation if the saved data supports it. “The redesign damaged search performance” is an explanation that requires more investigation. Keep those sentences separate so the team can accept the evidence while questioning the proposed cause.

For each observation, include a comparison and a limit. Which pages changed? Was the period complete? Did the query mix change? Does a small absolute count make a percentage look large? This does not require a long disclaimer. It requires enough context for a reader to understand the scale of the issue and the strength of the evidence.

Create a short hypothesis list

A hypothesis is a possible explanation, with a way to investigate it. A page revision, a tracking change, a change in query mix or a technical problem may each deserve consideration. List only explanations that are relevant to the observed pattern. A long catalog of everything that can affect search rarely helps a busy team decide what to inspect first.

Assign a next check to each live hypothesis. If a release is suspected, compare the affected group with an appropriate unaffected group where possible and review the implementation. If measurement is suspected, inspect the configuration and raw evidence. Record what would weaken the hypothesis as well as what would support it.

Work an example from evidence to action

Imagine three fictional service pages. One has an inaccurate opening-hours description, one has a sudden data gap and one has stable measurements but unclear service information. The report should not rank those issues only by a blended visibility score. Each has a different evidence path and a different owner.

The opening-hours issue can go directly to the person who verifies operational facts. The data gap goes to the analyst responsible for the connection. The unclear service page may need a content review with the business lead. Search metrics can inform the last task, but the direct evidence of unclear information already gives the team a useful starting point.

The decision record might therefore prioritize the factual correction immediately, fix the measurement gap before further analysis and schedule the service-page review within the month's available capacity. It should say who agreed to each action and when the work will be checked. That is a report with an operating consequence, even before the next period of data arrives.

Give every action a completion condition

“Improve the page” is too vague to close. A better task identifies the information to verify, the change to make and the review required. For example: confirm service availability with the operations lead, update the relevant passage and ask a second person to check the published version. Completion can then be observed directly.

Separate implementation completion from later performance review. Publishing an edit proves the edit was published. It does not prove the edit caused a future change in search activity. Schedule the later review with the same measurement protocol, keeping other changes visible in the annotation log. This helps the team learn without claiming more than the evidence shows.

Keep a small decision ledger

A monthly ledger can contain the question, evidence link, observation, hypothesis, action, owner, due date and review date. Add a status that distinguishes waiting for evidence from waiting for implementation. Retain the original decision when new information arrives, then add a dated note explaining how the plan changed. The history becomes useful when similar issues recur.

The ledger should fit the team's existing work system. A simple shared record may be enough for a small agency; a larger team may connect it to its issue tracker. The important property is traceability. A colleague should be able to move from an assigned task back to the evidence and understand why that task was chosen.

End the meeting with a read-back

Ask the action owners to summarize the decision in their own words. Check that the task, deadline and review condition match what the report intended. If the team cannot explain the next step simply, revise the record before ending the meeting. This is a practical quality check for the report itself.

Use Google's Search Essentials as a reference when reviewing the basic requirements and practices relevant to a site's search work. Keep the report centered on observed issues and the team's actual ability to address them. The next step is to create a one-page decision record for the coming month, choose one question and give the resulting work a clear owner.