对比
用 features 页把 Google 阅读与 AI 回答对齐
在 RankAI 的 features 页里，先把 Google 对页面的阅读和 AI 回答并排放在一行，再决定改哪段内容。这是 RankAI 提出的用法，不是页面已文档化的自动流程。
在 RankAI 的 features 页里，先把两件事并排放：一边是 Google 对某个页面的阅读，另一边是 ChatGPT、Perplexity、Gemini、Grok 和 Google AI 在回答里呈现出的内容。做法是选一个真实页面，记下 Google 读到什么，再就同一主题收集 AI 回答，最后才决定写或改哪段内容。这是 RankAI 提出的用法，不是 features 页已文档化的功能：页面并没有被描述成自动把两种阅读连起来的流程。
为什么两种阅读要分开记
AI 可见性和编辑计划只有各自独立记录时才谈得上交叉。RankAI 的公开页面提到 ChatGPT、Perplexity、Gemini、Grok 和 Google AI。Claude 和 Grok 要在连接之后才测量。Gemini 和 Google AI Overviews 不是同一次观察，应当当作两个不同结果来读，而不是一个信号。API 返回的回答也不是人在浏览器里看到的画面，所以回答里看到的内容和用户在浏览器里看到的不一定一致。
三步方法，每步都有可核对的判据
- 选一个页面，记下 Google 的阅读。取站点里的一个 URL，写下 Google 读到什么：标题、主要内容、提到的实体。判据：页面卡片上列出的元素，打开该 URL 后都能对上，没有多出来的。
- 就同一主题去问助手。按读者会问的方式提一个问题，收集 ChatGPT、Perplexity、Gemini、Grok 和 Google AI 的回答。判据：每个助手都保留原问题和拿到的回答，方便之后复查。
- 对照，再决定改什么。把 Google 的阅读和 AI 回答摆在一起：某个实体或概念在 Google 里有、回答里没有，或者反过来，那就是要处理的地方。判据：编辑计划里的每条改动都写明起始页面和促成它的那条回答。
features 页里一行填好的样子
假设 features 页里有一行这样填：页面 /guida-alla-visibilit-ai；Google 阅读 = 标题「Visibilità AI」，主段落讲助手的回答，实体为 ChatGPT 和 Perplexity；ChatGPT 回答 = 提到 Perplexity，没提 Gemini；Perplexity 回答 = 把 Google AI Overviews 作为单独观察引用；Gemini 回答 = 没有提到该页面。从这一行，编辑计划只得出一个动作：在页面里加一段，把 Gemini 和 Google AI Overviews 区分开，因为 Google 的阅读和回答里都缺这个区分。这一行只是把数据并排摆出来，决定仍由我们做：features 页本身不会把两种阅读连起来。
这篇的贡献是 RankAI 的一个操作建议：把 features 页当作收集点，而不是决策引擎。实际用起来，示例里填好的那一行就是提醒：Google 的阅读和 AI 回答在某个实体上对不上，这个差异就变成编辑计划里的一条。采纳它的判据很简单：必须可复查，也就是要写明页面、提的问题和拿到的回答。这样 AI 可见性就不是印象，而是可以和 Google 读到的东西对照的数据。这个方法不保证排名，也不保证结果，只是让写之前先把观察排好。
可核对的边界
边界在记录里：RankAI 的公开页面提到 ChatGPT、Perplexity、Gemini、Grok 和 Google AI；Claude 和 Grok 要在连接之后才测量；Gemini 和 Google AI Overviews 不是同一次观察。所以我们不能把 features 页说成自动连接 Google 阅读和 AI 回答的流程：这个连接是我们的方法，不是已文档化的功能。页面细节见深入说明页。