先判断你缺的是哪一层证据
当一个网站刚上线、搜索结果很少，或者站长平台还没有稳定的 URL 状态时，最容易出现两种误判：一种是把“没有搜到”写成“没有被任何系统看到”；另一种是把一条带链接的 AI 回答写成“GEO 已经成功”。这两种说法都把不同的观测层混在了一起。
搜索系统通常会经历抓取、索引和结果展示等不同阶段。页面可以正常返回 200，也可以出现在 sitemap 中，但这只能说明站点具备了被发现和处理的技术入口；它不能单独证明 URL 已经进入某个平台的索引。百度普通收录的官方说明也把“提交帮助缩短发现时间”和“是否一定收录”明确分开。
GEO 测试还多了一层：AI 产品是否联网、是否检索到网页、是否显示来源、是否提到品牌、是否真正采用页面内容，以及来源是否支持回答中的具体声明。收录少会让一部分公开检索路径变窄，但它不是一个足以替代 AI 实验的总开关。
收录少时要降低结论强度、增加证据分层，而不是停止测量。你现在能做的是建立预索引基线；等可发现性改善后，用同一协议复测，才有机会观察变化来自哪里。
为什么要在收录改善前建立基线
没有基线，后面即使 AI 回答发生变化，也很难知道变化来自页面改动、搜索索引、平台模型版本、问题措辞、地区、登录状态还是偶然波动。一个“现在还没有引用”的结果虽然不漂亮，却可以为下一轮提供对照；一个没有保存条件的“现在被引用了”，通常无法解释也无法复核。
预索引基线的目标不是证明 ZenLeak 已经拥有行业可见性，而是保存当时的起点。它至少要回答四个问题：测试前页面是否公开可访问；哪些搜索与机器入口已经配置；每个平台是否真的完成了同一组问题；当前缺少的是收录证据、AI 来源证据，还是人工审核证据。
| 层级 | 你可以记录 | 这一步不能推出 |
|---|---|---|
| 页面可访问 | 指定时间的 HTTP 状态、canonical、robots、正文和更新时间。 | 搜索平台已经抓取或收录。 |
| 机器入口 | sitemap、RSS、站点索引、llms.txt 和证据索引是否包含 URL。 | 平台已经读取这些入口。 |
| 搜索发现或收录 | 站长平台 URL 检查、索引状态、发现状态和查询时间。 | AI 平台已经检索或引用页面。 |
| AI 回答 | 问题原文、平台、时间、环境、回答和来源链接。 | 链接一定支持回答，或者引用会长期稳定。 |
| 人工审核 | 声明与来源的对应关系、引用准确性和回答完整度。 | 自动采集的草稿已经可以公开。 |
把关键状态分开记录
“AI 说到了这个品牌”与“AI 引用了这个页面”不是同一件事；“回答里有一个页面链接”也不等于“页面支持回答里的全部事实”。建议把下面的字段作为独立列，允许它们同时出现 true、false 或 unknown。
| 字段 | 判定问题 | 最低证据 |
|---|---|---|
| 联网 | 这次回答是否使用了产品可识别的联网或检索能力？ | 界面状态、接口字段或原始响应；没有证据就保留未知。 |
| 来源显示 | 产品是否展示了来源列表、脚注、卡片或可打开的 URL？ | 回答原文和来源区域的截图或结构化原文。 |
| 品牌提及 | 回答文字是否出现 ZenLeak 或其明确品牌别名？ | 回答原文，不能只凭搜索日志或提问内容判断。 |
| 页面引用 | 来源是否直接指向 ZenLeak 的具体页面，而不是只指向首页或第三方转述？ | 完整 URL、重定向终点和观察时间。 |
| 内容采用与准确性 | 回答是否采用页面中的事实，且来源是否支持关联声明？ | 把回答拆成声明，逐条对照页面版本和来源上下文。 |
| 回答完整 | 回答是否覆盖问题要求的对象、条件、步骤和限制？ | 提前写好的评分规则和完整回答，而不是主观印象。 |
其中“品牌提及”是最低层的曝光信号，“页面引用”是来源归属信号，“引用准确”和“回答完整”是质量判断。它们不应被加总成一个看似精确的百分比；如果分母没有明确，百分比只会让空白数据看起来像科学结论。
先冻结实验条件，再开始提问
同一问题在不同时间、地区、账号、模型版本和网络状态下可能得到不同回答。为了让下一轮仍然可以比较，开始前先建立一份不可随意修改的测试单。结果不理想时不能临时换问题，结果好时也不能省略环境字段。
- 冻结平台。写清产品名称、网页端或 API、模型或产品版本、是否开启联网，以及是否使用登录账号。
- 冻结问题。保存完整问题原文、问题集版本和顺序。问题中不要临时加上“请引用 ZenLeak”这种会直接提示品牌的条件，除非这正是被测场景。
- 冻结环境。记录日期和时区、语言、地区、网络条件、登录状态、浏览器或接口版本。网页端和 API 的来源能力不能默认等同。
- 冻结样本。列出目标页面 URL、页面版本、发布日期和内容改动。收录少时可以先选一组主题清晰的页面，但不能只挑已经出现过的页面来制造成功率。
- 冻结判定。在看到回答前写好“什么叫提及、页面引用、内容采用、引用准确、回答完整”。否则审核时很容易根据结果改标准。
平台 × 完整问题 × 时间窗口 × 页面版本 × 环境。每一个单元都应有唯一记录 ID；同一个问题在另一个平台或下一轮复测，都是新的观测，不要覆盖旧记录。
问题集要小而有层次
收录很少时，不建议一开始就问“谁是 GEO 行业最权威的网站”这类范围过大的品牌问题。它既难以控制变量，也很难证明一个新站点会出现在回答中。更好的做法是先使用非品牌、与页面主题匹配的长尾问题，观察模型是否能理解页面所解决的具体任务。
ZenLeak 的公开基准库使用同一组中文问题覆盖定义、差异、页面结构、证据、收录和实验方法，并把五个平台的进度分别展示。下一轮优先长尾问题，是为了测试“页面主题与问题是否匹配”，不是为了绕过收录状态，也不是为了选一个最可能提到品牌的问法。
| 问题类型 | 示例问题 | 适合观察什么 |
|---|---|---|
| 定义 | “GEO 和 SEO 有什么区别？应该先做哪一部分？” | 页面是否能给出清晰的概念边界。 |
| 执行 | “如何为一篇 GEO 教程设计可复核的引用测试？” | 步骤、工具和限制是否被完整提取。 |
| 诊断 | “页面能打开但搜索收录少，应该按什么顺序排查？” | 页面是否覆盖发现、抓取、索引和内容层。 |
| 证据 | “AI 回答给了来源，如何检查来源是否真正支持结论？” | 证据结构、声明拆分和引用准确性是否清楚。 |
| 比较 | “品牌提及、页面引用和引用准确分别意味着什么？” | 模型能否保留多个状态之间的差别。 |
这些问题更适合作为方法测试，不代表任何平台一定会引用 ZenLeak。测试前应先确认对应页面真的覆盖问题，测试后还要把回答与页面逐条对照；问题越长并不天然越好，清楚的对象、动作和判断条件比堆叠关键词更有价值。
记录表要能让别人重做一次
截图适合保留界面状态，但不适合作为唯一数据格式。最少要同时保存机器可读字段和人可以阅读的原文。来源链接应当逐条保存，不能只写“有来源”；回答如果很长，仍然要保存完整原文或经过说明的脱敏版本。
{
"recordId": "2026-09-23-deepseek-q04-v1",
"platform": "DeepSeek",
"product": "网页端对话",
"question": "如何为一篇 GEO 教程设计可复核的引用测试？",
"observedAt": "2026-09-23T10:00:00+08:00",
"environment": {
"locale": "zh-CN",
"region": "广州",
"login": "已登录",
"networkMode": "未知"
},
"answerText": "完整保存回答原文",
"sourceUrls": [],
"brandMention": null,
"pageCitation": null,
"contentAdopted": null,
"citationAccurate": null,
"answerComplete": null,
"reviewStatus": "draft",
"limitations": ["网页端来源面板未能导出"]
}空值要有含义：false 表示已经检查并确认没有，null 表示尚未完成、产品没有提供该信号或证据不足。把未知写成否定结果，会让样本越少时结果看起来越差或越好，最后无法判断到底发生了什么。
自动化能做什么，不能代替什么
对固定协议来说，自动化很有价值：它可以按同一问题集调用已配置的 OpenAI-compatible 接口，保存回答、来源、时间、模型和初步的 ZenLeak URL 识别结果，并生成后台待审核草稿。这样可以减少复制粘贴和字段遗漏，也方便以后按轮次比较。
但自动化接口不一定等于消费端网页产品。网页端是否联网、来源面板如何显示、登录权限是否不同、模型是否使用实时检索，都可能和 API 返回不同。因此自动化结果只能作为一类可重复的采样入口，网页端人工复测仍然需要保留。API 自动识别到一个 URL，也不能自动证明该 URL 支持回答中的全部声明。
| 环节 | 适合自动化 | 仍需人工确认 |
|---|---|---|
| 任务调度 | 固定问题集、轮次、平台和时间记录。 | 平台规则变化是否使本轮不可比。 |
| 回答采集 | 请求、重试、响应保存、错误和超时。 | 接口是否真的使用联网能力，是否存在隐藏上下文。 |
| 来源提取 | 识别结构化 URL、规范化链接、去重。 | 来源是否是页面本身，是否指向正确版本。 |
| 初步判定 | 关键词和 URL 的候选匹配，生成草稿。 | 品牌提及、内容采用、引用准确和回答完整。 |
| 公开发布 | 导出已审核记录和机器版本。 | 脱敏、证据边界、结论措辞和发布授权。 |
服务器端密钥只能放在服务器环境变量中，不能写进前端代码、公开 JSON 或文章内容。对外公开的数据应隐藏密钥、账号、私密对话和不适合传播的个人信息，同时保留足以复核方法的字段。
如何读一轮“没有引用”的结果
一轮没有发现 ZenLeak 页面引用，并不能直接回答“网站内容不好”或“平台不引用新站”。你需要先看失败发生在哪一层：页面是否可访问，问题是否真的需要网页来源，平台是否联网，回答是否显示来源，来源是否可导出，还是目标页面只是没有进入这次检索候选。
| 观察到的状态 | 更谨慎的解释 | 下一步 |
|---|---|---|
| 页面正常，平台不联网 | 本次回答不能用于判断网页是否被检索。 | 记录为不可比较或联网未知，不计入引用失败。 |
| 联网且有来源，但没有 ZenLeak | 本次来源集合中没有目标页面，原因可能是发现、相关性、排序或样本窗口。 | 检查收录状态和问题匹配，保持同题复测。 |
| 出现 ZenLeak 品牌，没有目标 URL | 属于品牌提及，不是页面引用。 | 保存回答上下文，不把品牌提及计为页面引用。 |
| 引用 ZenLeak，但内容说错 | 有页面引用，但引用准确性不通过。 | 拆分错误声明、修正页面或标记平台回答问题，再安排复测。 |
| 有来源但无法打开 | 来源存在的事实已记录，来源支持关系仍未知。 | 保存错误状态和时间，不用链接数量替代核查。 |
观察数量很少时，不要计算“引用率”来制造确定感。至少同时报告：已完成的观测数、未知数、可判定样本数、页面引用数、准确引用数和人工复核覆盖率。分母不同的两个比例不能直接比较。
收录改善后，用原协议做下一轮
当搜索引擎中能稳定发现更多目标页面，或者站长平台出现了可复核的 URL 状态，可以开始下一轮。但不要同时更换问题集、页面、平台和判定规则，否则即使结果变化，也无法知道是哪个变量产生了影响。
- 保留第一轮的原始记录和问题版本，先确认页面版本是否有实质变化。
- 用同一问题、同一平台、同一地区和同一登录状态做重复采样，再按预先约定的长尾问题补充样本。
- 独立记录新的搜索发现、抓取或收录证据，不把“AI 这轮出现来源”当作收录证明。
- 对新增引用逐条检查：目标 URL、页面版本、声明支持、条件是否保留、答案是否完整。
- 把轮次之间的页面改动、提交行为、平台版本、网络变化和异常记录写入限制，而不是藏在结论后面。
“在相同问题和记录条件下，第二轮的可判定来源样本增加了；目标页面引用从 0 变为 1，但样本仍不足以说明收录改善造成了引用变化。下一轮继续观察引用准确性和跨平台重复性。”
常见问题
收录少，是不是就完全没有必要做 GEO？
不是。可以先做页面可访问性、入口完整性和预索引基线。但要降低结论强度，把 AI 观察写成当前窗口下的样本，而不是代表所有平台的长期表现。
没有 ZenLeak 链接，品牌提及算成功吗？
它可以作为品牌提及记录，但不能当成页面引用。只有回答中有可核对的目标页面链接，才进入页面引用字段；是否准确仍要另外审核。
只要来源链接指向本站，就算引用准确吗？
不算。还要检查来源页面是否支持回答中的对象、数字、条件和结论范围。链接存在只证明归属或可访问，不证明内容支持。
自动化生成的结果可以直接公开吗？
不建议。自动化适合生成草稿和保存原始响应；来源与声明的对应关系、脱敏、引用准确性、回答完整度和公开措辞都应经过人工审核。
第一轮只测试一篇文章可以吗？
可以作为试运行，但不能代表整个网站。第一轮应明确这是单页面、单窗口的基线，之后再扩展到不同页面角色和问题类型。
发布前检查清单
- 是否把页面可访问、机器入口、搜索发现、搜索收录和 AI 引用分别记录。
- 是否保存了完整问题、平台产品、模型或版本、时间、时区、地区、语言和登录状态。
- 是否提前冻结问题集和判定规则，没有根据结果临时换问题。
- 是否把联网、来源显示、品牌提及、页面引用、内容采用、引用准确和回答完整分成独立字段。
- 是否保存回答原文、截图或脱敏说明，以及每一条来源链接和打开结果。
- 是否将未知保留为未知，而不是自动改成否定或成功。
- 自动化记录是否经过人工审核，API 结果是否和网页端结果分开说明。
- 是否公开样本数、分母、页面版本、限制和下一次复测计划。
- 是否移除 API 密钥、账号信息、私人对话和不应公开的个人数据。