应当把模型波动写入验收报告的备注栏，但不能用一句“模型不稳定”替代验收结论。适用做法是把页面可访问性、抓取索引、实体表达、引用来源和查询结果分别记录，再注明测试时间、模型版本与波动边界，后续用同一套条件复测。
模型波动不等于项目没做成
GEO验收看的是一组可复查的页面和查询表现，不是某次对话里的单句答案。模型可能受到上下文、检索内容、地区、登录状态、服务版本等条件影响，所以报告应区分“页面基础工作已完成”和“回答结果仍需观察”两件事。
如果页面能正常访问，重要内容没有被登录墙挡住，robots.txt没有误拦抓取，站点地图能被读取，结构化数据与正文实体保持一致，这些属于页面状态。至于模型是否引用、引用哪一段、回答顺序如何，应记录为测试观察，不宜直接写成稳定效果。
备注里至少要留下这几类信息
备注不是项目失败的免责栏，而是把复测条件写清楚的地方。建议记录查询日期、使用的模型或平台、提问原文、地区和设备条件、落地页面、回答是否提到实体、是否出现引用，以及与上一轮结果不同的地方。
如果无法确定模型版本，就写明“平台页面未显示版本”，不要自行补写版本号。模型回答出现变化时，可采用“本次查询未复现上一轮引用，页面内容和访问状态未同步变化，需按同条件继续观察”的表述，避免把一次结果扩大成长期结论。
验收结论要分成完成和待观察
一份清楚的报告，更适合把结论拆成三层：页面技术条件、内容与实体表达、模型查询表现。前两层可以依据页面检查结果作出完成判断，后一层则要注明测试样本和时间范围，写成“在本次测试条件下出现”或“尚未稳定复现”。
这样写的好处是，后续即使模型回答发生变化，也能看出是页面状态变化、内容改动，还是测试环境变化。成本、周期、引用次数和线索效果无法通用判断，需用自家数据验证，不能把一次验收结果写成长期承诺。
页面基础项怎么写才不空
抓取与索引部分应记录页面返回状态、robots.txt相关规则、站点地图地址、规范链接、重要页面是否能从站内链接到达。根据 Google Search Central《搜索抓取与索引指南》，抓取和索引涉及页面可访问性、链接发现与内容处理，这些机制可以作为报告中的页面检查依据。
结构化数据则要看类型和属性是否与页面正文相符，不能只因为代码已部署就判定内容获得了某种展示或引用结果。Schema.org的词汇定义可以帮助团队统一实体名称、组织信息、产品或服务信息的表达，但它本身不代表模型一定会采用页面内容。
查询测试别只截一张图
单张截图只能说明某个时点看到了什么，无法说明波动来自哪里。测试记录应保留完整提问、回答时间、模型或平台显示信息、出现的实体、引用页面和未出现的关键信息；若页面后来修改，还要把修改时间与版本号放在同一条记录里。
查询问题也要覆盖用户真实问法，例如品牌名查询、服务能力查询、方案比较和问题排查。每类问题都应单独判断，不要把一个问题得到的回答外推到所有生成式搜索场景。若平台不显示引用来源，就记录“未展示引用”，不把它写成页面没有被使用。
一套能闭环的验收记录
- 记录观察对象：页面访问、抓取状态、索引状态、实体提及、答案引用和AI引荐点击分别建项，不把爬虫访问与用户点击混在一起。
- 记录必要信息：保存提问原文、平台与版本显示、查询时间、落地页、引荐来源、有效表单和订单状态；没有显示的项目标记为未显示。
- 设定归因口径：主转化事件只选一个，例如有效表单，并按实际销售周期设定归因窗口；无法识别的访问单独标为未识别。
- 完整记录一轮测试后再判断：用自家后台、服务器日志和CRM记录交叉查看，不用单次回答推断长期效果。发现异常时，回到页面访问、内容匹配和版本记录逐项排除。
- 报告写明下一步：页面条件异常就修复页面，实体表达不一致就统一名称，模型回答变化但页面未变时保留备注并安排同条件复测。
这套记录的重点不是把每次波动都归因清楚，而是让团队知道观察了什么、依据哪条记录作判断，以及下一次改动后要重新比较什么。
哪些写法容易让验收失真
“模型已经认可”“页面已被大量引用”这类句子缺少测试范围，容易把一次回答误写成稳定结果。更稳妥的写法是注明查询条件、回答时间和可见引用；如果没有引荐点击或转化记录，就不要把答案出现当成线索或订单。
另一个常见问题是把技术部署和效果结果放在同一栏。robots.txt、sitemap和结构化数据属于页面状态；引用、点击和成交属于观察结果，三者需要分栏记录。模型波动备注应放在观察结果旁边，同时保留页面版本和测试记录，方便后续复测。