先给结论:源站返回的robots.txt正常,不代表用户和爬虫实际拿到的就是同一份。边缘节点异常时,最该保留的不是一句“我们这边没问题”,而是能证明差异存在的对照证据:同一URL、同一时刻、不同网络位置拿到的状态码、响应头和正文摘要。缺少这组对照,后续无论是修缓存、改规则还是做移除决策,都只能靠猜。
假设一个站点要下线旧版帮助目录,但保留其中少量仍被引用的页面。运维在源站把robots.txt改为只屏蔽已确认无价值的路径,源站自测返回200,内容也正确。可是外部反馈显示,部分地区的爬虫仍能抓到被屏蔽路径,另一些地区却连允许抓取的路径也拿不到。
这时有两种成立条件不同的解释。第一种是边缘缓存仍保存旧版robots.txt,源站更新没有穿透到所有节点;第二种是源站与边缘节点对同一请求的处理逻辑不同,例如边缘做了重写、跳转或鉴权。两者要保留的证据并不相同,所以不能只截一张源站返回图就结束。
发现异常后,第一时间固定对照样本。选三条URL:一条确认要屏蔽的旧路径,一条确认要保留的路径,一条robots.txt本身。对每条URL,在同一时间窗口内分别从源站直连位置和至少两个外部网络位置发起请求。
这样做的实际动作是:把“源站正常”变成可复核的对照表。结果会直接影响下一步——如果只有边缘节点返回旧正文,问题在缓存层;如果边缘节点返回的状态码与源站不同,问题在边缘处理逻辑,处理顺序和负责人都会变。
边缘异常常被误判为“改完就坏了”,但实际可能是发布、缓存刷新、CDN回源策略调整中的某一步引入的。需要保留一条最小时间线:源站文件最后修改时间、发布操作时间、首次收到异常反馈的时间、第一次抓到异常响应的时间。
这里要克制因果推断。抓取量下降、某路径请求归零,都不能单独证明robots.txt处理正确。它也可能是爬虫调度变化、站点整体流量波动或边缘节点临时故障。时间线的作用是缩小范围,不是下结论。
一个可执行的判断动作:如果异常响应时间早于发布操作时间,那么“本次修改导致异常”的解释就不成立,应优先排查更早的边缘配置或缓存状态。这个结果会改变排查方向,避免在错误的时间点上反复回滚。
robots.txt的抓取限制不等于可靠的索引移除。即使边缘节点最终正确返回了屏蔽规则,已经进入索引的旧URL也可能继续出现。因此证据要分成两层:一层证明爬虫是否被正确限制抓取,另一层证明索引状态是否发生变化。
对第一层,保留robots.txt的实际响应和抓取日志中的对应请求;对第二层,保留目标URL当前的索引状态查询结果和查询时间。不要把两者混在一张表里,也不要用“已经屏蔽”推断“已经移除”。如果旧内容必须退出,而robots.txt只能限制抓取,那么还需要评估其他移除手段,并分别记录各自的动作和结果。
旧内容、旧系统或旧合作关系退出时,常见的错误是只保留“已下线”的结论,不保留判断依据。边缘异常场景下,建议按路径保留三类记录:仍被引用的路径、确认无价值且可屏蔽的路径、状态不明的路径。
这个动作的结果是:退出范围被证据切成三块,而不是一次性全删或全留。下一步无论是继续屏蔽、恢复抓取还是申请移除,都有对应的依据,不必重新采集。
站点地图不保证收录,HTTPS也不保证安全无漏洞或排名。这些结论同样适用于边缘异常排查:不要因为站点地图里还有某条URL,就认为它一定被抓取;也不要因为边缘节点返回了HTTPS响应,就认为内容一致。不同搜索引擎对robots.txt的支持情况须分别核查,不能拿一个引擎的表现替另一个下结论。
最后,证据要能回答三个问题:同一时刻不同位置拿到了什么、变化发生在哪一步、每个动作之后状态是否改变。如果一组记录只能证明“源站是好的”,它就不足以支撑边缘异常的修复决策。把对照样本、时间线和分层结论一起保留,才是这类问题里真正有用的证据组合。