网站收录查询工具，源站正常而边缘节点异常时应保留哪些证据
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /4d55bd126c46.html
📄
网站收录查询工具，源站正常而边缘节点异常时应保留哪些证据
先给结论：此时最该保留的不是“收录量截图”，而是能证明源站响应与边缘响应差异的原始记录——同一 URL 在源站直连和边缘路径下的状态码、响应头、响应体摘要，以及查询工具返回的原始字段。因为这类异常往往只影响部分节点或部分地区，单看查询工具的总量数字无法区分“抓取路径被边缘层改写”和“收录真的掉了”。保留这些证据后，你才能判断是继续观察、改写边缘规则，还是暂时退出该缓存策略。
先固定一组可比对的样本，而不是全站都查
源站正常、边缘异常的场景，通常表现为：直连源站返回 200，走边缘节点却返回 403、503，或者返回一个内容被替换的页面。此时不要立刻全站扫描，而是先挑一组可复现的样本，覆盖不同页面类型，例如首页、栏目页、详情页各取若干条，并记录每条 URL 的完整路径和查询参数。
取样时明确前提：这些样本必须能稳定复现异常。如果边缘节点是轮询的，同一 URL 多次请求可能落到不同节点，那就要记录每次请求命中的节点标识（如果响应头里有）或至少记录请求时间与结果。否则你拿到的“异常”可能只是某一次网络抖动，不能作为后续决策依据。
这一步的实际动作是：用固定 UA 分别请求源站直连地址和边缘地址，把两次响应并排保存。结果会直接影响下一步——如果只有边缘路径异常，问题范围就锁定在边缘层；如果源站直连也开始异常，那就不是边缘节点的问题，后续证据方向要改。
要保留的响应证据，按能回答的问题分层
证据不是越多越好，而是每一层能回答一个具体问题。建议按下面三类保存，且保留原始文本，不要只留截图。
- 状态与响应头：记录状态码、
Content-Type、Cache-Control、X-Cache、Age、Vary、Server等字段。它们能回答“边缘是否返回了缓存副本”“缓存是否过期”“是否按 UA 或 Cookie 分流”。 - 响应体摘要：保存正文开头若干字符或标题文本，用来判断边缘返回的是正常页面、错误页还是被改写过的页面。只存哈希不够，因为你需要看出内容差异。
- 查询工具返回的原始字段：如果工具给出的是“已收录/未收录”二值，同时记录查询时间、查询的 URL 形态（带不带 www、带不带参数）、以及工具是否区分不同搜索引擎。不同工具的判定口径不同，混在一起会误导判断。
这里有一个容易忽略的边界：robots.txt 的抓取限制不等于可靠的索引移除。如果边缘异常期间你顺手改了 robots.txt，之后查询工具显示未收录，你无法分清是边缘异常导致抓取失败，还是 robots 规则本身在起作用。所以证据里要包含 robots.txt 的版本和时间点，避免两种原因纠缠。
日志与查询结果对不上时，先怀疑哪一边
常见情况是：源站日志显示抓取正常，查询工具却显示未收录或收录下降。这时不要直接断定工具失真，也不要直接断定收录掉了。先做一次交叉核对：
- 从源站日志中筛出目标 URL 的抓取记录，看状态码、响应大小、抓取时间。
- 对照边缘响应记录，看同一时间段内边缘是否对抓取 UA 返回了不同结果。
- 再看查询工具返回的是哪个搜索引擎的结果，以及该工具是否只覆盖部分索引。
如果日志显示抓取成功但工具显示未收录，合理解释至少有两种：一是工具索引更新滞后，二是该搜索引擎尚未把抓取结果纳入可查询索引。这两种都不等于你的边缘配置没问题。反过来，如果日志里抓取量骤降，也不能单独证明是边缘异常导致——也可能是抓取预算调整、站点地图变更或 robots 规则变化。所以日志和查询结果要一起看，不能拿单一指标下结论。
保留、改写还是退出：三种取舍的适用前提
保留当前边缘策略：适用于异常只出现在极少数节点、且源站直连始终正常、查询工具结果没有持续恶化的情况。此时保留证据并继续观察，但设定一个复查点，比如固定时间后重新取样同一组 URL。如果复查时异常节点仍在，保留就不再成立。
改写边缘规则：适用于证据显示边缘层对抓取 UA 或特定路径返回了非预期响应，且你能定位到具体规则（如缓存键、UA 分流、回源超时）。改写前先保存当前规则快照和异常样本，改写后用同一组样本复测。复测结果决定下一步：如果边缘响应恢复且查询工具结果随后改善，说明方向正确；如果边缘恢复但工具结果没变，问题可能不在边缘层。
暂时退出该边缘策略：适用于异常范围持续扩大、改写规则成本高于收益，或你无法在合理时间内定位原因。退出的前提是你能回退到源站直连或备用路径，并且回退后仍能保留异常期间的证据。退出不等于问题解决，只是先恢复可抓取状态，后续仍要复盘边缘层为什么异常。
假设一个短例子：某站点边缘节点对不带 Cookie 的请求返回 403，而抓取 UA 恰好不带 Cookie。源站直连正常，查询工具显示部分 URL 未收录。此时保留的证据应包括：同一 URL 带 Cookie 与不带 Cookie 的两次响应、边缘节点标识、查询工具查询时间。如果改写规则允许无 Cookie 请求回源，复测后边缘返回 200，那么下一步就是观察查询工具是否在后续周期内更新；如果没有更新，再查该搜索引擎的抓取日志，而不是继续改边缘规则。
证据保存的格式与复查节奏
保存格式建议用纯文本或结构化字段，避免只留截图。每条记录至少包含：时间、请求 URL、请求路径（源站/边缘）、UA、状态码、关键响应头、响应体摘要、查询工具名称与返回字段。这样做的目的是让后续复查时能直接比对，而不是重新描述一遍现象。
复查节奏取决于异常是否稳定复现。如果稳定复现，可以在改写或退出后立即复测；如果不稳定，就要拉长观察窗口，并记录每次复测的节点和结果。注意：站点地图提交不保证收录，HTTPS 也不保证安全无漏洞或排名，这些与边缘异常无关的因素不要混进证据判断里。不同搜索引擎对同一 URL 的处理可能不同，所以查询工具的结果要按搜索引擎分别记录，不能合并成一个“收录数”。
最后，把证据和决策绑定：保留证据是为了回答“异常是否还在、范围是否扩大、改写是否生效”。如果一组证据无法回答其中任何一个问题，它就不值得继续占用你的排查时间，应该换成能直接区分源站与边缘差异的记录。
