站内搜索与推荐：AI 候选集的内部影子

周三下午，一家做宠物智能用品的出海团队在争一件事：下个月的内容预算做对比页，还是补“能不能配 App”这类说明页。增长负责人想先买一个 AI 可见度监测工具，用外部数据定选题；技术负责人没接话，打开站内搜索后台，导出最近 90 天的查询词。第一页写着“自动猫砂盆 能不能 用 豆腐砂”“同款 哪个好”“出差 三天 够不够”。这些句子，监测工具的提问列表里一条都没有。

站内搜索词、零结果查询与共购关系，是你能拿到的最便宜的一份候选集研究样本；但它只是影子，必须和外部提问对照校准，否则你是在用已经到站的人的需求，推测还没到站的人的提问。

为什么站内搜索能看见 AI 的候选集

判断很直接：两者是同一件事的两个版本——一个问题进去，三到五个名字出来。

站内搜索是检索、排序、结果页；AI 答案是检索、生成、引用。相同处比想象中多：输入是自然语言，输出是有限候选，排序依据都是“匹配度，加上凭什么信你”。不同处也很硬：你的候选池是自家 SKU，AI 的候选池是全网页语料加平台商品。所以站内搜索能告诉你“问题的形状”，不能告诉你“问题的规模”。

共购与推荐数据补的是另一半：谁和谁被一起考虑。买家问“哪个更适合”时，AI 需要一组可替换的候选，共购是最接近“替代品”的站内信号；配件、耗材的共购关系，则决定“兼容性”这类答案能不能被组织出来。

偏差是结构性的：站内查询只覆盖已经进站的人，AI 面对的却是更早、更泛的提问者。把站内分布当成市场分布，是这类研究最常见的错误。

三类数据，只有一类能直接用

查询词信息量最大，零结果行动性最强，共购结构性最好。三类混成一张“热搜词”报表，就都没用了。

数据	你在读什么	对 GEO 的用处	常见坏法
搜索查询词	买家的原话：比较句式、场景约束、属性词	生成内容缺口与对比页选题	只算无结果率，不读句子
零结果与低点击查询	你答不出、或答了没人点的问句	最硬的缺口清单	归进“其他”就关掉
共购与推荐曝光	谁和谁被一起买、一起看	对比页配对、兼容性字段	只看推荐位点击率

三类数据要能用，得 join 到同一个键上：query → 落地页 → 商品或类目。没有这个键，日志只是报表。埋点至少记三样：查询原文、结果条数与首条、是否点击。少一样，判断“答不出”还是“答了没人看”就只能靠猜。

从查询到内容缺口：五步

这一步的产物不是一份报告，是一张带负责人和验证日期的表。

步骤	做什么	谁来做	怎么算过
1 取数与归一	90 天 query，去重、合并变体、剔除纯品牌词与导航词	数据	唯一查询数降下来，语义簇稳定
2 打四类标签	比较型、场景型、属性型、售后型	内容 + 运营	九成以上查询能落进一类
3 对齐页面库存	每个查询簇指到一个页面	内容	每个簇有页面，或明确标“无页”
4 判断病灶	无页是缺口，有页零点击是答偏	内容 + 前端	两类分开列，不混成“优化项”
5 排期与验证	每簇一个负责人、一个验证日期	增长	30 天后回看该簇点击与复测结果

只有第 4 步需要判断力，也最容易糊过去。查询有结果却没人点，通常不是排序问题，是标题和摘要没回答那句话；查询没结果，也不等于要做新页面——多数时候是搜索同义词没配。把“移动电源”和“充电宝”配成同义词是一小时的活，新建一页是一个月的活。这些簇最终要落到候选集上，AI 怎么从一堆名字里挑出三五个，见本期主线AI 的候选集只有 3–5 个名字，怎么进去。

示例：一份 90 天日志读出了什么

以下为虚构示例，只演示读法，不指任何真实品牌。

一个卖空气净化器的自建站，假设 90 天站内搜索 1.8 万条，归一化后 4200 个唯一查询。按四类打标：场景型接近一半，属性型次之，比较型不到两成，售后型最少。场景型里出现频率最高的是“多大面积够用”“新房用多久”“宠物毛能不能滤”“滤芯能不能通用”。

团队原以为买家在比参数，日志显示他们在确认“我家的情况能不能用”。于是预算从降价专题改成三件事：一张滤芯与机型的兼容性表、一段适用面积与房间数的场景说明、一份养宠家庭的选择指引。推荐位的共购数据也印证了同一件事——买机器的人常一起买滤芯，通用性写不清，搭售就断在那里。三个月里他们只跟一个指标：这三个查询簇在结果页的点击，是否从第二页移到第一页。这个指标能自证，转化率不能。

这次读日志真正的收益不是找到三个选题，是纠正了一个假设。同样的纠正也适用于品类结构：查询簇的边界，往往就是品类树该怎么建的边界。

和外部提问对照：影子要校准

站内数据决定“做什么”，外部提问决定“值不值得做”。两者不重叠时，不要用站内数据硬排优先级。

做法是把站内前 50 个查询簇改写成买家在 AI 里的问法：去掉品牌词，补上场景，在两三个入口各问两遍，记三件事——你在不在候选里、和谁一起出现、AI 怎么描述你。结果分三种情况处理。

高度重叠：站内问得多，AI 也这么问。影子可信，直接排期，这类簇的投入产出最好。

站内多、AI 少：需求已经到站。这是转化问题，不是 GEO 问题，交给详情页和评论，不要占内容预算。

站内少、AI 多：最该警惕的一类。说明买家的问法已经跑到你的流量结构前面，站内日志看不见它们。这时要外部提问集主导，站内数据只做验证。

校准之后要盯的不是排名，而是候选集份额：同一批问题里，你出现在几个候选名单中。它比“有没有被提到”更接近生意。

边界：什么时候这份日志不值得读

样本太薄。 每月站内搜索不足几百条，簇化后每簇两三条，再外推就是自欺。新站、新市场先做外部提问集。

搜索框被当成导航。 查询里全是品牌词、SKU 号、“客服”“物流查询”，说明它承担跳转功能，不是研究功能。先改结果页，再谈读日志。

成交主要在平台内。 平台搜索词不在你手里，后台只给聚合报表。这时站内日志只覆盖自建站那一小块，别拿它代表整个市场。

合规不允许。 查询原文可能带邮箱、电话、地址。导出前脱敏，跨境传输与上传第三方工具都要按当地规则处理。

还有一条常被忽略：高客单、强体验的品类，买前功课发生在社区和视频里，站内搜索反映的是“已经决定的人”。这份数据能优化成交，预测不了候选集。

这类活落在技术底座：埋点、join 键、脱敏、复测口径都是工程问题，选题判断是内容的事。两张皮，日志一定烂在硬盘里。

这个月先做一件事：导出最近 90 天的站内搜索日志，脱敏、归一化、按四类打标，取前 50 个查询簇；挑其中 10 个改写成 AI 里的问法，在两个入口各问两遍，记下你在不在候选集里。不需要新工具，一个人两天能做完。