收录提交源站正常而边缘节点异常时应保留哪些证据

📍 WDQWDWQD987AAAAA:216.73.217.31
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /707429cb3657.html
📄

收录提交源站正常而边缘节点异常时应保留哪些证据

当源站返回正常、但边缘节点对搜索引擎抓取请求返回异常时，最该保留的不是“提交入口截图”，而是能证明异常发生在边缘层、且源站内容本身可用的对照证据。缺少这组对照，后续无论重试提交、调整缓存还是联系服务商，都容易把问题归错层。

先分清：你看到的“异常”发生在哪一层

假设一个情境：站点源站直连时对爬虫返回 200 和完整正文，但通过 CDN 或边缘节点访问同一 URL 时，对同一 User-Agent 返回 403、503 或一个不含正文的挑战页。此时收录提交本身通常不是根因，提交只是把 URL 送进队列，真正决定能否被处理的是边缘节点给爬虫的响应。

需要保留的第一类证据是“同 URL、同 UA、不同入口”的对照记录。至少包含：请求时间、请求 URL、User-Agent、源站直连响应状态与响应体摘要、边缘节点响应状态与响应体摘要。两边响应体差异越大，越能说明问题在边缘策略而非内容质量。

必须固定的证据：响应头与缓存命中状态

仅记录状态码不够。边缘节点的异常常体现在响应头里，例如 cache-control、age、x-cache、cf-cache-status 一类字段（具体字段名取决于你使用的边缘服务，需按实际响应核对）。这些字段能帮助判断：异常是缓存了一份错误响应，还是每次回源都被边缘规则改写。

如果清除边缘缓存后异常消失，说明此前很可能缓存了错误响应；如果清除后依旧异常，则更可能是边缘规则、WAF 或回源链路在持续拦截。这个动作直接决定下一步是查缓存策略还是查访问控制规则。

把“提交记录”和“抓取响应”分开存档

收录提交的记录只能证明你送出了 URL，不能证明爬虫拿到了什么。因此要把两类证据分开：

  1. 提交侧：提交时间、提交的 URL 列表、提交时使用的账号或接口（不记录敏感凭据）。
  2. 抓取侧：边缘节点对爬虫 UA 的实际响应，以及源站直连的对照响应。

当两者放在一起时，可以排除一种常见误判：提交成功但抓取被边缘拦截。反过来，如果边缘响应正常、源站直连反而异常，那问题就不在边缘层，保留的证据方向也要随之调整。

日志与第三方观测：哪些字段值得留

边缘节点或 WAF 日志中，优先保留能定位“谁被拦、按什么规则拦”的字段：时间戳、客户端 IP 或 ASN、User-Agent、请求路径、命中规则 ID、动作（放行/拦截/挑战）、响应状态。若日志只显示拦截计数而不显示规则，证据价值有限，应尝试导出明细或申请更细粒度日志。

同时保留一份第三方抓取模拟结果作为旁证，但要注明它是模拟而非搜索引擎官方抓取。它的作用是说明“换一个网络位置是否复现”，不能单独证明搜索引擎一定遇到了同样问题。

证据齐了之后，先做哪一个动作

如果对照证据显示：源站正常、边缘对爬虫 UA 异常、且清除缓存后仍异常，那么下一步应优先核查边缘的访问控制与机器人规则，而不是反复重新提交。重新提交在边缘仍拦截的情况下，通常不会改变抓取结果。

如果证据显示异常只出现在缓存命中时，下一步应检查缓存键是否包含 User-Agent、是否存在把挑战页写入缓存的情况。此时调整缓存策略并再次用同 UA 验证，比继续提交更能推进问题解决。

需要提醒的是：robots.txt 的抓取限制不等于可靠的索引移除；站点地图不保证收录；HTTPS 也不保证边缘节点不会拦截爬虫。这些都不能替代上面这组分层对照证据。保留证据的目的，是让每一次后续动作都有可验证的前置判断，而不是在源站与边缘之间反复猜测。

图1 图2
nginx