判断 AI 是否正确理解网页，关键不是看回答是否流畅，而是拿网页中的原文事实、条件限制和更新时间逐项比对。适合用在产品页、服务页、帮助中心和数据说明页：先确认页面能被访问，再抽取核心信息，接着用固定问题测试答案，最后记录引用、错误和页面版本，避免一次回答带来的错觉。
先看 AI 到底错在什么地方
把回答拆成事实、范围、条件和结论四类。事实要能在页面中找到对应句子，范围要与页面限定一致，条件不能被省略，结论则要区分网页原话和 AI 的推断。比如页面写“支持某种格式上传”，回答却扩展成“支持所有格式”，这不是措辞变化，而是范围被放大。
验证时不要只盯着关键词是否出现，还要看主语、时间、对象和否定词。产品名称相近、地区服务不同、旧版功能仍留在页面里，都可能让回答看起来合理，却对应了另一段内容。每个判断都标出网页中的原句位置，方便复盘。
网页内容要先变成可比对的答案
页面内容较长时，先制作一份简短事实表，字段可包括页面主题、适用对象、主要功能、限制条件、价格表达、更新时间和联系入口。这里的表不是给访客看的，而是作为人工基准答案。没有明确写出的内容，先记为“页面未说明”，不要让 AI 自行补齐。
实体名称也要统一。公司名、产品名、服务名和简称分别列出，并注明它们之间是什么关系。一个页面同时出现母公司、子品牌和产品系列时，问题里要明确指向，避免把企业能力、单个产品能力和第三方服务混成一个答案。
页面能被看到，才谈得上理解
用浏览器打开页面只是起点，还要看服务器返回状态、主要正文是否在初始页面中出现，以及 robots.txt 和 sitemap 是否存在明显限制。Google Search Central《搜索抓取与索引指南》说明，抓取与索引涉及页面访问、内容处理等环节；这些机制可以检查，但不能据此推断 AI 一定会引用页面。
动态渲染页面要单独处理。把用户真正看到的正文，与不执行脚本时能够读取到的内容放在一起比较，重点看标题、段落、列表和关键信息是否一致。若核心答案只在交互后出现，就应准备一份清晰的文本版本，并观察不同访问方式得到的页面内容是否相同。
结构化数据能帮忙，但不能替正文答题
Schema.org 的类型和属性定义可以帮助页面表达产品、组织、文章或服务之间的关系，但结构化数据不是正文的替代品。页面正文写的是“提供预约服务”，标记却写成另一种服务类型时，机器读取到的信号就不一致，人工测试也应把两处内容放在一起比较。
检查时只保留页面真实存在的信息，名称、描述、发布日期、作者、价格或评分等内容都要能在页面找到对应表达。结构化数据没有写全，不代表页面一定有问题；写入页面没有出现的内容，才会增加理解偏差。Schema.org《Getting Started with Schema.org》可作为类型和属性含义的参照。
用一组固定问题测试，而不是问一次就下结论
问题集应覆盖不同问法：页面讲什么、适合谁、不适合谁、有哪些限制、某项功能是否存在、信息更新时间是什么。每个问题都绑定一个预期答案和原文依据。测试时保留完整问题、回答、引用片段、访问时间和页面版本，不能只截取看起来有利的一句。
- 打开目标页面，记录页面标题、正文版本和访问时间。
- 摘出事实、限制、实体关系和更新时间，形成基准答案。
- 用直接问法、同义问法和带条件问法分别提问。
- 逐句比较回答与基准答案，标记遗漏、扩大范围、张冠李戴和时间错误。
- 检查回答是否引用目标页面，区分出现于答案、产生点击和后续转化。
- 修改页面后保留旧版记录，再用同一问题集复测。
把一次测试做成可持续的记录
闭环可以从“AI 引荐点击”开始观察，记录引荐来源、落地页、有效表单和成交状态，并只选一个主转化事件。归因窗口要结合自身销售周期设定，无法通用判断点击、成本或转化效果，需用自家数据验证。答案被提到不等于用户点击，点击也不等于订单。
页面改动后，把改动内容、上线时间、问题集版本和回答差异放在同一条记录里。若回答仍遗漏限制条件，先回到页面正文和实体关系；若回答已准确但没有引荐点击，再单独观察渠道标记、落地页和服务器日志。无法归类的访问记为未识别，不要强行归因给某个来源。