Comparisons
AI Visibility: How to Read the Features Page
The RankAI features page shows what can be observed about a site's AI visibility. It is not a forecast of where you will rank. Here is how to read it without turning an observation into a promise.
If you are building an editorial plan and want to understand what can be observed about a site's AI visibility, treat the RankAI features page as a lens, not a verdict. Take a page you published recently: open the features page, note which of the observed AI engines are named, and compare what you see with the actual page. That tells you how pages are handled in the observations available. It does not tell you where you will end up tomorrow. AI visibility and your editorial plan remain two separate things: the first is what we can observe, the second is your own decision about what to write next.
A three-step method for reading the features page
RankAI's working proposal is this: use the features page as the starting point for a repeatable check, not as confirmation of a result. Each step has a verifiable criterion.
- List the observed engines and keep the observations separate. The public pages name ChatGPT, Perplexity, Gemini, Grok and Google AI. Verifiable criterion: for each engine, write down whether the observation is available right away or only after you connect it. Claude and Grok are measured only after you connect them; if you have not connected them, that data point is not there, and it should not be read as an absence of visibility.
- Do not merge Gemini and Google AI Overviews. Verifiable criterion: keep two separate columns in your reading sheet. Gemini and Google AI Overviews are not the same observation, so a result on one does not carry over to the other.
- Compare the observation with the page in front of you. Verifiable criterion: open the published page and check that the observed content matches what you see. If the observed engine returns an API response, remember that this is not a person's screen: it is a technical observation, not a preview of the user experience.
- Turn the reading into an editorial decision. Verifiable criterion: for each observed page, note one single change to try in the next cycle and the date when you will read the features page again. If you cannot name the change, the observation is not yet useful to the editorial plan.
What the features page leaves out
The features page does not say where you will rank, does not measure search volumes, and does not cover every AI engine that exists. At RankAI we keep this distinction explicit: what is observable is how pages are handled in the engines we name; what stays out is future position and any engine not listed. If an engine is not among the ones we observe, do not infer a result from it: it is simply not part of the reading.
The most common risk, when you look at the features page with the goal of building an editorial plan, is treating a single observation as if it were a prediction. Our proposal is to reverse the order: first decide which editorial question you want to test, then choose the page to observe, then read the features page. In practice, keep a log with four columns — page, observed engine, what you saw, change to try — and fill in only the rows where you have an actual observation. Empty rows are as informative as filled ones: they show you where the connection is missing or where the engine is not among those observed. This avoids two mirror-image mistakes: taking a technical data point for a user's screen, and taking missing data for missing visibility. Reread the log at intervals you decide on, not on the basis of promised results: it is a working method, not a universal standard, and as such it should be adapted to your site.
One limit to keep in mind
The verifiable limit is this: the features page shows only observations on the engines we name and, for Claude and Grok, only after you connect them. Everything about future position, unlisted engines, and what a person sees on a screen stays outside the reading. For the full picture, see the in-depth page.