serpWrite the baseline specification
A baseline is a documented starting measurement, not a promise of causality. Define the product, prompt set, surfaces, language, location, and collection period before publishing changes. State which outcomes matter and how each is counted. Keep the specification short enough that another teammate can follow it. Avoid changing the prompt mix after seeing weak initial results. A baseline selected to flatter the business is less useful than an honest one that reveals gaps. Save the specification with a version number and a fixed list of question identifiers.
Preserve the content state
Record the pages that exist, their important claims, and the dates of major revisions. You do not need a full website archive to preserve useful context; a controlled record of the pages involved in the experiment can be enough. Save relevant titles, URLs, canonical destinations, and the specific sections you plan to change. Note any concurrent pricing, branding, or integration changes. Later visibility differences may coincide with these updates, so a change log prevents the team from attributing everything to the article that received the most attention internally.
Collect valid observations
Run the agreed questions and store complete outputs and visible sources. Use the same classification rules you intend to apply later. Keep errors and missing results separate. Hypothetical example: a team plans to improve its migration guide and records 20 valid answers about related buyer tasks. The business appears in four and its guide is cited in two. Those counts provide a starting point for that defined sample. They do not establish a universal ranking, and the team should not multiply them by an estimated market size to manufacture an audience figure.
Add independent context
Export relevant platform reports and landing-page analytics for the same period where available. Bing's AI report offers a citation perspective; Google's AI-feature data sits within Web performance reporting. Preserve the original metrics and labels. Avoid implying that matching date ranges make these datasets share a denominator. Their value is triangulation: one may show page-level citation patterns, another observable visits, and your own sample the actual answer wording. A clear baseline can place these views side by side without pretending they form a complete funnel from every answer to every conversion.
Plan the next comparison
Specify what will remain stable, which pages will change, and when another review is practical. Use comparable periods and annotate collection changes. If the product or measurement method changes substantially, begin a new series instead of hiding the break. Report both counts and percentages, with examples of meaningful differences. The baseline's main benefit is accountability: the team knows what it observed before acting and can distinguish a verified implementation from a speculative performance explanation. Keep the original files intact so the starting point cannot drift as the narrative around the project evolves. Store the baseline in a read-only export alongside the editable analysis.
Capture a usable starting point before content changes so later comparisons have clear scope.
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 ↗