Comparisons
How to verify a declared feature: AI visibility criteria
A declared feature is not the same as an available one. Here is how to check, before it enters the editorial plan, whether a feature is active in your environment and produces an observable result.
In an AI visibility editorial workflow, it is worth checking that a feature is actually available before you put it into the editorial plan, not just named. The check starts from a concrete question: is the feature active in our environment, and does it produce an observable result? On RankAI, the default is human approval of a version. Automatic publishing is turned on per site and still goes through the checks. The public pages name ChatGPT, Perplexity, Gemini, Grok and Google AI. Claude and Grok are measured only after you connect them. Gemini and Google AI Overviews are not the same observation. Use these points as verification criteria, not as a promotional list.
The rule: available versus merely named
A feature is available when we can say where it is active, which check governs it, and what observable result it produces in our editorial workflow. It is merely named when it appears on a public page or in a description but we have no observable result in our environment. The distinction is operational: the editorial plan can cite a feature only if the check produces a result we can document.
Illustrative example, not observed
Illustrative example, not observed. Case A: the “automatic publishing” feature is active for a site and subject to the checks; the result is documented as available because we know where it is turned on and which human approval still applies. Case B: a feature is named on a public page but is not connected to our environment; the result is “not available” because the observation in the workflow is missing. Ambiguous case: the feature is active, but its result cannot be told apart from another observation, as with Gemini versus Google AI Overviews. In that case we do not declare it available, and we hold it out of the editorial plan.
This is RankAI’s proposed approach, not a universal standard: before we write a feature into the editorial plan, we fill in a card with three required fields — where it is active, which check governs it, and what observable result it produces. If any of the three is blank, the feature is “merely named” and does not go into the plan. If two different observations get confused, as with Gemini and Google AI Overviews, the card is marked “ambiguous” and the check stops until we separate the two observations. This criterion keeps the editorial plan from mistaking the presence of a name for actual availability in our workflow.
Verification checklist for the editorial plan
- Write down the feature and the point in the editorial workflow where it should act.
- State where it is active and which check governs it.
- Record the observable result in our environment.
- Separate observations that do not match, such as Gemini and Google AI Overviews.
- Stop and mark it “ambiguous” if the result cannot be told apart; do not add it to the plan.
Verifiable limit: this procedure does not establish whether a feature improves AI visibility; it establishes only whether the feature is available in our editorial workflow. For the full context, see the in-depth page.