AI对话正在“泄露”进你的Search Console:7类AI查询识别指南(附正则筛选)
大家好,我是Neo。
问你一个问题:你的 Google Search Console 查询报告里,最近有没有出现过一些“不像人话”的搜索词?
比如 “yes”、“yes go on”、“yes, pricing”、“what about resend?”……
别笑,这可能是你 2026 年能捡到的最值钱的数据泄露之一。
8 月初,一位叫 Anastasia Kourou 的 SEO 在 LinkedIn 上贴出了一张截图:她的 Search Console 查询报告里躺着一堆这样的词。她直接艾特了 Google 的 John Mueller,问了一个很尖锐的问题——你们是不是在记录人们对 AI 说的话?
Mueller 的回答让整个 SEO 圈炸了:是的。
更戏剧性的是后续:官方确认了这个机制,但没人知道该怎么利用它。直到 8 月中旬,一位叫 Suganthan Mohanadasan 的 SEO 把自己 16 个月的 Search Console 数据翻了个底朝天,把这类“AI 对话查询”分成了 7 类,还给了一套完整的识别和利用方法。
这篇文章,我把整个事件的来龙去脉、7 类查询的识别方法、以及独立站卖家该怎么用这份数据,一次给你讲透。
一、事件还原:GSC 里为什么会出现“yes”?
先把时间线捋清楚。
8 月初,Anastasia Kourou 在自己的 Search Console 查询报告中发现了奇怪的东西:一堆单字词、半截话,比如 “yes”、“yes go on”、“yes, pricing”。这些词完全不像传统搜索——谁会在搜索框里只输入一个“yes”?
她把截图发到 LinkedIn,问 John Mueller:Search Console 是不是在追踪人们对 AI 说的话?
Mueller 的回复直接引用了一段官方文档:
“Search Console includes information on AI Overviews and AI Mode in the general performance report… If a user asks a follow-up question within AI Mode, they are essentially performing a new query. All impression, position, and click data in the new response are counted as coming from this new user query.”
翻译过来就是:Search Console 会把 AI Overviews 和 AI Mode 的数据计入主性能报告;用户在 AI Mode 里追问一句,本质上就是发起一次新查询,后续响应里的展示、位置、点击数据,全部记在这条新查询名下。
8 月 6 日,Search Engine Roundtable 报道了这件事。底下评论区的 Ross Tavendale 问出了所有人都在想的问题:既然 Search Console 在记录人们对 AI Mode 的回应,我们怎么反推利用它?
没人回答。
8 月 13 日,Suganthan 在自己的博客上给出了答案——他用 16 个月的真实数据,把这类“AI 对话查询”分成了 7 种类型,并开发了一套分类工具(开源 MCP),让每个人都能在自己网站上跑一遍。
二、为什么说这是“泄露”?因为官方报告不给查询数据
要理解这份数据的价值,得先明白 Google 官方在“AI 可见性”上给了你什么、又藏了什么。
2026 年 6 月 3 日,Google 上线了 Search Generative AI 性能报告(GenAI 性能报告),专门统计你的网站出现在 AI Overviews 和 AI Mode 里的情况。到 8 月 11 日左右,这份报告已经大规模开放,绝大多数站点都能看到了。
这份报告有 5 个数据维度:
- 展示次数(impressions)
- 页面(pages)
- 国家(countries)
- 设备(devices)
- 日期(dates)
唯独没有查询词,也没有点击。
而且没有任何 API 支持——Search Analytics API 的类型参数还停在 googleNews,searchAppearance 维度查不到任何 AI 相关数据,BigQuery 批量导出的 schema 里也没有 AI 列。你想把数据拿出来?只能手动点 UI 里的导出按钮。
也就是说:Google 告诉你“你有多少 AI 可见性”,但拒绝告诉你“是因为什么查询获得的”。
(Suganthan 在文章里吐槽:我们都懂为什么哈哈。)
但与此同时,那个你看了很多年的普通性能报告,一直在悄悄收录 AI 对话碎片。因为官方把它们当作普通查询处理,没有任何过滤。
怎么证明这些“yes”真的来自 AI 对话,而不是真人搜索?Suganthan 用位置数据做了个绝妙的证明:
他的网站对 “yes” 这个词的平均排名是 4.5 位。但在开放网络上,“yes” 这个词属于歌曲和语法网站,任何正常网站都不可能排到 4.5 位。唯一的解释是:他的链接出现在 AI 回答的内容块里——因为 Google 文档规定,AI Overview 里的链接继承整个内容块的位置,AI Mode 的引用在滚动到视野内后也按同样规则计数。
位置 4.5 的“yes”,意味着你的链接躺在 AI 的答案里,而不是搜索结果页上。
这就是那份“泄露”数据。问题只剩下一个:怎么从海量正常查询里把它们分辨出来?
三、7 类 AI 对话查询:一份可执行的识别清单
Suganthan 拉出了自己 16 个月的查询记录,把凡是“不可能是打字搜索”的条目全部过了一遍,最终归纳出 7 种类型。他找到了 1,127 条查询、20,300 次展示——跟数百万普通展示比起来微不足道,但每一条都是一个真实会话留下的痕迹。
1. 裸回复(Bare replies)
特征:yes、sure、really?、show me……用户在和 AI 对话中途做出的回应,被当作一次搜索处理,你的页面恰好出现在回复内容里。
2. 对话中途的对比(Mid-conversation comparisons)
特征:what about resend?、what about gemini、how about in chinese?
这是最有价值的一类。用户手上已经有一个答案,正在让 AI 对比替代方案——他们点名的那一个,才是他们真正在乎的。
Suganthan 发现这类查询和他的文章一一对应:“what about claude” 命中他的 WebMCP 指南,“what about xcode?” 命中 Xcode 文章,“what about wayback machine” 命中 Wayback 教程。每一个都是一位读者在让 AI 拿某个东西和他的页面做对比。
3. 对着“人”说的问题(Questions addressed to someone)
特征:can you jailbreak meta raybans、how do i sell it、is it free
这些句子的语法只有对着“听者”才成立——不是对着搜索框打字,而是对着 AI 说话。
4. AI 可见度工具跑出来的合成提示词(Synthetic prompts)
特征:以 “. my location is usa.” 结尾的提示词;“evaluate the [company] on [facet]” 句式。
谁会连续两个月每天搜一模一样的句子?不会是人——是软件。AI 可见度追踪工具定时跑的提示词,被 Google 原样记录成了查询。
5. 机器完整指令(A machine’s complete instructions)
特征:“search the web for… return the 3 most relevant results you actually found… do not invent results or urls.”
某个工程师写的提示词模板,整段被 Google 归档为一次查询。
6. 报错信息和表格头(Error messages & spreadsheet headers)
特征:他的数据里躺着一条某排名追踪工具完整 CSV 表头的查询,拿下了 146 次展示;还有人把 X 客服的整封拒信粘进去当查询。
7. 10 词以上的长查询(Quarantined long queries)
特征:超过 10 个词、没有其他特征标记的查询。可能是引用的句子、可能是 agent、也可能是真人。这类进“待人工复核”队列,不做自动判断。
四、冰山效应:你看到的只是水面上的 1,127 条
Suganthan 用 BigQuery 批量导出交叉验证了一个残酷的事实:
最近 59 天里,他网站 57.7% 的网页展示没有任何查询字符串(被 Google 匿名化处理了)——454,720 次匿名 vs 333,651 次可见。他识别出的 1,127 条对话查询,只是这片隐藏水池露出水面的尖角。
读这篇文章里的每一个数字,都要当作下限来读。
时间线也很有意思:2025 年 4 月到 11 月,裸回复类查询的展示为零;12 月出现第一丝火光;2026 年 3 月开始全面点亮,此后每个月稳定在 20-30 次展示。
一个之前整整 8 个月不存在的查询类别,突然变成常态——这就是 AI Mode 用户量起飞的时间戳。
再看几个关键数据:
- 光 “yes” 这一个词:110 次展示、6 次点击、平均位置 4.5。6 个人对 Google 的 AI 说了“yes”,然后顺着自己的回应点进了他的网站。
- 对话类查询(第 2、3 类为主):559 条查询、8,834 次展示、13 次点击。
- 追踪器探针(第 4 类):124 条查询、2,902 次展示;其中某个“评估矩阵”连续 59 天每天对他的文章跑一次。
- Agent 指令(第 5 类):合计 2,181 次展示,其中一条在 5 天内跑了约 2,160 次。
还有个名场面:他的数据里躺着一条查询—— “you didnt give me the link”(你没给我链接),一个用户在和 AI 吵架,Google 把这句抱怨记录在案,并计入了他的 Wayback 教程页。
Google 记录了一个人和机器人吵架的全过程。经典。
五、实操:怎么在自己网站复现这套方法
Suganthan 把整套识别逻辑做成了免费开源的分类工具(Search Console MCP)。但即使你不用他的工具,有几件事你现在就能做:
1. 先用正则快速筛选
进入 Search Console → 效果报告 → 添加过滤器 → 查询 → 自定义,粘贴这个正则:
^(yes|yeah|ok|okay|sure)[?!.,]*$
你就能看到自己网站上所有“裸回复”类 AI 对话查询。
2. 识别主战场:对比类查询(pivots)
这类查询直接告诉你用户正在拿什么东西和你的内容对比。有人搜 “what about X” 命中你的页面,说明你的页面缺了 X 的对比内容——这就是一份免费的内容需求清单。写上一节 X 的对比分析,就能接住别人已经在问 AI 的问题。
3. 有展示、没点击的对话查询:改正文,别改标题
这一点特别重要。对话类查询里,用户根本看不到你的标题——他看到的是一段 AI 生成的回答。真正进入 AI 回复的是:回答问题的那个段落、标题下的第一段、那张表格、那个具名事实。
所以标题优化对这类流量几乎无效,正文段落和结构化内容才是战场。这和我在 ChatGPT 侧研究里反复得出的结论完全一致:AI 时代,优化的是“被引用的段落”,不是“被点击的标题”。
4. 机器桶要隔离,别污染你的分析
追踪器探针和 agent 指令(第 4、5 类)不是真实需求,做机会分析时务必排除。否则某个关键词工具迟早会一本正经地建议你优化 “yes” 这个关键词。
5. 数据出口的限制要心里有数
- UI 导出:每张表最多 1,000 行
- API:每个搜索类型每天约 50,000 行上限
- BigQuery 批量导出:无行数上限
对话字符串几乎不重复(没人会用同样的方式追问),所以它们大多藏在 API 丢弃的尾部数据里。大站建议直接上 BigQuery 批量导出。
六、Neo的解读
1. AI 对话已经渗透进最基础的数据管道
这件事最震撼的地方在于:没有发布任何新功能,没有任何公告,AI 对话的数据就这么混进了你看了十年的报表里。Google 把 AI Mode 的每一条消息都当作搜索处理,这个设计决策让所有站长的数据一夜之间“不干净”了——但反过来,也把一份极其珍贵的 AI 行为数据免费送到了每个人手里。
2. 这是 Google 变相送你的“AI 行为审计”
注意第 4、5 类——如果你在用 AI 可见度追踪工具,你工具跑的那些提示词,正在被 Google 独立记录在案。你的 Search Console 变成了一份关于“你的追踪器到底在跑什么”的免费审计报告。如果你没用这类工具,那你看到的是:第三方正在每天扫描你排名的关键词。这份数据本身就是情报。
3. “关键词”这个概念正在被重新定义
传统关键词工具处理的是“人打出来的搜索词”,现在你的查询报告里混着“人对 AI 说的话”和“机器对 AI 说的话”。不做分类,你的关键词研究就是在一堆脏数据上做决策。我相信未来所有像样的关键词工具都必须内置这类对话查询分类器——现在谁先做,谁就领先。
4. 对独立站卖家的直接建议
- 每周花两分钟,跑一遍上面的正则,看看有没有新出现的对话查询
- 把“pivot 类查询”列成清单,直接变成内容选题
- 重点优化:首段、小标题下的第一段、表格、具名数据——这些才是被 AI 引用进回答的内容
- 大站上 BigQuery 导出,别指望 UI 和 API
写在最后
从 8 月 6 日那张 LinkedIn 截图,到 8 月 13 日那份 16 个月数据的深度分析,再到 SEJ 在 8 月 17 日把它推给全世界——这件事的传播速度本身就说明,SEO 圈饿这种“能落地的 AI 数据”饿太久了。
对话已经在发生,Google 一直在做记录。 你现在要做的,是去读自己的查询报告,找出那些“不像搜索的搜索”,然后看看 AI 反复选择你的那些段落里,到底写了什么。
那里面,藏着你的下一个流量机会。
我是Neo,我们下篇见。