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

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

先给结论：源站正常而边缘节点异常时，最该保留的不是“收录掉了”这个结论，而是能区分源站响应、边缘响应、搜索引擎抓取结果三层的证据。具体做法是：以你手上一个正在被影响的URL为对象，分别在源站直连和边缘节点各取一次完整响应，把差异固定下来，再决定是修缓存、改回源，还是先通知搜索端重新抓取。缺少这一层对照，后续任何处理都只能靠猜。

先选一个URL，把“源站正常”变成可复查的记录

不要用首页，选一个近期有抓取记录、且你怀疑受边缘影响的页面。直连源站时，保留以下内容：

• 用curl -I取到的状态码、Content-Type、Content-Length、Last-Modified或ETag；
• 完整响应体的哈希值（如sha256sum结果），用来判断边缘返回的是不是同一份内容；
• 抓取时间与请求时带的Host、User-Agent，因为不同UA可能命中不同缓存策略。

这一步的假设是：源站直连结果代表“内容本身没问题”。如果直连都返回5xx或空body，问题就不在边缘，先修源站，后面的证据都不用取。

再取边缘响应，重点记录与源站不一致的字段

对同一个URL走边缘节点再取一次，逐项对比。真正有价值的证据是差异，而不是两份各自正常的报告：

• 状态码是否被改写，例如源站200而边缘返回403、404或503；
• Cache-Control、Age、X-Cache一类头部是否显示命中了旧副本；
• 响应体哈希是否与源站一致，不一致说明边缘缓存了旧版本或被注入内容；
• 是否出现源站没有的跳转、验证页或空内容。

如果边缘与源站完全一致，只是搜索端没收录，那问题更可能出在抓取或索引环节，而不是边缘异常。这个判断会直接改变下一步：前者去查缓存与回源，后者去查robots、站点地图和页面本身的收录条件。

把搜索端看到的结果单独留一份，别和边缘日志混在一起

搜索引擎抓到的版本可能既不是源站也不是当前边缘版本，而是更早的缓存。保留证据时要分开：

• 搜索端返回的状态码与抓取时间；
• 它抓到的正文片段或快照特征，用来判断抓的是哪个时间点的副本；
• 同一时间你自己的边缘请求结果，作为对照。

这里要克制因果推断：抓取量下降或某次抓取失败，不能单独证明是边缘异常导致的，也可能是抓取预算调整、站点整体改版或搜索端自身调度变化。证据的作用是缩小范围，不是直接定罪。另外，robots.txt 的抓取限制不等于可靠的索引移除，如果边缘异常期间顺手加了限制，它既不能帮你快速移除旧内容，还可能让后续恢复更慢。

证据够了再动手，动作要能回退

当差异集中在缓存头部和旧副本时，合理动作是刷新或清除该URL的边缘缓存，然后立即重取一次边缘响应，确认哈希与源站一致。这个动作的结果决定下一步：

1. 刷新后边缘与源站一致，且搜索端能正常抓取——保留刷新前后的两份记录，作为恢复依据；
2. 刷新后很快又回到旧副本——说明回源或缓存规则有问题，此时要留的是回源日志和缓存规则配置，而不是继续反复刷新；
3. 刷新后仍不一致——问题可能在边缘节点本身或中间层，需要把源站直连、边缘请求、搜索端抓取三组证据一起交给负责该层的人。

站点地图不保证收录，提交它只是告知，不是修复边缘异常的手段。HTTPS 也不保证安全无漏洞或排名，别把证书正常当成边缘正常的证据。如果这个URL属于旧内容或旧合作关系的退出范围，先判断它是否还有保留价值：有价值就按上面的流程修复并保留记录；确认要退出，则单独走移除流程，不要和边缘修复混在一次操作里，否则你无法判断是哪个动作起了作用。不同搜索引擎对缓存、抓取和移除的支持情况要分别核查，别用一家的结果推断另一家。

一份可交接的最小证据包

把上述内容整理成同一时间窗口内的三组记录：源站直连响应、边缘响应、搜索端抓取结果，每组都带时间、请求方式和关键头部，再附上你执行过的动作及动作后的复测结果。这样交接时，对方能直接看到差异在哪一层，而不需要重新复现。判断标准很简单：如果拿掉其中任意一组，结论就不再成立，那这组证据就必须保留。