搜索引擎抓取规则，源站正常而边缘节点异常时应保留哪些证据
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /3eedcfae814b.html
📄
搜索引擎抓取规则，源站正常而边缘节点异常时应保留哪些证据
先给结论：源站日志显示 200，并不等于抓取链路正常。边缘节点异常时，最该保留的是能证明“哪个节点、在什么时间、对哪个 URL、返回了什么”的成组证据，而不是只截一张源站成功日志。下一步动作取决于这些证据能否把源站与边缘节点区分开。
两个解释：源站成功但边缘失败，或抓取根本没到边缘
源站正常、边缘异常，通常有两种成立条件不同的解释。
第一种是请求确实到达了边缘节点，但边缘返回了错误、空响应、跳转循环或旧缓存。此时源站可能完全健康，因为边缘没有把请求转发过去，或者转发后没有正确回传。第二种是抓取请求根本没到边缘，问题出在 DNS 解析、防火墙策略、IP 段封禁或线路层面。这种情况下源站和边缘都可能“看起来正常”，因为异常发生在更前面。
两种解释的处置方向不同：前者要查边缘配置和缓存，后者要查解析与网络准入。所以证据必须能回答“请求有没有到边缘”，而不只是“源站有没有报错”。
能区分两种解释的证据组合
单个日志不能定性，成组证据才有区分力。建议按下表保留，并让时间戳尽量对齐到同一分钟。
- 边缘访问日志：记录请求时间、客户端 IP、请求 Host、完整 URL、边缘返回状态码、响应大小、上游耗时、缓存命中状态。若边缘日志里根本没有该抓取 IP 的记录，更倾向第二种解释。
- 源站访问日志：记录同一时间窗内来自边缘回源 IP 的请求，而不是只保留来自搜索引擎 IP 的请求。源站只看到边缘 IP 是正常现象，关键是回源请求是否存在。
- 抓取端可见结果：用与抓取端相近的出口去请求同一 URL，保留响应头中的状态码、缓存相关字段、跳转链和内容长度。注意这只能说明该出口看到的结果，不能代表所有节点。
- 解析与网络准入记录：DNS 解析结果、边缘节点 IP 归属、防火墙或 WAF 对该 IP 段的放行与拦截记录。若抓取 IP 在边缘之前就被拦截，边缘日志自然为空。
- 变更时间线：证书、DNS、缓存规则、WAF 规则、回源配置的变更时间。把变更时间与异常出现时间并列，才能判断哪个动作可能相关。
这里要避免一个常见误判：抓取量归零或某个统计项下降，不能单独证明是边缘故障。它也可能来自抓取预算调整、站点整体改版、robots.txt 变化，或抓取端自身的调度波动。只有把边缘日志、源站回源日志和网络准入记录放在同一时间窗里，才能排除这些竞争解释。
一个假设例子：如何用证据决定下一步
假设某站点源站日志持续显示 200，但抓取端报告大量超时。先取异常时段内边缘节点的访问日志：
- 如果边缘日志中能看到抓取 IP，但状态码为 5xx 或响应大小为 0，说明请求已到边缘，问题在边缘处理或回源链路。下一步应查边缘的上游超时配置和回源健康检查，而不是改源站代码。
- 如果边缘日志中完全没有抓取 IP，但源站也没有对应回源请求，说明请求可能在到达边缘前就被丢弃。下一步应查 DNS 解析是否指向了异常节点、防火墙是否拦截了该 IP 段。
- 如果边缘日志有请求且返回 200，但抓取端看到的是旧内容或空内容，说明可能是缓存或内容回传问题。下一步应核对缓存键、缓存过期规则和边缘到源站的响应体是否完整。
这个例子的数字和状态只是假设，用于说明比较方法：同一个 200 在不同日志里的含义不同，必须结合请求是否到达边缘来判断。
保留证据时的三个操作要点
第一，时间窗要一致。边缘日志、源站日志和抓取端记录应使用可对齐的时间标准，并注明时区。时间窗错位会让“没有记录”变成假象。
第二，保留原始格式。导出的日志、响应头和抓取端记录尽量保留原始字段，不要只保留截图或人工摘要。后续排查需要按 IP、URL、状态码重新筛选。
第三，区分“限制抓取”和“移除索引”。robots.txt 的抓取限制不等于可靠的索引移除，它只影响抓取行为，不保证已收录内容从结果中消失。站点地图也不保证收录，它只是发现线索。HTTPS 同样不保证安全无漏洞或排名。不同搜索引擎对这些机制的支持情况须分别核查，不能拿一个引擎的表现推断另一个。
把这些证据按时间线整理后，通常能落到一个明确动作：要么修边缘配置，要么修网络准入，要么修缓存与回源。动作执行后，再用同一组日志对照异常是否消失，才能判断处理是否有效。
