先给结论：GEO 复测报告不是一张“排名成绩单”
GEO 复测报告的任务，是说明页面在指定时间、指定版本和指定条件下，经过了哪些可重复检查，观察到了什么，哪些状态仍然未知。它不是把“页面能打开”“搜索平台发现了 URL”“真实蜘蛛访问过”和“AI 回答引用了页面”加在一起的总分。
同一个页面可以同时满足技术可访问，却没有平台收录状态；可以出现在搜索平台的发现接口，却没有稳定排名；也可以被某次 AI 回答提及，却没有显式链接或准确采用。报告必须保留这些层级之间的间隔，否则读者很容易把过程信号误读成最终效果。
“在 2026-10-18、固定页面样本和当前生产版本下，观察到 28/28 页面技术检查通过；这支持页面可访问和可解析的有限判断，但不证明搜索引擎已收录、获得排名或被 AI 引用。Bing 本轮接口受限，未返回部分保持未知。”
四层证据：先确定你到底在复测什么
一份报告至少要把四个问题拆开。它们可以放在同一份报告里，但不应共享一个模糊的“通过”状态。每层都要有自己的观测单位、来源和限制。
| 证据层 | 回答的问题 | 可以保存什么 | 不能直接推出 |
|---|---|---|---|
| 技术可访问 | 页面和机器入口是否正常返回并可解析？ | HTTP、HTML、canonical、robots、标题、H1、JSON/XML 格式 | 已经收录或有排名 |
| 搜索发现与平台状态 | 平台接口或工具在本次查询中返回了什么？ | 查询时间、接口状态、已发现数量、限流和未返回项 | 缺失项就是未收录 |
| 真实蜘蛛身份 | 日志中的请求能否通过官方规则核验来源？ | 源 IP、UA、PTR、正向 DNS、官方 IP 范围、核验时间 | 访问过就一定会收录 |
| AI 答案引用 | 固定问题下是否提及、链接、采用并准确支持？ | 平台、问题、环境、完整回答、来源 URL、逐条判定 | 一次回答代表长期表现 |
Google 对搜索过程的说明本身就区分抓取、索引和结果呈现，并明确不是每个页面都会通过每一个阶段。GEO 复测进一步把 AI 答案作为单独观察层，是为了避免把搜索流程结果和答案生成结果混成同一个指标。
样本和分母：数字先要能被解释
复测开始前先冻结样本。固定页面样本用于跨轮次比较，全站审计用于发现新增异常，关键入口用于检查机器可读文件，平台接口用于保存外部状态。它们的分母不同，不能把 28 页、73 页和 14 个入口相加成一个“总通过率”。
| 数据集 | 适合回答 | 正确写法 | 错误写法 |
|---|---|---|---|
| 固定页面样本 | 同一批重点页面是否发生技术变化 | 28/28 页面技术检查通过 | 全站 28/28 页面已经收录 |
| 关键入口 | robots、sitemap、RSS、索引文件是否可用 | 14/14 入口状态和格式符合预期 | 14 个入口健康，所以 AI 会引用 |
| 全站质量审计 | 当前公开页面是否触发站内规则异常 | 73/73 通过，0 警告，0 错误 | 内容质量获得搜索平台认证 |
| 平台接口快照 | 本次查询实际拿到了哪些平台结果 | Bing 返回 13/73 已发现，接口受限 | 其余 60 页都未发现 |
对 AI 基准还要使用更细的单位：问题 × 平台 × 轮次 × 环境。没有执行、回答中断、来源区未加载和无法取得完整 URL，都应该保存原因。它们不能被悄悄从分母中删除，也不能自动填成“没有引用”。
记录字段：截图之外还要保存什么
截图适合证明当时界面看到了什么，但截图本身不够支撑后续统计。建议为每次复测建立结构化记录，并把原始结果、人工判定和公开摘要分开保存。至少包括以下字段：
- 范围：实验 ID、URL 清单、页面版本、观察开始和结束时间、时区。
- 请求：请求方法、状态码、最终 URL、Content-Type、响应时间、User-Agent 和重定向。
- 页面：canonical、robots 指令、标题、描述、H1、正文可解析状态和机器入口关系。
- 平台：平台名称、工具或接口、查询时间、地区、语言、登录状态、联网状态和模型信息。
- 答案：问题原文、完整回答、来源区域、完整 URL、截图路径、脱敏方式和页面版本。
- 判定：提及、显式页面引用、内容采用、引用准确、回答完整、未知原因和审核时间。
状态值建议至少区分“通过、失败、未知、未执行、无效和不适用”。其中“未知”表示证据不足，“否”表示检查已经执行且明确没有发生。两者不能使用同一个颜色、同一个数字或同一个统计分母。
计划数 = 固定页面数 × 检查项目数
有效回答数 = 能取得并完成判定的回答数
显式引用率 = 出现目标 URL 的有效回答数 ÷ 有效回答数
准确采用率 = 逐条核验准确的采用回答数 ÷ 内容采用回答数真实案例：2026-10-18 复测数据应该怎样解读
下面的数据来自 ZenLeak 公开的两份复测 JSON。它们是 2026-10-18 的第一方快照，反映当时的生产版本和查询条件；它们不是搜索平台对网站的认证，也没有替代 2026-10-19 到期任务的后续复测。
| 项目 | 观察结果 | 可以支持的判断 | 仍不能推出 |
|---|---|---|---|
| 固定公开页面 | 28/28 HTTP 200，canonical、可索引指令、标题、描述和单个 H1 通过 | 固定样本当时具备技术可访问和基础可解析条件 | 28 页都已被搜索引擎收录 |
| 关键入口 | 14/14 状态码、类型和格式符合预期 | 预设机器入口当时可用 | 平台已经使用这些入口 |
| 全站规则检查 | 73/73 通过，0 警告，0 错误 | 站内自动规则没有发现异常 | 外部平台认可内容质量 |
| Bing 接口 | 13/73 已发现，接口受限 | 当次响应中至少有 13 页返回已发现状态 | 其他页面未发现或已收录 |
| 声明 UA 交叉请求 | 16/16 HTTP 200 | 四种客户端声明下入口可达 | 请求来自真实蜘蛛，或已经抓取和引用 |
这里最重要的不是“通过项很多”，而是每个数字的分母都没有被偷换。13/73 是限流接口的一次返回，不是网站的 Bing 收录率；16/16 是第一方客户端的可达性测试，不是蜘蛛身份认证；73/73 是站内规则结果，不是搜索引擎评分。
原始材料：上线就绪复测 JSON、机器入口复测 JSON。报告应链接到原始文件，而不是只在正文里抄一遍数字。
蜘蛛核验：User-Agent 是候选信号，不是身份证
搜索爬虫可以声明 User-Agent，普通客户端也可以伪装成搜索爬虫。因此日志中出现“Googlebot”“bingbot”或“Baiduspider”时，第一步只能把它标记为候选。真正核验需要结合来源 IP、官方发布的网段或平台规定的正向与反向 DNS 规则，并记录核验时间和结果。
对百度候选请求，通常先对 IP 做反向解析，再对得到的主机名做正向解析，确认解析回原始 IP，并检查主机名后缀是否符合百度公开规则。对 Google、Bing、OpenAI 等平台，也应使用各自官方规则。单独使用 PTR、UA、IP 归属地或“访问了 robots.txt”都不足以完成身份确认。
先记录和分级，再决定是否限流。对未核验但访问正常的请求，不要因为 User-Agent 像蜘蛛就直接加入白名单；对明显扫描敏感路径的请求，可以按路径和频率进行保护，并把状态码、原因和释放记录保存下来。
报告写法：事实、解释和行动分开
高质量报告应让读者知道“看到了什么”和“作者如何解释”不是同一件事。可以使用下面的六段结构：
- 范围：写清日期、时区、生产版本、URL 样本、平台、问题集和排除项。
- 方法：说明请求、解析、平台查询、蜘蛛核验和人工审核分别如何执行。
- 数据质量：列出计划、完成、失败、中断、未知和限流，不只展示成功结果。
- 分层结果：分别报告技术、搜索平台、蜘蛛身份和 AI 引用，不合并成一个总分。
- 限制：说明样本大小、接口限制、平台波动、身份伪装和不能外推的范围。
- 行动：只安排下一轮可以验证的动作，例如补抓取日志、复核接口、冻结问题或补充证据。
“在【时间】、【页面版本】和【复测条件】下，观察到【具体分子 / 分母】。该结果仅支持【有限判断】；由于【限流、样本、平台或证据缺口】，不能推出【收录、排名、AI 引用或因果效果】。下一轮将用【相同条件或明确变化】检查【具体指标】。”
复测流程：发布前回归，发布后分阶段观察
| 阶段 | 动作 | 保存材料 | 不要写成 |
|---|---|---|---|
| T+0 | 冻结页面和问题基线 | 版本、标题、正文摘要、技术入口、问题环境 | 当天没有引用 |
| T+3 / T+7 | 复查可访问、机器入口和日志 | 响应、日志候选、身份核验、异常 | 已经收录 |
| T+14 | 使用同一问题和平台重复观察 | 完整回答、来源、判定、缺失原因 | 一次提及变成稳定引用 |
| T+30 | 对照页面版本和同期变化 | 多轮数据、改动日志、业务事件 | 变化一定由某次改动造成 |
今天发布文章后，不需要因为上线就立刻重复全部平台测试。更稳妥的做法是保存 T+0 基线，按既定窗口复测；只有页面发生实质变化时，才在记录中说明变化并重新安排相关检查。提交接口接收、sitemap 出现和蜘蛛访问都只是发现链中的不同信号。
常见问题
HTTP 200 就说明页面已经被收录了吗？
不是。HTTP 200 只说明本次请求返回了成功响应。收录还涉及平台抓取、处理、索引资格和结果展示，必须使用平台自己的状态或搜索结果证据单独核验。
Bing 接口返回 13/73 应该怎么写？
写成“本次受限查询返回 73 页中的 13 页已发现，未返回页面状态未知”。不要写成“网站只有 13 页被 Bing 收录”，因为限流会造成数据不完整。
声明 Googlebot 的测试返回 200，能证明 Google 来过吗？
不能。这是第一方客户端发送的 User-Agent 字符串。要证明真实来源，需要服务器日志与 Google 官方验证规则相互印证。
AI 提到了品牌但没有 URL，应该记成什么？
可以记为品牌提及；显式页面引用应保持为未知或否，取决于是否完整检查了来源区域。内容采用和引用准确还需要逐句对照页面原文。
复测报告是否应该给网站一个总分？
不建议。总分会掩盖不同分母和未知状态。用分层指标、原始证据和下一轮动作表达结果，更适合复核和长期比较。
发布一份 GEO 复测报告前的清单
- 是否固定了 URL 样本、页面版本、观察时间和时区。
- 是否分别记录技术页面、关键入口、全站审计和平台接口的分母。
- 是否保存了状态码、Content-Type、canonical、robots、标题、描述和 H1。
- 是否把平台限流、关闭、未执行和未知状态明确写出。
- 是否把 User-Agent 候选和真实蜘蛛核验分成两个状态。
- 是否保存问题原文、完整回答、来源区域、完整 URL 和页面版本。
- 是否单独判断品牌提及、页面引用、内容采用、引用准确和回答完整。
- 是否提供原始 JSON、日志或可下载证据，而不是只有截图或摘要。
- 是否同时写出支持的判断、不能推出的结论和下一轮动作。
- 是否避免使用“保证收录”“必然引用”“永久有效”等无法核验的表述。
结论边界：复测不能消除平台不确定性
GEO 复测的价值，不是让搜索引擎或 AI 平台变得可预测，而是让网站团队知道自己究竟测到了什么。把可访问、发现、身份、引用和准确性分开，短期看会让报告出现更多“未知”；长期看，这些未知会告诉你下一步该补日志、补平台证据、补人工回答，还是暂时不要下结论。
可以继续阅读GEO 页面上线后如何复测、搜索收录复测教程、百度蜘蛛身份核验和GEO 效果复盘方法。它们分别展开页面回归、平台状态、蜘蛛身份和长期指标，不应被一个总分替代。