AI 搜索可见度：看提及、看引用，也看客户咨询

分清四种事件

企业出现在 AI 回答中，可能没有带来点击；有人访问网站，也可能没有咨询；收到咨询，也可能不符合服务范围。把这些都算作同一个成功指标，会难以判断究竟该改进哪里。

查看结果前，先定义有效咨询。以一家虚构的维修公司为例：需求属于公司提供的服务、地址位于服务区域内，并且确实希望委托工作。按自己企业的情况制定标准，并始终使用同一标准。

记录观察条件

检查 AI 回答时，保存原始提问全文、平台、可见的模型或模式（如有）、日期、地点背景，以及是否使用新对话。同时保存回答和引用链接的目标页面。缺少这些记录，之后出现差异时，就可能无法解释原因。

把发现型提问与品牌问题分开。“谁能提供这项服务？”和“这家指定公司提供什么？”测试的是不同场景。两者都有用，但合为一个可见度百分比，会掩盖实际测试了什么。

比较时沿用稳定的提问样本，探索性问题另行记录。增加问题时，注明变化。网站即使没改，样本变大或问题变容易，也会影响百分比。

了解引荐与归因的局限

Profound 对 ChatGPT 引荐链接的分析说明，平台展示链接的方式会影响观察到的引荐行为。因此，报告应标明平台变化。流量记录变化，不能直接证明是最近一次内容修改带来的。

分析工具只能看到客户过程的一部分。有人读完 AI 回答，稍后搜索企业名称，再换一台设备联系企业；引荐来源也可能缺失或没有参考价值。自愿回答“你是如何得知我们的？”可以补充背景，但人的回忆仍可能不准确。

按企业实际的隐私做法选用分析工具，并准确公开说明。不要只为了让仪表盘完整而增加跟踪。小企业需要的是能理解、也能持续维护的衡量流程。

小样本，可以说明什么

以下数字为虚构示例，用于说明解读方法，并非 FoundUp 的成果。假设一家企业在一轮测试中检查十二个发现型提问：四个回答提到企业名称，两个引用企业网站；分析工具当月记录到十八次可识别的 AI 引荐访问，三次咨询提到了某个 AI 工具。

这些数字不能串成一个可完整追踪的漏斗。十二个提问只是小型测试集，不能代表全部客户问题；十八次访问可能来自测试集之外；三次咨询可能包含在这些访问中，也可能来自其他途径。

报告应分开说明每项观察，并标明未知之处。例如，一个回答仍使用旧服务区域，就值得单独列出并安排纠正。记录只显示咨询时，就不能说“AI 带来了三位客户”。

有权限时，补充平台第一方报告

截至 2026年9月28日，Google 的 Generative AI performance report（生成式 AI 效果报告）提供了受支持的搜索 AI 功能的展示次数。查看可用的页面、国家或地区、设备和日期维度。报告缺失或数据不足，不等于实测为零；这些展示次数，也不等于 ChatGPT 引用、点击或有效咨询。

也应检查该资源的 Search generative AI control（搜索生成式 AI 控制设置）。技术上允许抓取，并不能证明资源已设置为允许纳入。将核实后的设置状态与索引证据一并保留，不要仅凭公开 robots.txt，就判断所有纳入条件均已满足。

Bing 的 AI Performance 报告，可从该平台的角度查看引用和用于检索回答依据的查询。应保留各平台自己的定义和覆盖范围，不能把指标合成一个通用 GEO 得分，也不能把一次展示视为客户转化。

记录缺失数据，别记成零

将这些字段复制到工作表，每个回答单独记录。完整回答另行保存，在最后一个字段填写对应的记录位置。工作表中不要放入客户隐私信息。

observed_at,prompt_id,prompt_text,platform,model,market,language,
prompt_type,brand_mentioned,owned_source_annotation,owned_link_in_text,
fact_check,referral_visits,qualified_enquiries,data_status,answer_record

针对 FoundUp 品牌问题的 API 回答，正文虽有链接，却没有结构化来源标注，且错误解释了 GEO 的全称。只报告“品牌可见”，就会掩盖实际问题；报告零次引荐访问同样不对，因为这次 API 调用根本没有衡量网站访问。

导出平台仪表盘数据时，应连同数字保留平台定义和缺失数据标记。Google 的生成式 AI 效果文档提醒：界面显示为 ~ 或 - 的不可用值，下载后会变成零。因此，要随导出文件保存界面状态和报告时间段，再判断零是否代表实际未发生。这是基于文档的提醒，不表示我们已检查 FoundUp 的 Search Console 报告。

每月进行一次简短回顾

1. 检查业务结果。按同一定义统计咨询，看看不符合服务条件的咨询是否有共同原因。
2. 检查准确性。列出提问样本中有关服务、地点、价格或联系方式的错误说法。
3. 检查来源。保存重要回答所使用的 URL，并注明它们是自有页面还是外部参考来源。
4. 标注变化。记录网站发布、营销活动、季节性变化、提问修改及已知的平台变化。
5. 先做一项小改进。扩大报告范围前，可以先纠正一个事实、写清服务边界，或排查无法正常访问的页面。

咨询量较少时，不必对每次月度百分比波动立即作出反应。先阅读真实需求，如实呈现不确定之处。衡量应帮助决策，不能用小样本编出看似笃定的结论。

参考提问测试指南设计观察集；回答有事实错误时，按纠正流程处理。

可查阅的观察记录

以下记录来自 FoundUp 自身的 API 测试，并非客户成果或真实用户搜索记录。表格列出了测试问题、回答内容，以及这些证据无法证明什么。

完整的问题集和方法保留了原始样本。监测方案应约定平台或模型、问题、市场、语言、频率、报告时间段，以及谁负责跟进发现的问题。本示例不代表 FoundUp 的标准监测安排。

下载记录模板，直接使用

下载空白观察模板（CSV），或查看已填写的 FoundUp 示例（CSV）。示例保留了上述 9月28日的品牌诊断，包括回答对 GEO 的错误解释。这是历史观察记录，并不代表最新网站版本的结果。

每个回答占一行，记录问题原文、测试时间、平台和模型、语言、地点设置、品牌提及、结构化来源标注、正文链接及局限。团队自编的问题只能用于评估，不能证明存在搜索需求。无法取得的数据应留空，不能记成实测为零。

这个示例中，回答提到了 FoundUp，正文中也有网站链接，但未返回结构化来源标注。下载文件将三者分列为不同字段；来源 URL 指向这份说明记录。需要时可在非公开记录中保留完整回答，任何公开导出文件都应排除客户信息和凭证。