一次假阳性排查：搜索引擎把我搜的词塞回了页面里
这篇讲我们自己犯的一个错。写出来是因为它几乎必然发生在任何自建监测工具上，而且发生了你不一定看得出来 —— 数据看着很漂亮，方向是错的。
现象
我们在测一家客户的品牌词命中率。探针的逻辑很简单：拿问题去搜，把返回的页面文本抓下来，看里面有没有出现客户的品牌关键词，有就算命中。
报表显示：必应上五次测量，品牌词全部命中，命中率 100%。
但人工打开同一个搜索页面看，自然结果里一条都没有这家公司。
原因：搜索引擎会把你搜的词还给你
问题出在「页面文本」这个定义太粗。一个搜索结果页里，包含查询词的地方远不止自然结果：
<title>和<head>里的元信息 —— 标题通常就是「你搜的词 - 必应」- Open Graph 标签，
og:title、og:url里都带着查询词 - 无障碍属性，比如搜索框的
aria-label、按钮的title - URL 参数，
q=、qpvt=、bq=等等，而且常常是 URL 编码后的形态 - 页面内嵌 JavaScript 配置里的 JSON 键值，同样藏着查询词
换句话说：只要你搜了某个词，返回的页面里就一定含有这个词，不管自然结果里有没有。用整页文本做匹配，品牌词的命中率必然是 100% —— 这个数字毫无意义。
修了三轮才干净
第一轮：剥掉 <head> 和 <title>。以为解决了，实际没有 —— aria-label 在 body 里。
第二轮：剥掉所有 HTML 属性值（单引号双引号都要管）。好多了，但还有漏。
第三轮：把含 URL 编码片段（形如 %XX）的整个 token 全部剥掉，再剥掉 JSON 里的查询键。因为查询词会以二次编码的形态藏在 JavaScript 配置的 URL 串里，普通的属性剥离抓不到。
三轮之后命中率从 100% 掉到 0% —— 这才是真实情况。
更重要的是配了反向测试
剥离逻辑有个明显的风险：剥得太狠，会把真实提及也一起剥掉，于是所有命中率都变成 0，看起来同样「稳定」。
所以修完之后我们补了单元测试，其中一半是反向用例 —— 构造一段确实包含真实提及的自然结果，断言剥离之后它必须还在。只测「假阳性被消除」是不够的，必须同时测「真阳性没被误杀」。
对客户的实际意义
如果一份 AI 可见性报告给你的品牌词命中率是 100% 或者接近 100%，值得警惕 —— 大概率就是这个坑。
另一个判断方法：要求对方用不含你公司名的问题来测。品牌词本来就容易命中（客户搜你的名字，找到你不奇怪），真正有商业价值的是品类词 —— 「上海有哪些靠谱的 H3C 系统集成商？推荐几家」这种。这也是我们做诊断时坚持不用公司名做测试问题的原因。
顺带说一句：我们第一次给自己公司测品类词，八个 AI 全部是零命中。这个数字不好看，但它是真的，而且零起点反而好归因 —— 后面任何一次命中都能说清是哪个动作带来的。
要点回顾
- 搜索结果页里必然含有你搜的那个词，用整页文本匹配会得到 100% 的假命中率
- 查询词藏在 og 标签、aria-label、URL 参数、内嵌 JS 配置里，要逐类剥离
- 剥离逻辑必须配反向测试，否则「真实提及被误杀」一样看不出来
- 看到品牌词命中率接近 100% 要警惕；要求用不含公司名的品类词重测
依据：我们探针脚本的剥离逻辑与其单元测试（含真实提及必须保留的反向用例），修复前后的原始返回均有留档，可逐条复核。