服务器日志里出现了一个爬虫，请求成功，品牌页面被抓取了。
这能说明访问情况，但尚不能回答：返回了什么内容、描述哪个品牌、事实是否最新，以及这些信息有没有出现在回答里。
把问题分开，团队才能做出具体改进，而不是庆祝一个含义尚不明确的数字。
页面被获取，是信息旅程的起点。还应检查读者究竟能从中了解什么。
一次抓取说明什么？
请求日志记录了与服务器的交互。解释日志，需要看请求地址、响应状态、时间，以及请求者身份是否得到可靠确认。
成功响应也可能只是登录页、空的应用外壳，或以成功状态返回的错误消息。因此，应查看实际内容。
| 观察结果 | 可以支持的判断 | 仍未解决的问题 |
|---|---|---|
| 请求到达服务器 | 端点收到流量 | 请求者身份和目的 |
| 已验证的爬虫获取档案 | 该爬虫访问了地址 | 是否保留或使用事实 |
| 响应含有品牌记录 | 该响应提供了文字 | 系统是否正确理解 |
| 回答链接到档案 | 在这次回答中发生了引用 | 每个陈述是否有依据、推荐是否改变 |
报告中应区分这些观察，每项都回答一个不同的问题。
无需交互也能读到内容吗？
像读者一样打开页面，再查看服务器返回的内容。名称、简介、核心事实和来源链接是否可读？重要部分是否需要点击、登录或额外请求？
不同系统处理网站的方式不同。Google 的 JavaScript SEO 文档将抓取、渲染和索引列为不同阶段。这提醒我们，应测试实际可获得的内容，不要假定所有读者都像浏览器一样工作。
参考页面把核心事实放进初始 HTML，可以减少对交互行为的依赖，但仍不能据此证明某个 AI 服务将怎样使用这些内容。
品牌身份明确吗？
文字可以读到，也可能描述错了对象。
假设有两个互不相关的 Aster：一个在英国销售自行车，另一个在加拿大提供会计软件。这些是虚构例子。如果标题只有“Aster”，读者就需要自行区分。
清晰的导语应说明业务类别并链接官网。有来源的经营公司或母公司关系也应明确表达，标识图片本身无法承担这些区分。
集团内部也一样。子公司的产品范围，不应在摘要里悄悄变成母公司的直接业务。
事实一致且仍然有效吗？
对照简介、事实表、时间线和结构化副本。它们应描述相同主体，并保留相同限定。
常见问题包括：
- 简介仍列旧所有者，时间线已记录交易完成。
- 成立日期在一处指公司，另一处指消费品牌。
- 地区产品系列被表述为全球业务。
- 结构化副本省略了页面中的不确定性说明。
即使所有请求都成功，这些仍是编辑问题。从品牌网页到品牌知识介绍了如何明确这些区别。
怎样检查理解是否准确？
用一小组事实问题检查记录：品牌是什么？谁经营它？这句话适用于哪个市场？归属判断由什么支持？
先直接阅读页面作答；如果还测试助手，就记录回答、链接、日期和测试条件。逐项对照来源。一次正确回答是一次观察，不能保证未来所有输出。
常见问题
爬虫流量增加，是否意味着品牌被理解得更准确？
流量衡量请求，不直接衡量理解、事实准确性、引用或推荐。这些结果需要分别检查。
结构化数据能解决身份含糊吗？
它可以明确表达身份和关系，但错误或不一致的字段仍是错误信息。需要对照可见记录及来源复核。
应先修什么？
先确认响应包含可读的核心事实，再修正身份不清、缺乏依据的表述和矛盾。如果关心回答准确性，还应另外测量。
先读记录，再读日志
Brand Wiki以可访问、有来源的品牌档案为基础。评估档案时，看读者能够确定和核实什么；访问日志则提供传递情况的证据。