项目验收应采用“分平台建基线、分查询做测试、按可追踪结果判定”的做法，而不是拿某个平台的回答代表全部效果。若平台能访问页面但回答没有引用，和页面根本无法抓取，处理方向并不相同。判断时至少对比可访问率、索引状态、回答覆盖率、引用准确率、AI引荐点击和有效线索率，效果结论需用自家数据验证。
先把“表现差”说清楚
“表现差”可能指回答没有提到品牌，也可能是引用了旧页面、实体名称混乱、链接打不开，或者用户点击后没有完成目标动作。验收表要把这些情况拆开，记录平台名称、测试问题、回答原文、引用页面、访问时间和页面版本，不能只填一个“好”或“差”。
页面无法访问属于技术问题，页面能打开但没有进入索引范围，处理方向又不同；页面已被访问，回答仍然偏题，则要回到内容结构、实体说明和问题覆盖。这样分层后，项目团队才知道是在修服务器、改页面，还是重写答案所需的上下文。
验收前先建立一份基线
基线不需要追求复杂，先选出业务真实出现的查询，再按品牌词、产品词、场景词和问题词分组。每个查询保留固定写法，并记录测试日期、平台、设备、地区设置和登录状态；这些条件改变后，结果可能无法直接横向比较。
如果暂时没有历史数据，可把当前测试结果标成“起始样本”，不要把一次查询当成稳定结论。项目成员还要统一“有效引用”的定义，例如引用页面能打开、主题确实支持回答、页面中的关键表述没有被断章取义，具体口径由团队写入验收表。
页面能不能被访问，要单独验收
技术验收先看目标页面是否返回正常的HTTP状态、正文是否能在不依赖复杂交互的情况下读取、robots.txt是否限制了不该限制的路径，以及站点地图是否包含需要发现的页面。Google Search Central的《搜索抓取与索引指南》说明了抓取和索引之间的基础关系，可用来区分“页面打不开”“不允许抓取”和“尚未进入索引范围”。
结构化数据也不要当成效果承诺。Schema.org的词汇说明了类型和属性如何表达实体、产品或组织信息，但它不能单独证明AI平台一定会引用页面。验收时应把页面可读正文、标题层级、实体名称、结构化数据与页面实际内容逐项比对，发现标记和正文不一致，就先修正一致性。
回答测试要看引用是否真的帮得上忙
同一组问题应在各平台重复测试，并把结果分成“直接回答”“部分回答”“未回答”“引用不相关页面”四档。每档都要留下回答截图或文本、引用页面标题和测试时间；平台是否展示引用、引用位置如何变化，不能用一次结果推断长期表现。
验收重点不是回答里有没有一个链接，而是链接能否支持对应句子。比如问题问交付范围，引用页却只介绍公司理念，就算页面能打开，也不应计入有效引用。对实体名称、产品名称、服务边界和更新时间较敏感的内容，页面正文应使用稳定且一致的叫法，别让简称、旧名称和新名称互相打架。
一套能落地的验收清单
把技术状态、内容质量和业务结果放进同一张表，但不要混成一个分数。下面这组动作可以作为项目验收主线，每一步都要有负责人、完成日期和对应记录，版本变化后重新跑受影响的问题。
- 记录页面访问结果、HTTP状态、robots.txt限制、站点地图收录情况和页面版本。
- 用固定测试问题在各平台运行，保存回答、引用页面、测试时间、地区与设备条件。
- 按“回答是否切题、引用是否支持原句、实体名称是否一致、页面是否可打开”逐项打标。
- 单独记录AI引荐点击、落地页、有效表单或订单状态，并选定一个主转化事件。
- 按销售周期设定观察窗口，比较有效线索率、订单成本或其他团队已定义的指标；无法通用判断时，需用自家数据验证。
- 平台差异持续存在时，先定位是访问、索引、内容还是归因问题，再只修改一类变量并重新测试。
这套清单的关键是保留版本记录。页面改标题、改实体描述或替换结构化数据后，要标注改动前后内容，否则后续看到结果变化，也难以判断究竟是哪次调整产生了影响。
验收通过后还要看归因闭环
爬虫访问、答案中出现、用户点击、自然搜索进入和完成转化是不同信号，不能合并成一个“AI效果”。AI引荐点击可以作为中间结果，只有点击来源能够识别，并且后续完成了团队指定的主转化事件，才适合进入业务归因。
建议把引荐来源、落地页、会话时间、有效表单或订单状态写入同一记录，并为归因窗口设定统一口径。直接访问可能无法判断来源，品牌词搜索也不应自动算作AI引荐；无法确认的访问单独标记，避免把不清楚的流量算进项目成果。