先给结论：复测不是再看一次 HTTP 200
GEO 页面上线后，真正值得复测的不是“页面现在能不能打开”这一项，而是页面能否沿着一条可解释的证据链继续向外部系统传递：先是技术响应和内容解析，再是站内公开入口发现，然后才是搜索平台抓取、索引、展示，以及 AI 产品是否检索和引用。前一层通过，不能自动推出后一层通过。
本文记录 ZenLeak 在 2026-10-09 的一次固定复测。复测沿用了 2026-10-01 冻结的 28 个公开页面样本，同时对当前 67 个公开页面运行质量审计，并重新检查 14 个关键机器入口。结果支持“当前站内技术状态没有退化”，但不支持“67 个页面都已被搜索引擎收录”，也不支持“页面已经被 AI 稳定引用”。
67/67 通过是 ZenLeak 自己的质量规则结果；28/28 是固定样本的页面级技术结果；10 个 Bing 已发现结果受接口限流影响；Google 查询关闭，AI 引用没有完成固定问题复测。它们不是同一个指标，也不能拼成一个收录结论。
样本与口径：为什么同时保留 28、67、14 和 16
复测最忌讳每次临时换分母。新文章增加后，全站公开页面数量会变化；但如果把新增页面直接塞进旧基线，结果就同时改变了样本和时间，无法判断变化来自网站还是来自统计口径。因此本轮保留四组不同职责的数字：
| 数字 | 对象 | 本轮含义 | 不能推出 |
|---|---|---|---|
| 28 / 28 | 固定公开页面 | 2026-10-01 冻结的 28 个 URL 均返回 200，并满足 canonical、自身可索引、标题、描述和单一 H1 条件。 | 28 个页面已经被搜索平台收录。 |
| 67 / 67 | 当前公开页面质量审计 | 当前 67 个公开页面通过 ZenLeak 的页面质量规则，警告 0 个、错误 0 个。 | 外部平台认可质量、排名或 AI 引用。 |
| 14 / 14 | 关键公开入口 | 预设入口返回预期状态和格式，包含 robots、sitemap、RSS、站点索引、证据索引和机器可读文件等。 | 平台一定会读取这些入口。 |
| 16 / 16 | 声明 User-Agent 的 HTTP 请求 | 4 个路径 × 4 个请求标识均返回 HTTP 200，未观察到状态码级差异。 | 请求真的来自 Google、Bing、OpenAI 或其他平台。 |
这四组分母必须在报告中分开。把 67/67、28/28 和 16/16 相加或平均，会制造一个看似精确、实际没有业务含义的“综合收录分”。复测的价值在于保留对象、时间和判定条件，而不是把所有数字压成一个百分比。
复测方法：先冻结对象，再冻结状态词
本轮复测把可观察事实写成几个互不替代的状态：技术通过、机器入口通过、平台已发现、平台已收录、真实蜘蛛已核验、AI 页面引用。同时保留“未知”“未复测”“限流”和“已关闭”，不把缺失填成 0。
- 固定页面集合。保存完整 URL、发布日期、页面版本和样本来源。固定样本继续使用 28 个 URL，全站审计另行记录当前 67 个公开页面。
- 检查页面技术条件。逐页读取 HTTP 状态、最终 URL、内容类型、canonical、索引指令、标题、描述和 H1；这些字段回答“页面是否具备可访问、可解析的基础”。
- 检查站内发现入口。检查预设机器入口是否返回正确状态、格式和目标记录，防止页面已经生成但 sitemap、站点索引或证据索引没有跟上。
- 单独读取外部平台状态。保存接口原始状态和限制原因，不把站内检查代替百度、Bing 或 Google 的平台状态。
- 保存复测工件。把时间、时区、样本、每 URL 结果、平台字段和解释写入 JSON，正文只做可读说明，并链接到原始记录。
这一顺序的目的，是让读者能够回答“哪一层已经被观察到、哪一层还没有证据”，而不是只得到一个“系统正常”的笼统结论。
技术验收结果：固定页面与全站审计都没有发现退化
固定 28 个页面：页面级条件全部通过
固定样本中的 28 个页面全部返回 HTTP 200，且每页同时满足 canonical 指向自身、允许索引、存在标题、存在描述和具有单一 H1。这里的“技术可索引”是一次检查条件的合取，不是搜索平台已经选择索引的结果。
例如，canonical 自指只能说明页面声明了自己的规范地址；它不能说明平台一定采用这个声明。页面含有标题和描述，只能说明 HTML 中存在这些信号；搜索结果标题和摘要仍可能由平台根据查询和页面内容重新生成。把 HTML 验收字段升级成平台结果，会让报告失去边界。
当前 67 个公开页面：质量审计 67/67
同一快照还对当前公开页面运行了站内质量规则：67 个页面中 67 个通过，警告 0 个，错误 0 个，未检查 0 个。该审计关注页面是否缺少必要元数据、结构是否明显异常、链接和内容入口是否满足本站定义的基础规则。
“截至 2026-10-09，67 个公开页面通过 ZenLeak 内部质量规则；固定的 28 个页面技术检查也全部通过。”不要说成“搜索引擎已收录 67 个页面”或“AI 已经认可 67 个页面”。后两句话需要外部平台或固定 AI 观察证据。
机器入口复测：14/14 与 16/16 分别说明什么
14/14 是关键入口健康检查，判断站点提供的公开机器入口是否能返回预期内容。16/16 则是一个更窄的交叉请求实验：对首页、/robots.txt、/llms.txt 和 /evidence-index.json 这 4 个路径，分别使用 ZenLeak 研究客户端、带有 Googlebot 标签的字符串、带有 bingbot 标签的字符串和 ChatGPT-User 标签发起请求。
| 检查 | 实际做法 | 结果 | 证据边界 |
|---|---|---|---|
| 关键入口健康 | 检查预定义的 14 个公开入口、状态码、格式和最小结构。 | 14 / 14 | 说明本轮入口响应正常，不说明外部平台已经读取。 |
| 声明 UA 交叉请求 | 4 个公开路径 × 4 个客户端声明，记录每次最终响应。 | 16 / 16 HTTP 200 | 只能说明不同字符串下未观察到状态码阻断。 |
| 真实平台身份 | 需要服务器日志、官方 IP 范围或适用的正反向 DNS 规则。 | 未由本实验确认 | User-Agent 可以被伪造，不能单独证明真实蜘蛛。 |
这也是为什么后台应该把“请求标识”和“蜘蛛身份核验”设计成两列。前者来自请求头，后者来自独立证据。若把所有包含 baiduspider、Googlebot 或 bingbot 的日志直接算成真实蜘蛛，后台的蜘蛛数量会被自报身份污染，也会误导后续的收录诊断。
平台观察：本轮知道什么，不知道什么
Bing：10 个已发现，不是完整收录结果
本轮后台确实调用了 Bing Webmaster 接口，但接口受到限流，只取得 10 个页面的“已发现”结果。原始记录同时写明本轮检查对象为当前 67 个公开页面，因此 10 个已发现结果不能外推为 67 个页面全部已发现，也不能外推为固定 28 个页面全部已收录。
“已发现”只表示平台知道 URL 或在该接口语义下识别到 URL。它和抓取、进入索引、查询展示、点击以及 AI 引用仍是不同状态。下次复测应该继续使用同一批 URL，在限流解除后补齐缺失状态，而不是把剩余 57 个页面标成未发现。
Google：查询关闭，不等于未收录
Google Search Console 查询按站点设置保持关闭，本轮没有请求 Google API。原因是生产环境的服务器网络条件不足以稳定完成该查询。关闭只说明 ZenLeak 没有取得这一平台的本轮数据，不说明 Google 已收录或未收录页面。
还要区分两条网络方向：服务器访问 Google 管理接口失败，不等于 Googlebot 访问不了 ZenLeak；同样，浏览器能打开 Google 页面，也不等于服务器端 API 凭据、出口网络和权限全部正常。没有平台级证据时，最可靠的状态词是“未查询”或“已关闭”。
百度：提交台账不能替代收录核验
百度主动提交接口的接收记录，只能说明一次提交请求进入接口处理流程。它不能单独证明百度已经抓取 URL、页面通过质量判断、进入索引或在某个查询中展示。服务器日志里出现自报百度 User-Agent 也不能替代真实身份核验，尤其是同一个 IP 在短时间内访问敏感路径时，更应该先做反向 DNS、正向回验和请求行为分析。
AI 平台：没有固定问题，就没有可判定的“引用率”
本轮没有完成针对固定 URL 的 AI 问题集复测，因此 ZenLeak 页面是否被检索、是否作为来源出现、来源是否支持回答、回答是否完整，均保持未知。品牌名称在某个回答中出现，不能自动升级成页面引用；页面 URL 出现在来源卡片中，也还需要核对来源正文是否真的支持对应声明。
如何读这次结果：把“通过”放回它所属的层级
| 层级 | 本轮状态 | 可以说 | 不能说 |
|---|---|---|---|
| 页面响应 | 通过 | 固定样本页面能返回并解析，未发现本轮技术阻断。 | 搜索平台已经抓取。 |
| 站内发现 | 通过 | 公开入口能够指向页面，站内发布链路没有明显断点。 | 外部平台一定读取入口。 |
| 真实抓取 | 未由本轮 UA 实验确认 | 声明字符串下没有观察到响应阻断。 | 这些请求就是 Googlebot、bingbot 或 ChatGPT-User。 |
| 搜索发现 | Bing 部分已知 | 接口返回的 10 个结果在本轮被标记为已发现，且存在限流。 | 全部页面都已发现或已收录。 |
| 搜索收录 | 未完整取得 | 本轮没有足够平台级数据形成全站收录判断。 | 把技术通过或提交成功写成已收录。 |
| AI 引用 | 未知 | 下一轮需要用固定平台、问题和来源记录完成判断。 | 把品牌提及或一次回答当成稳定页面引用。 |
这个分层不是文字游戏。它直接决定下一步动作：技术不通过，先修页面；机器入口不通过，先修发布链路；平台接口限流，补查询而不是改写结论；AI 结果未知，建立固定问题集而不是凭印象说“模型喜欢”或“不喜欢”。
如何复跑：一份可交给团队的最小协议
- 记录版本。保存 Git 提交或部署时间、站点域名、页面 URL、内容版本、时区和复测发起时间。
- 固定页面。沿用历史样本进行纵向比较；新增页面另建新增样本，不要回写历史分母。
- 固定字段。至少保存 HTTP 状态、最终 URL、canonical、robots、标题、描述、H1、内容类型和检查错误。
- 固定入口。检查 robots、sitemap、RSS、站点索引、搜索索引、证据索引和 llms 相关文件，并记录入口是否真的包含目标 URL。
- 固定平台口径。百度的提交、Bing 的 discovered、Google 的 URL 检查和真实蜘蛛核验分列保存，接口失败时写明失败原因。
- 固定 AI 问题。冻结平台、语言、地区、登录状态、联网模式、问题原文、回答全文、来源链接和观察时间，不能只保存“出现/没出现”。
- 固定结论词。使用“通过、失败、未知、未查询、限流、关闭、待人工核验”，不要用“0”覆盖没有执行的数据。
本轮可复核工件已经公开：上线就绪复测 JSON、机器入口复测 JSON、上线就绪实验记录和机器入口实验记录。下一次固定复测日期为 2026-10-16；如果某个平台在此之前恢复可查询，可以单独补充平台记录，但不要修改本轮已保存的原始工件。
常见问题
67/67 通过是不是说明网站已经做好 SEO 了？
它说明当前 67 个公开页面通过 ZenLeak 的内部质量规则。SEO 还包括搜索平台处理、查询展示、用户点击和长期内容质量；内部规则通过不能替代这些外部结果。
28/28 技术可索引是否等于 28 个页面都收录？
不等于。技术可索引只表示本轮页面满足可访问、规范地址、索引指令和基础内容条件。收录需要对应搜索平台提供可以复核的状态。
16/16 的 Googlebot、bingbot 请求能证明蜘蛛来过吗？
不能。实验只是把不同 User-Agent 字符串发给服务器，验证服务器是否按字符串返回不同状态。真实身份需要服务器日志、官方 IP 范围或正反向 DNS 等独立证据。
Bing 只有 10 个已发现，是不是其他页面都没被发现？
不能这样推断。本轮接口限流只取得 10 个结果，剩余页面状态缺失，正确状态是未完成或未知，不是未发现。
为什么 AI 引用状态不直接记成 0？
因为本轮没有用预先固定的问题和来源证据包完成这项观察。没有执行或证据不足时写 0，会把“未测量”伪装成“已测量且没有发生”。
上线后复测清单
- 固定页面 URL、内容版本、观察时间和时区。
- 把固定样本、当前全站审计、关键入口检查和 UA 交叉请求分开统计。
- 逐页检查 HTTP、最终 URL、canonical、robots、标题、描述、H1 和正文可解析性。
- 检查 sitemap、RSS、站点索引、搜索索引、证据索引和 llms 入口是否包含目标页。
- 将自报 User-Agent 与真实蜘蛛核验结果分开保存。
- 将百度提交、Bing 已发现、搜索收录、排名和 AI 引用分成不同字段。
- 接口限流、功能关闭、未查询和未完成都保留为状态，不用 0 替代。
- 公开 JSON 原始工件、可读解释、数据限制和下一次复测日期。
结论边界：这次复测没有回答什么
这次复测回答了“ZenLeak 的页面和站内公开入口在 2026-10-09 是否出现可观察的技术退化”，也记录了 Bing 查询受限、Google 查询关闭以及 AI 引用尚未完成。它没有回答百度、Bing、Google 当前到底收录了多少页面，没有回答哪些页面排名第一，也没有回答某个 AI 平台是否会长期引用 ZenLeak。
这样的限制不是报告缺陷，而是证据边界。下一轮要提升结论强度，应该补齐对应平台的逐 URL 状态、完成真实蜘蛛身份核验，并按照固定问题协议采集 AI 的完整回答和来源链接。只要这几层仍未完成，最专业的表达就是把它们保留为未知。