A first AI visibility baseline before a product launch

Before a launch changes your product pages, save a record of what you want to compare later. The questions, recorded answers and public facts at that point are your baseline.

A baseline gives the team a reference for questions such as “Did this answer begin describing the new workflow?” It does not prove that the launch caused a later change, and it does not predict how quickly an AI service will reflect new information.

The useful work is to preserve a small, interpretable set of observations before the reference point disappears.

Define the launch event precisely

Write down what is changing and when it becomes public. A homepage rewrite, a feature release and a launch announcement may happen at different times. If the pages change on Monday and the announcement goes out on Wednesday, an answer collected on Tuesday is already after the page change.

Choose the boundary relevant to the question you want to investigate. Record timestamps and time zones rather than relying on a label such as “launch week.”

State what the product truth will be on each side of that boundary. If a capability does not exist before release, an earlier answer saying it is unavailable may be correct. You should not later relabel that answer as an error because the product changed.

Choose what you need to learn

A launch baseline works best with a specific decision behind it. You may want to know whether a provider describes a newly public capability accurately, whether the brand appears for an established use case, or which sources an answer cites before the website changes.

Keep those purposes separate. Questions that name the product test its description. Questions that leave the product unnamed test discovery within the chosen scope.

Use a small reference set that the team can inspect fully. Select questions for their relevance, using the prompt-selection guide if needed. There is no universal number of questions that makes a launch comparison conclusive.

Avoid putting unreleased details into an external provider request unless they are approved for that use. A question containing a new feature name also supplies information that an ordinary discovery question would not. Label that kind of diagnostic test separately.

Freeze the reference questions and known context

Save the exact wording and a version identifier for each question. Record its purpose, intended market and language, plus the provider profile and effective request context that are available to you.

Keep unknown settings marked as unknown. A provider label alone does not establish that its API answers match the consumer application a colleague uses. If you later change the model, search configuration or question wording, record the change rather than treating the new observation as an unchanged test.

You can add exploratory questions after launch. Keep them outside the original reference series until you deliberately create a new version. Replacing weak results with more favorable questions would change what the baseline measures.

The reference set can live in an ordinary worksheet. It does not require an automatic experiment-management feature.

Save the answers, not just the headline percentage

Collect the baseline early enough to inspect it before the relevant public change. Keep each successful answer with its exact question, collection time, provider context and any recorded citations or sources.

Record every planned position, including failed and unavailable responses. A failed request cannot establish that the brand was absent. If you retry before launch, preserve the failed attempt and the retry time. Do not silently merge a post-launch retry into the pre-launch sample.

Review whether the collection actually finished before the launch boundary. A run that starts beforehand but returns some answers afterward may span both states. Mark affected observations and use a clean comparison scope where possible.

One completed collection is an initial observation. If time and available capacity allow additional collections before launch, retain them as separate dated observations so you can see whether the starting answers already vary. Do not delay a launch merely to satisfy an invented monitoring sample requirement.

Preserve the relevant public page state

Answers are only one part of the record. Save the public facts and pages that the team expects to change: the capability description, relevant documentation and any qualification needed to interpret the claim.

For each important page, keep its URL, capture time and a readable copy or an existing versioned record. Where available, record a dated page-health check as separate evidence about what that check observed.

A technical check does not prove that an AI provider read the page. A screenshot does not establish what an earlier provider request received. Likewise, a page opened after launch is not proof of its pre-launch wording. Preserve the actual dated state you have, and describe its limits.

Keep the baseline packet focused on the pages relevant to the launch question. A full website or repository scan is not required to document a specific capability change.

Create one compact launch record

Illustrative example for fictional HarborBookings. The dates and events below demonstrate the method; they are not customer evidence or product results.

The record distinguishes the public change from its later verification and promotion. If another relevant event occurs, such as a documentation correction or an independent review, add it with its actual date.

Give one person responsibility for maintaining this log and another, where practical, responsibility for checking material product claims. The log supports interpretation; it does not claim to capture every external influence on later answers.

Compare later observations on the same terms

At the follow-up, inspect the same question/provider positions and show completion counts. Retain the full collection record even if only a subset is comparable.

Suppose, in a separate fictional example, ten unchanged discovery questions run once through two unchanged provider profiles. All twenty planned answers succeed before and after launch. The target appears in four baseline answers and seven later answers: 4/20 = 20% and 7/20 = 35%.

That is three additional appearances and a rise of fifteen percentage points within this sample. It is not evidence of fifteen percent more customers, increased revenue or a proven launch effect.

Inspect the changed answers. Did they describe the launched capability? Did they cite the updated page, another source or no explicit source? Were the appearances recommendations, passing mentions or cautions? An aggregate increase does not answer those questions.

If the product truth changed, assess each answer against the truth applicable at its collection time. Then ask separately whether later answers reflect the new state.

Use an honest substitute when the baseline is missing

If the launch has already happened, begin with a dated post-launch reference. Existing saved answers may provide earlier evidence, but only for the questions and context they actually preserve.

Do not ask today's provider to recreate its old response and label that output a historical observation. An archived page can establish earlier page content; it cannot reconstruct an answer that was never saved.

In Prerender Buddy, inspect Collection history and the recorded prompt results where AI Visibility is available. Confirm the actual selected collection and its completion dates. Keep the launch log and page-state record alongside that evidence; do not assume they are captured automatically.

Schedule the next comparison around a decision the team will review. With the questions, answers, product facts and launch events preserved, the team can describe what changed in the observed sample and decide what to investigate next.