搜索引擎收录检查：源站正常而边缘节点异常时应保留哪些证据
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /5dc876151c8d.html
📄
搜索引擎收录检查：源站正常而边缘节点异常时应保留哪些证据
先给结论：如果源站返回正常、但边缘节点在抓取时返回异常，优先保留的是“同一时刻、同一URL、同一请求头下，源站与边缘节点的响应差异证据”，而不是先清缓存或改 robots.txt。因为前者能帮助你判断问题是否真实存在于抓取链路，后者可能把唯一可复查的现场直接抹掉。这个结论有一个重要前提：你能拿到边缘节点的访问日志或至少能复现请求；如果两者都拿不到，下面的证据清单要相应降级。
为什么源站正常不等于抓取链路正常
搜索引擎收录检查里，最常见的误判是把“我用浏览器打开源站正常”当成“抓取一定正常”。实际上，抓取请求通常经过 DNS 解析、CDN 或边缘节点、WAF、回源、源站应用等多层。源站正常只说明最后一跳没问题，边缘节点仍可能因为缓存规则、节点回源超时、区域调度或安全策略返回 5xx、403、验证页或空内容。
因此，证据要围绕“差异”来收集，而不是围绕“源站是否活着”。如果边缘节点返回 403，而源站返回 200，这个差异本身就是关键证据；如果边缘节点返回 200 但正文为空，差异同样成立。只有把两侧放在同一时间窗口对比，才能排除“刚刚修好了”或“只是本地网络问题”的解释。
必须保留的四类证据
下面四类证据按优先级排列。能全部保留最好；只能保留一部分时，优先保留第一类和第二类。
- 同一 URL 的双侧响应记录。分别记录源站直连和边缘节点的 HTTP 状态码、响应头中的
Cache-Control、Age、X-Cache、Server、Content-Length，以及响应正文的前若干字节。重点是时间戳和请求头要一致，否则对比不成立。 - 抓取请求的 User-Agent 与来源 IP。如果边缘节点对特定 User-Agent 或特定 IP 段做了拦截，普通浏览器请求不会触发。保留搜索引擎抓取时使用的 User-Agent 和边缘节点日志里的来源 IP，才能判断异常是否只针对抓取流量。
- 边缘节点的访问日志与回源日志。日志要包含请求时间、节点标识、回源状态、缓存命中状态和最终返回状态。没有节点标识，就无法判断是个别节点异常还是全局异常；没有回源状态，就无法区分“边缘自己返回了错误”和“回源失败被边缘包装成错误”。
- 异常前后的配置变更记录。缓存规则、WAF 规则、回源超时、证书、DNS 调度策略的变更时间和内容，都要留档。很多边缘异常不是持续故障，而是某次变更后只影响部分节点或部分路径。
两种做法怎么取舍：先冻结现场还是先恢复服务
面对源站正常而边缘异常，常见两种做法：一是立即清缓存、回滚配置，尽快恢复抓取；二是先冻结现场，保留日志和响应样本，再动手修复。两者都合理，但适用条件不同。
如果异常已经持续影响大量 URL，且你已有可回滚的最近配置版本，先恢复服务更合理。代价是现场可能被覆盖，所以动作要配合证据保留：在回滚前，先对至少三到五个代表性 URL 做双侧响应记录，并导出异常时间段的边缘节点日志。回滚后，用同一组 URL 再做一次对比，确认异常是否消失。这个动作的结果会直接决定下一步：如果回滚后恢复，问题大概率在配置变更；如果回滚后仍异常，就要转向节点或回源链路排查。
如果异常只出现在少量 URL，或你还没有可回滚的版本，先冻结现场更合理。代价是恢复时间被拉长，但你能拿到完整证据链。此时不要先清缓存，因为清缓存会改变 Age 和缓存命中状态，让后续无法判断异常是否与缓存内容有关。
一个会让上述结论失效的反例是：边缘节点异常其实是源站间歇性超时导致的，只是你检查源站时恰好赶上正常窗口。这时“源站正常”这个前提本身不成立，双侧响应记录如果只取了一个时间点，就会误导判断。因此，双侧记录至少要覆盖异常发生前后的多个时间点，而不是单次快照。
一个注明假设的短例子
假设某站点在边缘节点上对 /product/a 返回 403，源站直连返回 200。你保留了三样东西：同一分钟内的双侧状态码与响应头、边缘节点日志中该 URL 的回源状态为 200、以及当天上午新增的一条 WAF 规则记录。这三样证据放在一起，指向的是“边缘安全规则拦截了抓取请求”，而不是“源站不可用”。下一步动作应该是核查该 WAF 规则的作用范围和触发条件，而不是去改站点地图或提交收录。这个例子只用于说明证据如何影响下一步，不代表任何真实站点或平台行为。
证据到手后，下一步怎么走
拿到证据后，先判断异常是“只针对抓取”还是“对所有请求”。如果只有抓取请求异常，检查边缘节点的 User-Agent 规则、频率限制和 IP 信誉策略；如果所有请求都异常，检查缓存规则、回源配置和节点健康状态。判断依据来自前面保留的日志和响应头，而不是来自“源站能打开”这个单一事实。
同时要接受一个现实：robots.txt 的抓取限制不等于可靠的索引移除，站点地图也不保证收录，HTTPS 更不保证安全无漏洞或排名。这些手段不能替代对边缘异常本身的排查。不同搜索引擎对抓取来源、验证方式和边缘行为的支持情况需要分别核查，不能拿一个引擎的表现直接推断另一个。
最后，把这次保留的证据按时间线归档，并记录你采取的每一个动作及其结果。这样下次再出现源站正常而边缘异常时，你能更快判断是同一类问题，还是一个新的、需要重新取证的场景。
