案例背景：为什么上线检查需要成为公开记录

ZenLeak 在主域名、HTTPS、教程结构、证据索引和管理后台基本完成后，需要回答一个更具体的问题：当前公开页面是否具备被搜索系统发现、访问、解析和进入索引流程的基础条件？如果只写一句“网站已优化完成”，读者无法知道检查了哪些 URL、用了什么口径，也无法在下次更新时比较变化。

因此，本轮把 2026-09-17 的生产状态冻结为基线。样本来自当时站点索引中的 28 个公开页面，后台、登录页和管理 API 不进入公开内容样本。检查覆盖页面级技术条件、Bing 发现状态、关键机器入口和站内质量规则。

案例边界

这是上线就绪与平台发现基线，不是排名实验，也不是 AI 引用实验。Google 接口因生产服务器网络不可达而关闭，本案例不会用 Bing 或本地结果替代 Google 数据。

基线之前已经具备什么

  • 正式域名统一为 https://zenleak.cn，HTTP 与非正式主机归一到正式地址。
  • 教程具有标题、描述、canonical、结构化数据、来源和更新时间。
  • 站点提供 robots、sitemap、RSS、llms.txt、站点索引和证据索引。
  • 后台能执行页面质量、站点健康和搜索平台状态检查。
  • Google 查询支持手动关闭，缺失平台数据不会显示成已通过。

这些功能是测量工具，而不是结果本身。只有对明确样本运行并记录后，才能形成基线。

2026-09-17 基线数据

指标结果本案例中的定义不能推出
技术可索引28 / 28页面具备正常响应、允许索引、规范地址和可解析基础内容。搜索引擎已经收入索引。
Bing 已发现28 / 28Bing Webmaster 接口在检查时返回页面已发现状态。稳定排名、展示、点击或 AI 引用。
关键入口健康14 / 14预设页面与机器入口返回预期状态和格式。所有网络、地区和客户端永远可用。
页面质量规则28 / 2828 个样本通过站内 SEO 与内容结构规则。外部权威性、读者满意度或平台质量认证。
待处理异常0本轮自动检查未留下已识别且未处理的异常。未知平台状态都已解决。
Google 状态未查询服务器无法稳定访问 Google 接口，功能主动关闭。未收录或已收录。
AI 引用未测试本轮没有向 AI 答案产品运行固定问题集。提及、链接、采用或准确度表现。

完整结构化记录发布在上线就绪基线实验页，同时提供 JSON 与 Markdown。案例页解释决策过程，实验页保存指标、方法、限制和复核时间，两者职责不同。

这轮检查是怎么完成的

1. 冻结公开 URL 样本

样本从站点结构生成，而不是只挑表现好的页面。教程、栏目、案例、资源与信任入口进入样本；后台与 API 因明确设置为私有和 noindex 被排除。样本总数、每条路径和检查时间一起保存，下一轮才能对同一对象复测。

2. 检查页面级技术资格

对每个页面核对 HTTP 响应、标题、描述、唯一 H1、canonical、robots 指令、基础结构和可解析正文。这里使用“技术可索引”而不是“已收录”，因为站内检查无权替平台做索引选择；Google Search Central 对搜索工作流程的说明也明确区分抓取、索引和结果呈现阶段。

3. 单独读取平台发现状态

Bing 使用已配置的 Webmaster 接口逐页查询，并通过队列控制调用频率。系统参考 Bing Webmaster Tools 的 URL Inspection 官方说明保留结果字段的原始含义，只记录“已发现”，不自行升级为“已索引”。Google 服务账号文件虽已正确保管，但生产网络无法稳定到达接口，因此后台使用管理员开关关闭查询，页面状态保留为未配置或禁用语义，而不是伪造结果。

4. 检查 14 个关键入口

健康检查覆盖首页、robots.txt、sitemap index、具体 sitemap、llms.txt、llms-full.txt、RSS、站点索引、证据索引、单篇证据 JSON、单篇证据 Markdown、搜索索引、Pagefind 脚本和站点图标。每个入口同时检查响应状态、内容类型和最小结构。

5. 保存限制与后续动作

记录明确写入单次快照、平台范围、Google 缺失和未进行 AI 测试等限制，并安排 2026-10-01 复核。这样，下次数字变化时可以判断是样本增加、技术退化、平台状态变化，还是检测口径改变。

额外的机器入口响应检查

同日还对首页、robots.txt、llms.txt 和 evidence-index.json 使用四种 User-Agent 字符串执行 16 个请求，16 个均返回 200。这只说明未观察到状态码级差异。测试客户端不是对应平台的真实爬虫，因此记录没有把结果解释为真实抓取。详情见机器入口响应记录。

这次基线最重要的五个判断

判断一：满分首先是“量表内通过”

28/28 和 14/14 看起来完整，但分母来自预先定义的样本与规则。它们说明这套量表内没有失败项，不代表没有未覆盖的问题。公开分母、规则和排除项，比只展示一个 100 分更重要。

判断二：缺失数据必须保持缺失

Google 网络不可达是一个基础设施限制。正确处理是关闭功能、解释原因并保留未知状态，而不是用本地浏览器、Bing 状态或技术检查推断 Google 结果。空值不是 0，也不是通过。

判断三：平台发现与平台索引不是同义词

Bing 返回已发现，说明平台知道 URL。它没有自动证明页面进入稳定索引，更不能证明某个查询会展示。后台和公开记录使用原状态名称，可以减少汇报过程中逐层夸大。

判断四：机器可读入口也需要健康检查

sitemap 或 JSON 文件存在不等于内容有效。检查要验证格式、关键字段、记录数、私有路径泄漏和更新时间。证据索引还应核对声明数与记录数，避免页面增加后机器入口悄悄落后。

判断五：基线的价值在于下一次比较

单次检查只能说明一个时点。真正有用的是固定 URL 集、字段和方法，在内容扩展、服务器调整或平台变化后复测。ZenLeak 下一阶段的 AI 引用面板已经公开 12 个问题，但尚未发布结果；这比先写“引用率提升”再补实验更可信。

下一轮如何扩展

  • 将新增的六篇教程和三条实验记录纳入页面与机器入口样本。
  • 保持 Google 开关状态透明；网络条件恢复后单独建立 Google 基线。
  • 按固定问题面板运行至少两个相隔 7 天以上的 AI 答案观察窗口。
  • 保存新增页面首次被发现、抓取与平台报告状态的时间，而不是只看最终状态。
  • 对服务器日志中的真实爬虫请求使用官方方法核验身份。

常见问题

28/28 技术可索引是否等于 28 个页面都收录了？

不等于。它表示本轮没有发现明显技术阻断。是否进入索引应读取具体平台证据，且不同平台可能给出不同结果。

Bing 已发现为什么不直接写 Bing 已收录？

因为平台返回字段与“稳定进入搜索索引”不是同一承诺。公开记录保留原始语义，避免把发现、抓取、索引和展示合并。

Google 不可达会影响网站被 Google 抓取吗？

本案例中的“不可达”指服务器主动调用 Google 管理接口失败，不自动等于 Googlebot 无法访问网站。两条网络方向和证据不同，需要分别验证。

为什么现在就公开进行中的 AI 实验？

预先公开问题与判定标准可以减少结果出现后挑选有利样本。进行中页面只说明协议已建立，不提前展示或暗示结果。

复用这套基线的清单

  • 先冻结完整 URL 样本，并写明纳入与排除规则。
  • 为技术可访问、可索引、平台发现、已索引、排名和 AI 引用分别命名。
  • 每个指标是否包含分母、日期、数据来源和判定口径。
  • 平台接口失败或关闭时，是否保留未知状态而不是填 0 或通过。
  • robots、sitemap、RSS、站点索引和证据记录是否作为独立入口检查。
  • 自动质量分是否公开量表边界，不把规则通过当成外部认证。
  • User-Agent 测试是否明确不能证明真实爬虫身份。
  • 结果是否同时提供人类可读页面和结构化下载。
  • 是否写明不能由本轮数据推出的结论。
  • 是否确定下一次复核日期，并尽量保持样本与方法一致。