搜狗网站收录：源站正常而边缘节点异常时应保留哪些证据
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /1a1ac90a1ad9.html
📄
搜狗网站收录：源站正常而边缘节点异常时应保留哪些证据
先给结论：源站正常、边缘节点异常时，要保留的不是“收录掉了”这一句话，而是能证明搜狗抓取器看到的是哪一个版本的证据。最该固定的是抓取时刻的响应头、完整响应体、边缘节点标识和源站日志的对应关系；只截一张搜索结果页，无法区分是节点返回了错误内容，还是搜狗只是暂时降低了抓取频率。
矛盾现象：源站日志干净，收录却不见好转
常见的矛盾是：源站访问日志里搜狗蜘蛛的请求大多是 200，页面内容也正常，但搜狗侧的收录表现没有恢复。这时容易得出“源站没问题，所以是搜狗的问题”这个结论，但它跳过了中间一层——边缘节点。蜘蛛请求会先落到 CDN 或反向代理，再由节点回源。源站正常只说明回源那一段正常，不代表节点返回给蜘蛛的内容正常。
还有一种更隐蔽的情况：节点对普通用户返回新页面，对特定 UA 或特定 IP 段返回旧缓存、验证页或空内容。源站日志看到的仍是 200，因为回源确实成功了，异常发生在节点组装响应的环节。
两种解释，以及能区分它们的证据
解释一：边缘节点返回了与源站不一致的内容
如果节点缓存了旧版本、命中了一条错误的改写规则，或者对搜狗 UA 命中了不同的缓存策略，蜘蛛拿到的就是旧内容或异常内容。区分它的关键证据是同一 URL 在节点侧和源站侧的响应体对比。操作上，用与搜狗 UA 一致的请求头分别打边缘节点地址和源站地址，保存两次响应的状态码、Content-Length、Last-Modified、ETag 和正文摘要。如果两者正文哈希不同，就说明节点层发生了内容偏移，下一步应去查该节点的缓存键和规则命中记录，而不是继续改源站模板。
解释二：节点正常，问题出在抓取调度或索引处理
另一种解释是节点返回的内容与源站一致，但搜狗抓取量下降、收录未更新。此时节点是清白的，证据方向要转向抓取行为本身。可保留的证据包括：按小时统计的搜狗蜘蛛请求量、状态码分布、抓取 URL 列表，以及这些 URL 是否集中在某一目录或某一类模板。如果请求量下降伴随 5xx 或超时上升，问题偏向节点稳定性；如果请求量平稳但收录不动，问题更可能在索引侧，需要核查页面质量、重复度和内链结构，而不是继续排查节点。
需要固定的证据清单
- 抓取时刻的边缘节点响应头：状态码、Cache-Control、Age、X-Cache 一类缓存命中标识、节点 IP 或机房标识。
- 同一时刻的源站响应头与响应体摘要，用于和节点侧做逐项对比。
- 源站访问日志中对应时间窗的记录，确认回源是否发生、回源状态码是多少。
- 节点侧的缓存命中与规则命中记录，能说明这条请求走了哪条策略。
- 按时间排列的搜狗蜘蛛请求量与状态码分布，用于判断是抓取异常还是索引异常。
- 异常 URL 的完整列表及所属模板，便于判断是个别页面还是整类页面。
这些证据的共同点是可复查、带时间戳、能对应到具体节点。缺少时间戳的截图、只有结论没有原始响应的记录，都无法在后续排查中复用。
一个假设例子：如何用证据决定下一步
假设某站点在边缘节点上配置了对旧目录的 301 跳转，源站已经删除了该目录。源站日志显示回源请求返回 404，节点则对蜘蛛返回 301。此时保留节点响应头和跳转目标，就能看出蜘蛛被引导到了一个已下线的地址。动作是把该跳转规则改为返回 410 或直接放行到新地址，结果会让后续抓取不再落在无效路径上，下一步就可以观察抓取量是否回到正常目录，而不是盲目提交新的站点地图。
反过来，如果节点响应与源站完全一致，却仍无收录改善，那么继续调整节点缓存策略不会有收益，应把精力放到内容质量与内链结构上。这里要提醒：robots.txt 的抓取限制不等于可靠的索引移除，站点地图也不保证收录，这两点不能作为节点异常已解决的依据。
保留证据时的边界与取舍
证据不是越多越好。优先保留能区分“节点问题”和“索引问题”的那几项，其余日志可以按时间窗抽样。如果旧系统或旧合作关系正在退出，只需保留仍在使用的那部分节点和目录的证据，已下线的部分不必长期留存。判断标准是：这条证据能否在两周后回答“当时蜘蛛看到的是什么”。能回答的留下，不能回答的可以清理。
最后，不同搜索引擎对同一节点的处理方式可能不同，搜狗侧的证据不能直接套用到其他引擎，需要分别核查。把节点响应、源站日志和抓取统计三者对齐，才能在源站看似正常时找到真正需要处理的那一环。
