网站收录状态：源站正常而边缘节点异常时应保留哪些证据
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /c201d9faadc7.html
📄
网站收录状态：源站正常而边缘节点异常时应保留哪些证据
先给结论：源站返回 200 并不能证明抓取链路正常，边缘节点异常时最该保留的是同一 URL 在源站与边缘两端的响应头、状态码、时间戳和请求标识。只有这些证据能区分“搜索引擎没来抓”和“来了但被边缘层挡掉”，后续动作才不会做反。
矛盾现象：源站日志干净，抓取却持续减少
一个常见场景是：源站访问日志里对应 URL 的请求很少，甚至一段时间内为零，但服务器本身健康、页面可访问、证书也没有报错。此时容易得出“搜索引擎不抓了”的结论，并去改内容或提交站点地图。但如果流量经过 CDN、WAF 或反向代理，源站日志干净可能只是请求在边缘节点就被处理或拦截了，根本没到达源站。
这个矛盾有两种合理解释：一是抓取工具确实降低了访问频率，请求没有发出；二是请求发出了，但在边缘节点被拦截、缓存了旧内容或返回了非预期状态。两者对应的处理方向完全相反，所以不能靠源站日志单独下判断。
两种解释分别会留下什么痕迹
如果是抓取频率下降，边缘节点上通常也不会出现对应请求的记录，或者只有零星正常请求，响应码以 200、304 为主，没有集中出现的 403、429、503。此时问题更可能出在内容质量、站点结构或抓取预算分配上。
如果是边缘节点异常，边缘访问日志或 CDN 控制台里会出现可观察的模式：同一路径在短时间内被同一类 User-Agent 反复请求，返回 403、429、503，或者返回 200 但内容明显是缓存旧版本；也可能出现重定向循环、证书校验失败、响应体被截断。这些痕迹不会出现在源站日志里，因为请求没有穿透到源站。
能区分两种解释的证据清单
要做出区分，需要同时抓取两端的证据，并保证时间能对齐。建议保留以下内容：
- 边缘侧原始日志：包含请求时间、完整 URL、状态码、响应大小、User-Agent、客户端 IP、命中的缓存规则或拦截规则标识。不要只导出汇总报表，汇总会丢掉单次请求的判定依据。
- 源站侧对应时段日志：用同一时间窗口和同一 URL 过滤，确认请求是否到达源站。如果边缘有请求而源站没有，说明请求终止在中间层。
- 两端响应头对比：同一 URL 分别直连源站和经过边缘请求，记录
HTTP 状态码、Cache-Control、Age、X-Cache一类缓存标识、Server以及自定义请求 ID。差异本身就是定位依据。 - 请求标识串联：如果边缘会注入唯一请求 ID 并透传到源站，用它把两端日志对上。没有这个 ID 时，用“时间戳到秒 + URL + User-Agent”近似匹配，但要注明匹配存在误差。
- 抓取工具侧的抓取统计与报错：记录该时段内抓取请求数、错误类型分布。注意请求量下降或某项统计归零不能单独证明边缘有问题，它也可能来自抓取频率正常波动、站点地图更新或内容变更。
- 变更时间线：记录 CDN 规则、WAF 策略、证书、DNS 解析的最近改动时间。没有时间线，日志里的异常起止点就无法和人为操作对应。
一个注明假设的短例子
假设某站点在边缘层新增了一条按 User-Agent 匹配的拦截规则，规则误伤了抓取工具的标识。此时边缘日志会显示该标识的请求集中返回 403，源站日志同一时段没有对应记录，直连源站的响应头是 200 而经过边缘的响应头是 403。三步证据一致，指向边缘规则误伤，下一步应是收窄规则并重新观察边缘日志，而不是去改页面内容或反复提交站点地图。
反过来，如果边缘日志里该标识的请求都是 200，源站也收到请求并正常返回，只是抓取统计在下降，那更可能是抓取频率或内容层面的问题，此时保留的证据应转向页面质量与内链结构，而不是继续排查边缘。
保留证据时容易踩的坑
只截图不导出原始日志，时间一长就无法做精确比对；只保留状态码不保留请求标识，两端日志对不上；把 robots.txt 的抓取限制当成索引移除手段，实际上它只约束抓取，不保证页面从索引中消失；把站点地图提交当成收录保证，它只是发现入口。HTTPS 也不等于链路无异常，证书链、TLS 版本协商和边缘回源都可能单独出问题，需要分别核查。
证据保留的目标不是证明谁对谁错，而是让下一步动作有依据。先固定时间窗口、两端日志和请求标识，再决定是调整边缘规则还是转向内容与抓取频率层面，这样每一次改动都能被后续日志验证。
