robots.txt编写：源站正常而边缘节点异常时应保留哪些证据
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /0a39356c680d.html
📄
robots.txt编写：源站正常而边缘节点异常时应保留哪些证据
源站返回的robots.txt正确，不代表边缘节点返回的版本也正确。当你在源站验证无误、却从部分网络位置抓到旧规则、空文件或HTML错误页时，应优先保留“同一URL、不同节点、同一时间窗”的对照证据，再决定是等待缓存过期、改写规则规避，还是临时退出该分发路径。缺少这组对照，后续任何改动都无法复盘。
先固定请求坐标，再谈节点差异
边缘异常最容易被误判成源站问题，原因往往是两次抓取用了不同的URL、协议、主机名或User-Agent。要保留的第一类证据是请求坐标：完整URL（含协议与端口）、请求时间（精确到秒并注明时区）、User-Agent字符串、请求方法、响应状态码、响应头中的缓存相关字段，以及响应体的完整字节内容与哈希。
动作上，建议对同一路径发起至少两组请求：一组直连源站或绕过边缘的地址，一组走边缘节点。两组请求尽量在同一分钟内完成，并记录各自出口。结果如何影响下一步：如果源站与边缘的响应体哈希不同，问题在分发层；如果哈希相同但状态码不同，问题在边缘的错误处理；如果两者都相同，则应回到抓取工具或本地解析环节，而不是继续改robots.txt。
保留三份快照，而不是只留一份
只保存“异常那一份”不够，因为无法证明它偏离了什么。可操作的做法是同时保留三份快照：
- 源站快照：直连源站取得的robots.txt原始字节，包含换行符与编码。
- 边缘快照：从出现异常的节点取得的同一路径内容，连同响应头一起保存。
- 历史快照：本次改动前的版本，用于确认异常是“旧版本残留”还是“新版本未生效”。
三份快照都应带时间戳和获取方式说明。如果边缘快照是HTML错误页而非纯文本，不要只截取可见文字，应保存完整响应体，因为错误页中的状态码、跳转目标或缓存标记往往才是判断依据。
区分“缓存未过期”与“规则被改写”
边缘节点返回旧内容，有两种常见解释，处理方式完全不同。第一种是缓存尚未过期：响应头中带有较长的缓存有效期，边缘仍在使用旧副本。第二种是规则被改写：边缘层出于安全、压缩或重写策略，改变了响应体或状态码。
区分证据在于响应头与响应体的组合。若边缘响应头显示命中缓存且年龄较大，而响应体与历史快照一致，更倾向缓存未过期；若边缘响应体被插入额外标记、被压缩成不可读内容，或状态码被替换，则更倾向改写。这里要注意：请求量、抓取量或某节点返回归零，都不能单独证明缓存已刷新或规则已恢复，还需要同一坐标下的重复请求与响应头变化作为佐证。
取舍：保留、改写还是退出
证据齐备后，决策取决于异常范围与业务容忍度，而不是“哪种做法更标准”。
- 保留现状并等待：适用于异常仅出现在个别节点、源站与多数节点一致、且缓存有效期明确。前提是你能接受该节点在缓存过期前继续提供旧规则。动作是记录观察时间点，到期后重取同一坐标的快照；若仍不一致，再进入下一步。
- 改写规则规避：适用于边缘会改写响应体、导致规则被破坏的情况。例如边缘把纯文本包装成HTML，可尝试将关键规则放在文件更靠前的位置，或减少对边缘处理链的依赖。前提是你已确认改写发生在边缘而非源站，否则改写只会掩盖问题。
- 临时退出该分发路径：适用于异常节点占比高、且旧规则可能造成实际抓取偏差。前提是退出后仍有可用的直连路径，并且你已保存退出前的全部快照，否则退出会同时销毁证据。
假设一个短例子：某站点在源站看到robots.txt禁止抓取/tmp/，但一个边缘节点返回的旧版本并未禁止。若该节点缓存有效期还剩数小时，且该目录内容不重要，保留等待是合理选择；若该目录包含大量临时页，且异常节点不止一个，则应先保存三份快照，再考虑退出该路径。这个例子只说明比较方法，不代表任何真实站点的处理结果。
证据清单之外，还要记录“不能照搬”的边界
个别样本成立，不等于可以推广到所有节点或所有搜索引擎。不同搜索引擎对robots.txt的抓取频率、缓存策略与错误处理并不一致，必须分别核查。同时要记住：robots.txt的抓取限制不等于可靠的索引移除；站点地图不保证收录；HTTPS不保证安全无漏洞或排名。这些事实决定了你保留证据的目的，是判断“边缘返回了什么”，而不是承诺“改完就会生效”。
最后，把每次请求的坐标、三份快照、响应头与决策理由放在同一记录中，并注明哪些结论只是当前证据下的推断。这样当边缘行为再次变化时，你能直接对比新旧记录，而不是重新猜测问题出在哪一层。
