百度收录技巧：源站正常而边缘节点异常时应保留哪些证据
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /a102e71189cd.html
📄
百度收录技巧：源站正常而边缘节点异常时应保留哪些证据
先给结论：当源站返回正常、边缘节点却异常时，最该保留的不是“收录变差”的截图，而是能证明百度抓取器当时实际拿到什么响应的证据。核心是同时留存源站响应、边缘响应、请求标识和时间戳，让两条链路可对齐。如果只保留源站日志，你无法排除边缘节点返回了错误状态、旧缓存或拦截页；如果只保留边缘日志，又无法确认源站是否真的正常。两者缺一，结论都会失效。
为什么“源站正常”本身不足以支撑判断
源站正常通常指你的回源请求得到 200 和正确内容，但这只代表回源这一跳。百度抓取器访问的是边缘节点，它可能命中缓存、被节点规则改写、被区域策略拦截，或拿到过期的 HTML。此时源站日志里可能完全没有这次请求，或者只有一次干净的回源记录，看起来一切正常。
因此需要区分两种成立条件：
- 边缘异常成立：同一时间窗内，边缘访问日志显示抓取器 UA 得到 5xx、403、跳转异常或内容被替换，而源站回源日志显示正常。
- 边缘异常不成立：边缘日志缺失、时间不同步，或抓取器请求实际未经过该节点。这种情况下不能把收录波动归因于边缘。
一个反例会让上述结论失效：如果边缘节点只对特定地区或特定 IP 段异常，而你保留的证据来自另一地区节点，那么“边缘异常”这个判断就不适用于百度抓取器。必须用抓取器实际出口对应的节点日志，或至少标注证据采集位置。
必须保留的四类证据
1. 同一请求在源站与边缘的配对记录
至少保留：请求时间（精确到秒并注明时区）、请求 URL、UA、边缘节点返回状态码、源站返回状态码、响应体长度或内容哈希。配对的关键是找到同一个请求 ID 或同一时间戳附近的记录。如果边缘会改写请求头，源站看到的 UA 可能不同，这时要用 URL 加时间窗口对齐。
2. 响应内容的可核对副本
不要只存状态码。保存边缘返回的 HTML 片段或完整响应，并记录它与源站当前内容的差异。常见异常是边缘返回旧版页面、插入跳转脚本或返回验证页。保存方式可以是文件加哈希，避免后续内容变化导致无法复核。
3. 缓存与规则配置的快照
保留异常时间点的缓存规则、回源规则、重写规则和节点分组配置。配置后续可能被修改，没有快照就无法解释当时行为。注意：这些配置只用于内部核对，不需要对外公开。
4. 百度抓取侧的可见迹象
可保留百度搜索资源平台中抓取频次、抓取异常、站点地图提交后的状态变化等记录，但要清楚这些迹象不能单独证明原因。抓取量下降也可能来自内容更新节奏、站点整体质量变化或抓取配额调整，不能直接等同于边缘故障。
一个假设例子：如何用证据区分两种解释
假设某站点源站日志显示百度抓取器每天正常回源 200，但收录新增停滞。边缘日志却显示同一 UA 在部分节点得到 403。此时有两种解释：
- 边缘节点拦截了抓取器，导致百度拿不到内容。
- 边缘日志中的 UA 是伪造的，真实抓取器并未被拦截，收录停滞另有原因。
区分方法是核对请求来源 IP 是否属于百度官方出口，并比对同一时间源站是否收到对应回源。如果边缘 403 请求的来源 IP 不在百度公布范围，且源站同期有正常回源，则第二种解释更可能成立。这个例子中的数字和节点均为假设，只用于说明比较方法。
下一步动作：先固定证据，再改配置
在证据齐备前不要急于刷新缓存或修改边缘规则，否则异常现场会被覆盖。建议按以下顺序执行：
- 先导出异常时间窗内的边缘与源站日志，并计算响应体哈希。
- 再保存当前边缘配置快照，标注采集时间和节点范围。
- 然后用一个可控测试请求复现：分别从源站和边缘请求同一 URL，记录状态码与内容差异。
- 最后才决定是否调整规则，并在调整后保留前后对比记录。
这个动作的结果会直接影响下一步：如果复现显示边缘确实返回异常内容，就可以针对该节点规则修复并继续观察抓取；如果复现显示边缘正常，就应转向检查内容质量、站点地图有效性和抓取配额，而不是继续在边缘层排查。保留证据的意义正在于此——它让你在两种解释之间做出可复核的选择，而不是凭直觉改配置。
