How do I record a baseline before changing the site?
A useful baseline records the exact prompts, engines, pages and technical conditions that existed before deployment. Without that record, a later answer may reflect a changed question set, an index refresh or a competitor's content rather than your SEO work.
Create a baseline sheet with the following fields:
- The buyer question and its intended category or use case.
- The URL that should answer the question.
- Whether ChatGPT, Perplexity, Gemini, Claude, Grok, Google AI Overviews and Google AI Mode mention the brand.
- The brand's answer position, cited URL and competing brands or pages.
- The date, device context where relevant and technical version being tested.
- Organic impressions, clicks and indexed-page signals from Google Search Console.
Use the same prompt wording after the change. Keep a smaller control group of prompts whose target pages were not edited. The control group helps show whether broad engine changes affected both groups, while the edited group shows where the technical release may have made a difference.
2. Confirm the technical release is live and crawlable
A technical SEO change cannot improve AI visibility until the intended public version is reachable, indexable and internally discoverable. Check the live response rather than relying on a staging screenshot or a deployment message.
Check the changed URLs and their important supporting files for the following:
- The final URL returns the intended content without an unexpected redirect chain.
- The robots directives do not block the page or its important resources.
- The canonical points to the version you want engines to use.
- The page is present in the XML sitemap when it should be.
- Structured data is valid, visible in the rendered page and consistent with the visible facts.
- Internal links lead to the page using descriptive, crawlable links.
- The page renders its important text without depending on a failed script.
Record failures separately from visibility outcomes. A blocked crawler test means the release needs a technical fix, not that the page has poor answer relevance. The AI Search Technical SEO Checklist gives a separate fix order when several of these checks fail at once.
3. Rerun a fixed prompt set across all seven engines
A fixed prompt set makes the before-and-after comparison meaningful across ChatGPT, Perplexity, Gemini, Claude, Grok, Google AI Overviews and Google AI Mode. Run the same prompts with the same brand description and record the full answer, not just whether the brand appeared.
For each run, capture the following:
- Whether the engine answered, refused, or returned an insufficient result.
- Whether the brand was named and where it appeared in the answer.
- Which page or pages were cited.
- Whether the changed URL was used, ignored or replaced by another page.
- Which competitors appeared and whether their pages filled the same role.
- Any factual change that could affect the answer independently of the technical release.
A single answer is not a durable result because generated responses can vary. Repeat the run under the same method, keep the prompt wording fixed, and label observations by date. Cituna measures these outcomes by asking the seven engines the questions a brand's buyers ask and recording names, citations, positions, competitors and replacement pages.
4. Separate mention, citation and position into different measures
AI visibility is not one score, so measure brand mention, citation, answer position and page choice separately. A brand can be named without a citation, cited without being recommended, or move from a weak mention to a prominent answer position without gaining clicks.
Use a result record that distinguishes these outcomes:
- Mention rate shows how often an engine names the brand.
- Citation rate shows how often an engine links to or cites a brand page.
- Position shows where the brand appears in the answer relative to competitors.
- Target-page usage shows whether the technical change helped the intended URL appear.
- Competitor replacement shows whether another site still supplies the answer.
- Answer accuracy shows whether the engine used the page for the right claim.
Treat a citation to the wrong page as a partial result rather than a success. For example, if a product page becomes cited for a technical comparison but the documentation page remains absent, the site may need clearer page purpose or links even though citation count increased.
5. Connect answer changes to search and page signals
Google Search Console helps test whether an AI visibility change coincided with changes in conventional search demand, but it does not prove that an assistant used a page. Compare clicks, impressions, queries and page-level performance for the changed URLs with the same baseline period and control pages.
Separate the evidence into three layers:
- Technical evidence confirms that the intended page and markup were available.
- Answer evidence shows whether engines named, cited or positioned the brand differently.
- Search evidence shows whether Google impressions and clicks changed for the relevant pages.
A rise in clicks with no answer change may indicate ordinary search improvement. A rise in citations with no clicks may still matter for assisted discovery, but it should not be reported as direct traffic. Cituna includes Google Search Console so teams can view which tracked changes moved clicks alongside answer visibility, rather than treating one signal as proof of all the others.
6. Choose measurement depth based on the decision
The right measurement method depends on whether the team needs a quick release check, a defensible before-and-after comparison or an ongoing operating system. A manual spreadsheet is suitable for a small set of prompts and one release, while a repeatable platform is more practical when every engine and every release must be tracked.
Use this decision rule:
- Choose a manual check when the change affects a few URLs and the decision is simply whether to roll back or continue.
- Choose a scripted or scheduled run when prompt wording, engine coverage and timestamps must stay consistent across releases.
- Choose a visibility platform when the team needs recurring scans, competitor and cited-page records, generated fixes and a link to search performance.
Cituna is one option for the third case: it runs daily buyer-question checks across all seven named engines, records the answer evidence and generates technical or page-level fixes. Its plans include the seven engines without per-engine add-ons, while a manual process may suit a team that only needs a one-off diagnostic. Compare the method against the decision you need to make, not against the largest possible metric set.
7. Diagnose the first failed layer before rewriting content
The first failed layer determines what to change next, so fix access and page selection problems before rewriting copy. Technical SEO changes often fail as measurement exercises because teams jump from a missing mention to new content without checking whether engines could use the intended page.
Work through the diagnosis in this order:
- If the live page is blocked, missing, redirected incorrectly or not rendered, repair deployment, access or rendering first.
- If the page is accessible but never cited, inspect canonical signals, internal links, structured data and whether the page directly answers the tracked prompt.
- If the page is cited but the brand is absent or low in the answer, improve clear entity and offering language without changing facts that are already correct.
- If the wrong page is cited, clarify page purpose and connect the preferred page through internal links and consistent references.
- If visibility improves but search clicks do not, inspect the query and snippet evidence before claiming a traffic effect.
Run the same prompt set after each material fix. This prevents several changes from being bundled together, which would make the apparent winner impossible to identify.
8. Validate the result before calling the release successful
A technical SEO release is successful when the intended page remains accessible and the measured answer improvement persists across repeated runs without creating new accuracy or search problems. Do not close the test because one engine produced a better answer once.
Use a release decision record containing:
- The baseline and post-release dates.
- The prompts and control prompts used.
- Results for each of the seven engines.
- Changes in mentions, citations, positions and target-page usage.
- Crawler, rendering, canonical and structured-data checks.
- Google Search Console movement for changed and control pages.
- The next action, owner and date for another run.
If the result is mixed, keep the technical change that clearly fixed access and isolate the unresolved answer problem. If the result is positive only on one engine, report it as engine-specific rather than as a universal gain. For a formal decision about whether movement exceeds ordinary variation, use the Test AI Visibility Changes for Significance method and keep its test conditions consistent with the baseline.
Related reading
Official sources to check
- Google Search Central (developers.google.com)
- Google Search Console Help (support.google.com)
- OpenAI Platform (platform.openai.com)
- Perplexity API Documentation (docs.perplexity.ai)
Drafted with AI assistance from our own research and Search Console data, and reviewed by Rahul A before publishing. Rules and prices change; check the linked official source before you act.