Define the recommendation decision before measuring
Recommendation-list visibility improves when the measurement matches the decision a buyer is asking an engine to make. Start with the category, use case, audience, and constraints that shape the shortlist, then write prompts that express those conditions in natural buyer language.
Do not combine every commercial question into one broad prompt set. A buyer asking for accounting software for a small agency has a different decision context from a buyer asking for accounting software with a public API. Record the conditions because they explain why one brand appears in one list but not another.
Create a prompt sheet with these fields:
- The buyer's job to be done
- The category or comparison set
- Important constraints, such as company size, location, budget, or integration needs
- The expected recommendation format, such as a shortlist, ranked list, or single choice
- The date and engine tested
Use AI Visibility Metrics for Recommendation Queries when you need a separate view of recommendation-query measurement. The useful distinction is between being named anywhere and being selected for the buyer's stated use case. A brand can have strong general visibility while remaining absent from a narrow recommendation list.
Run the same prompts across all seven engines
Run identical prompt families across ChatGPT, Perplexity, Gemini, Claude, Grok, Google AI Overviews, and Google AI Mode so that engine differences do not get confused with changes in your prompts. Keep spelling, constraints, and requested list size consistent, while recording when an engine does not return the same answer format.
Cituna asks these seven engines the questions a brand's buyers ask every day and records who each answer names and cites, the position of each name, and the competitors and pages that appear instead. A team can use that structure as a baseline, whether it measures manually or compares tools that automate the work.
Check each run for:
- Whether the brand is named at all
- The brand's position in the recommendation list
- Whether the answer gives a reason for recommending it
- Which pages or domains are cited
- Which competitors appear instead
- Whether the answer changes materially between runs
An engine response is not a stable ranking in the search-result sense. Store the prompt, engine, date, full answer, citations, and position together. Without the full response, a later change may look like an improvement even if the brand moved down the list or lost its supporting citation.
Separate mention, selection, position, and citation
Treat mention, selection, position, and citation as four different visibility outcomes. A brand that is mentioned in a footnote has not achieved the same result as a brand placed first with a cited product page and a reason that matches the prompt.
Use a measurement record that separates these fields:
- Mention: whether the brand appears anywhere in the answer
- Selection: whether the brand is recommended for the stated use case
- Position: where the brand appears among named recommendations
- Citation: whether the answer links to a page that supports the recommendation
- Fit: whether the reason given matches a real, current capability
The most useful first metric is usually selection rate by prompt family, not a blended visibility score. Position helps distinguish a marginal inclusion from a leading recommendation. Citation quality then shows whether the engine can connect the recommendation to an accessible source.
For example, an illustrative prompt asks for project management tools for a small design studio that needs client approvals. If a brand appears fourth, has no citation, and is described as supporting approvals only because a third-party list says so, the result has three separate problems: weak position, missing support, and possible claim risk. Fixing the homepage alone would not address all three.
Find the evidence gap behind each missing recommendation
A missing recommendation usually points to an evidence gap, not simply a lack of published words. Compare the pages cited for competitors with the pages available for your brand, then identify the exact buyer criterion that the engine cannot confidently connect to your brand.
Classify every gap before choosing a remedy:
- Discoverability gap: the relevant page is difficult for crawlers or users to reach
- Clarity gap: the page uses vague language instead of stating who the product suits and why
- Proof gap: the claim exists, but no documentation, example, comparison, or first-party detail supports it
- Consistency gap: important facts differ across pages or external references
- Source gap: competitors are cited by pages that your brand has not made easy to interpret
Check whether the recommendation page states the use case, audience, constraints, and distinguishing capability in plain language. Check structured data, headings, internal links, FAQ content, and rendered page access, but do not assume markup can compensate for an unsupported claim.
Cituna generates a proposed fix for each measured gap, including schema, FAQ markup, llms.txt, and page changes. The practical value of a generated fix depends on a human review of accuracy, wording, and whether the proposed page actually supports the recommendation.
Choose the first fix by decision impact
Prioritise the fix that can change a high-value recommendation decision and has a clear evidence path, rather than the fix that is easiest to publish. A missing description of a core use case normally deserves attention before a low-value citation on a peripheral page.
Score each gap against four questions:
- Does the prompt represent an important buyer decision?
- Is the brand absent, poorly positioned, or unsupported in that decision?
- Can one specific page or fact address the gap?
- Can the team test the change without changing several unrelated variables?
Use a simple order: first correct inaccurate or conflicting facts, then make the relevant capability explicit, then improve the supporting page and structured signals, and only then scale new content. This prevents a team from producing more articles while the source pages still fail to answer the buyer's main constraint.
Cituna's AutoSEO can write articles from measured gaps and Search Console demand, then publish them to WordPress, Shopify, a GitHub repository, or another CMS by webhook. Treat that automation as a scaling step after the priority is known, not as the first response to every missing recommendation.
Publish one controlled change and record its source
Publish one clearly defined change at a time when the goal is to learn what improves recommendation visibility. A controlled change might clarify a use case on a product page, add an accurate FAQ, correct schema, or create a supporting article that answers a specific buyer constraint.
Before publishing, record the original wording, the target prompts, the pages changed, the intended claim, and the date. Keep a source note for each important fact so that later edits do not introduce contradictions. Do not add llms.txt, FAQ markup, or schema merely because a competitor uses it; the underlying page still needs clear, supported information.
Use Google Search Console alongside engine-response data. Search Console can show whether a page's search clicks changed, but it does not by itself prove that ChatGPT, Perplexity, Gemini, Claude, Grok, Google AI Overviews, or Google AI Mode changed their recommendations. Keep search traffic and recommendation visibility as related but separate measurements.
For the broader measurement framework, see AI Visibility: How to Measure and Improve It. The page helps place recommendation-list checks alongside the other visibility signals without treating one score as the whole result.
Retest for movement, stability, and accuracy
Retest the same prompt set after the change and inspect movement, stability, and accuracy separately. A brand moving from fourth to second is a position improvement, but it is not a successful outcome if the cited page is wrong or the answer now makes an unsupported claim.
Compare each retest with the original record:
- Did selection change for the target prompt family?
- Did position improve, stay flat, or decline?
- Did the engine add a relevant citation?
- Did the explanation use the intended fact?
- Did a competitor disappear because of genuine improvement or because the answer changed format?
- Did unrelated prompts change in a way that needs review?
Repeat the check across all seven engines because movement in one engine does not establish movement in the others. Preserve both positive and negative results. A failed change can reveal that the proposed page was not the evidence source an engine uses for that decision, which is more useful than hiding the result in an aggregate score.
Decide whether to keep, revise, or scale the programme
Keep a recommendation-visibility change when it improves selection or support without reducing factual accuracy, revise it when the brand is named but the reason or citation is wrong, and scale it only when the same gap pattern appears across related prompts. This decision rule keeps automation tied to evidence.
Use a monthly review that groups results by buyer use case, not only by engine. Look for repeated competitor substitutions, recurring missing criteria, pages that win citations, and claims that engines repeatedly misunderstand. The next work item should be the most consequential repeated gap with a realistic source page.
Cituna combines daily engine questioning, gap-generated fixes, AutoSEO publishing, and built-in Google Search Console data so a team can move from measurement to a proposed change and then inspect related search movement. Its hosted MCP server can also connect Claude or another AI agent to the same data, with read tools on every plan and additional action capabilities on Pro. Those capabilities change the workflow, but the decision rule remains the same: verify the source, make one useful change, and retest the buyer decision.
Related reading
- AI Content Visibility: An 8-Step Check
- AI Agent Referral Measurement Across Seven Engines
- Improve AI Visibility for API Documentation
Official sources to check
- OpenAI developer documentation (platform.openai.com)
- Google Search Central (developers.google.com)
- Google Search support (support.google.com)
- Anthropic (anthropic.com)
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.