先给结论:源站正常只能证明“后端能返回正确内容”,不能证明爬虫收到的是同一份内容。此时应优先保留边缘节点返回的原始响应证据,而不是只截取源站日志。判断依据是两条链路是否分叉:如果源站与边缘节点的状态码、响应头、正文或缓存键不一致,问题就在边缘层;如果两者完全一致,才需要回到源站和抓取调度侧继续排查。证据保留的目标是让下一次复现不依赖记忆。
只要边缘节点还能响应,就应把“同一个 URL、同一组请求头”分别打到源站和边缘节点,保存两份可对比的原始响应。动作要具体:用 curl -I 或等效方式记录状态码与响应头,再用 curl -s 保存正文,并给每份文件标注请求时间、解析到的 IP、使用的 User-Agent 和是否带缓存绕过参数。
这一步的结果会直接决定下一步方向。若边缘节点返回 5xx、空正文或与源站不同的 Cache-Control,后续应围绕缓存策略、回源配置和节点健康检查取证;若两份响应一致,则边缘层嫌疑下降,应转向抓取频次、robots 规则和站点地图提交后的实际抓取记录。注意 robots.txt 中的抓取限制只约束爬虫行为,不等于可靠的索引移除手段,因此不要把“已写进 robots”当作内容已从索引消失的证据。
Content-Length、Cache-Control、Age、X-Cache 一类缓存标识。如果边缘节点已经下线、被替换或无法直接请求,就无法再取“双份响应”。此时应保留能重建时间线的间接证据:变更单、配置发布记录、DNS 或 CNAME 调整时间、证书更换时间、回源规则修改时间,以及监控中状态码和响应时长的突变点。关键不是证据数量,而是这些时间点能否与抓取失败的时间窗对齐。
这里有一个容易误判的地方:请求量或抓取量归零,不能单独证明边缘节点就是原因。它还可能来自抓取预算调整、robots 规则变化、站点地图失效、内容被判定重复,或外部链接结构改变。因此时间线证据必须与至少一项响应层证据交叉,才足以支撑“边缘异常导致收录失败”的判断。
假设某批旧文章在 3 月 10 日前后抓取量下降,同时边缘节点在 3 月 9 日做过一次缓存规则发布。仅凭时间接近不能下结论。可检查 3 月 8 日至 3 月 11 日边缘日志中同一 URL 的状态码分布:若 3 月 9 日之后 5xx 或空正文比例明显上升,而源站日志同期正常,则边缘层解释更强;若两边都正常,只是抓取请求减少,则应优先检查站点地图、内链和 robots。站点地图提交本身不保证收录,它只是发现线索之一。
本场景常与旧系统或旧合作关系退出同时发生。此时证据不仅用于排障,也用于决定旧 URL 是保留、跳转还是返回 410。可操作的分界是:如果旧 URL 仍有外部链接或站内导航价值,且边缘异常已修复,应保留可访问页面并观察后续抓取;如果旧内容已无业务价值、无有效外链、且边缘节点不再回源,则应记录移除决策、生效时间和替代关系,避免把“抓取失败”误当成“内容已删除”。
动作与结果的关系要写清楚:先导出仍引用旧 URL 的内链清单,再决定是否改链。若改链后边缘节点仍返回异常,说明问题不在链接层;若改链后抓取恢复,则旧 URL 的移除可以继续推进。HTTPS 只说明传输层加密,不保证页面无漏洞、不被篡改或一定获得更好排名,因此证书正常不能作为边缘内容正确的证据。
把上述材料按“请求层—响应层—时间线—决策记录”归档后,下一步不是立刻改配置,而是先确认异常是否可复现。可复现时,用同一组请求头再次对比源站与边缘节点;不可复现时,保留归档并设置观察窗口,记录后续抓取状态码与正文哈希是否回到一致。只有当边缘响应与源站响应重新一致,且旧内容的保留或移除决策已明确,才适合把问题从“边缘异常”转为常规收录观察。不同搜索引擎对状态码、robots 和站点地图的支持情况须分别核查,不能以一家表现推断另一家。