要判断 AI 是否真正读懂网页，最稳妥的办法是把页面交给多个具体问题测试，再将回答逐句对回原文、结构化数据和引用出处；如果它把页面主旨、适用边界或实体关系说错，就不能把这次结果当成理解正确。这个方法适合发布前审稿、页面改版后复查，也适合定位抓取、表达和引用环节的问题。
先用一个具体场景来测
假设页面介绍一项软件服务，正文写了服务范围、适用对象和不包含的内容。不要只问“这是什么”，还要分别问“适合谁”“不包含什么”“页面提到的限制是什么”。问题越贴近真实用户，越能看出 AI 是在复述页面，还是把相邻概念拼到了一起。
把 AI 的回答分成三类记录：原文明确写出的内容、根据上下文作出的推断、页面没有出现的补充。第一类要能在页面中找到对应句子，第二类要标注为推断，第三类不能悄悄写成页面结论。这样做的价值在于，错误不再只是一句“感觉不准”，而是能定位到具体段落。
页面本身要让机器读得到
页面能在浏览器打开，不代表抓取程序一定能顺利取得主要内容。根据 Google Search Central《搜索抓取与索引概览》，网页的抓取与索引涉及访问限制、响应状态和页面内容本身。检查时可分别看 robots.txt、页面响应状态、重要文字是否依赖脚本渲染，以及站点地图里的地址是否仍然有效。
如果正文只在登录后出现，或关键信息藏在图片、折叠组件和无法读取的脚本里，AI 测试出现缺漏时，不宜直接归因于模型能力。先用纯文本方式查看页面，再对照浏览器中的完整内容，能判断问题出在访问、渲染还是写法。这里的判断只说明页面可读性，不等同于会被某个平台引用。
索引状态和内容理解要分开看
页面能够被搜索系统发现，与 AI 是否准确概括，是两个不同环节。抓取记录只能说明程序访问过，索引状态只能说明页面进入了某种搜索处理流程，二者都不能直接证明答案会引用页面，更不能证明用户点击后会产生转化。
实际排查可以建立一张简单记录：页面地址、抓取时间、响应状态、索引状态、测试问题、AI回答、错误句子和对应原文。若页面长期无法访问，先处理技术入口；若页面能访问但回答遗漏限制条件，再回到标题、首段、小标题和正文关系上修改，别把所有问题都归到索引环节。
结构化数据能说明什么，不能说明什么
Schema.org 的词汇用于描述网页中的实体、属性和关系，例如文章、产品、组织或作者。它能帮助页面用统一格式表达“这是什么”，但结构化数据不是正文的替代品，也不能单独推出 AI 一定会采用某个结论。标记内容应与页面可见文字保持一致，不能把页面没有写过的服务、身份或评价填进去。
实体一致性也要放在页面整体里看。同一组织的名称、业务范围、作者署名、页面标题和联系信息如果写法频繁变化，机器可能难以判断它们是否指向同一对象。测试时可让 AI 分别回答“页面主体是谁”“提供什么”“服务边界是什么”，再检查这三点是否与正文及结构化数据相互吻合。
这套六步检查能直接照着做
- 记录页面版本、地址和测试日期，保留当时的正文截图或文本副本，避免改版后无法回溯。
- 用概括、适用人群、限制条件、实体关系和引用依据等问题分别提问，每次只改变一个问法。
- 把回答拆成事实、推断和页面外补充，并逐句回到原文寻找依据。
- 查看 robots.txt、响应状态、站点地图、主要正文和结构化数据是否相互一致；机制说明可参考 Google Search Central 与 Schema.org 的相关文档。
- 把错误按访问、索引、表达、实体或引用范围归类，先改动一个变量，再重新测试。
- 记录改前改后的问题、回答、页面版本和人工判定，形成可重复的对照记录。
判断“做对了”不应只看回答听起来是否顺滑，而要看关键事实有没有被替换、限制有没有被省略、页面外内容有没有冒充原文。若团队关心业务结果，还要把 AI 引荐点击、落地页、有效表单和成交状态分开记录；爬虫访问和答案出现只能作为中间信号。
别把一次回答当成最终结论
同一页面在不同问法、不同时间或不同上下文中出现差异，并不能单独证明页面理解有误。应固定一组问题，记录页面版本和回答时间，再观察错误是否持续出现。效果类结论无法用通用规则代替，需用自家查询记录、服务器日志和业务系统数据验证。
如果回答稳定地把服务对象、价格条件或适用边界说错，修改方向应尽量具体：让标题说明主题，让首段交代结论，让小标题承接问题，让限制条件紧跟相关主张。改完只调整相关区域，再复测同一组问题，才能知道变化来自页面改写，而不是提问方式变化。