收录批量查询，错误只在特定时段出现时怎样捕捉短暂证据
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /dc696630b6cb.html
📄
收录批量查询，错误只在特定时段出现时怎样捕捉短暂证据
收录批量查询的结果如果在某个时段集中报错，而在其他时段恢复正常，问题往往不在查询代码本身，而在那个时段才出现的中间环节。要抓住它，不能靠事后重跑，必须在错误发生的当下留下可复核的原始记录，再用两个解释去对照这些记录。
先接受一个反直觉现象：错误可能“查不出来”
很多人的第一反应是重跑一次批量查询。如果重跑成功，就判断问题已经消失。但短暂错误最常见的特征恰恰是：它只在特定时段触发，重跑时窗口已经关闭，于是你拿到的是“正常”结果，而不是证据。
更麻烦的是，收录批量查询通常同时经过多个环节：取待查 URL 列表、发起请求、接收响应、解析状态、写入结果。任何一环在特定时段变慢或受限，都可能表现为“查询失败”，但根因完全不同。如果只记录最终成功或失败，你无法区分是哪一环出了问题。
因此第一步不是修复，而是把“失败”拆成可观察的阶段，并让每个阶段都留下时间戳。没有时间戳，就无法判断错误是否与某个时段绑定。
两个解释：时段性限流，还是数据源在此时段变化
面对“只在特定时段出错”，通常有两个成立条件不同的解释。
解释一：外部请求在此时段被限流或降速。 成立条件是错误与请求频率、并发数或时段高度相关，且降低并发后错误减少。典型证据是响应码集中在某几类、响应时间在错误前明显拉长、同一批 URL 在低并发时段可以正常返回。
解释二：被查询的数据源本身在此时段更新或不稳定。 成立条件是错误只出现在特定 URL 子集，而这些 URL 恰好属于同一站点、同一目录或同一批新发布内容。典型证据是错误 URL 有聚集性，且这些 URL 在其他时段也偶发异常，与请求频率无关。
这两个解释可以同时存在，但区分它们的关键不是错误数量，而是错误与什么变量同步变化：是并发量，还是 URL 集合。
用一组可区分原因的证据替代“重跑一次”
要区分上面两个解释，需要在错误发生时同时记录以下信息，而不是只记录最终状态。
- 每个阶段的开始与结束时间，精确到秒，用来判断延迟发生在请求前、请求中还是解析时。
- 请求时的并发数与批次编号，用来判断错误是否随并发升高而出现。
- 原始响应码与响应体摘要，不要只存“失败”布尔值，否则无法区分限流、超时和解析错误。
- 失败 URL 的归属信息，例如同一域名、同一路径前缀，用来判断是否聚集。
- 同一批次中成功与失败的对照样本，用来排除“整批都失败”这种无区分力的结果。
一个可执行的动作是：把批量查询拆成固定小批次，每批记录上述字段，并在错误时段和非错误时段各跑一轮相同批次。结果如何影响下一步取决于对照结果——如果错误随并发升高而集中，优先排查请求侧；如果错误随 URL 集合聚集而与并发无关，优先排查数据源侧。
一个注明假设的短例子
假设某次收录批量查询在每天固定时段出现约三成失败，其他时段全部成功。第一轮记录显示：失败批次的并发数明显高于成功批次，且失败响应多为超时。降低并发后，同一时段失败减少。这组证据支持“请求侧限流或资源竞争”的解释。
但如果第二轮记录显示：失败 URL 集中在同一域名的同一目录，且降低并发后失败依旧，那么更合理的解释是数据源在该时段对该目录返回不稳定结果。此时继续调低并发不会解决问题，反而会掩盖真实原因。
这个例子的价值不在数字，而在比较方法：固定其他变量，只改变并发或只改变 URL 集合，看错误跟着哪个变量走。
记录之外必须核对的边界
短暂证据只能说明“当时发生了什么”，不能直接推出“应该怎么改”。在得出结论前，还要核对几个容易混淆的边界。
- robots.txt 的抓取限制不等于可靠的索引移除。查询失败不代表页面一定未被收录，也不代表一定被移除。
- 站点地图不保证收录。批量查询结果正常，也不能据此认定所有 URL 都已进入索引。
- HTTPS 不保证安全无漏洞或排名。查询通道加密与查询结果是否正确无关。
- 不同搜索引擎的支持情况须分别核查。同一批 URL 在不同来源返回不同状态，属于正常现象，不能合并成一个“错误率”。
把这些边界写进记录模板，可以避免把“查询失败”误读成“收录状态变化”。下一步动作应基于证据指向的环节，而不是基于失败数量本身。只有当时段、并发、URL 集合和原始响应被同时留下，短暂错误才从不可复现变成可判断。
