robots.txt：只在特定时段出错时，怎样捕捉短暂证据
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /6884b62dee7d.html
📄
robots.txt：只在特定时段出错时，怎样捕捉短暂证据
核心做法是：不要等到故障时段再临时抓取，而是提前布置一个按固定间隔自动记录 robots.txt 响应与抓取行为的采集点，把“当时到底是什么内容”变成可回看的带时间戳记录。因为错误只在特定时段出现，人肉复现往往扑空，能决定下一步的只有持续留痕。
先判断这是“内容瞬时变化”还是“抓取行为瞬时变化”
这两种情况的证据位置完全不同，选错方向会白等一个周期。
- 内容瞬时变化：同一 URL 在不同时刻返回的 robots.txt 正文不一样，例如某段时间多出或缺少某条规则。证据在响应正文和响应头里。
- 行为瞬时变化：robots.txt 正文一直没变，但爬虫在该时段的抓取量、抓取路径或状态码分布异常。证据在服务器访问日志里。
区分方法很直接：在疑似时段前后各取一次 robots.txt 原文做逐字节对比。如果两次一致，问题大概率不在文件内容，而在于爬虫对该文件的读取或后续行为；如果两次不一致，就要追是谁在改这个文件。
两种采集方案：定时轮询与日志回查，各自成立的条件
假设情境（以下为虚构示例，仅用于说明比较方法）：某站点管理员发现，每天凌晨的一段固定时间内，部分栏目页抓取量明显偏低，白天恢复正常。他怀疑这段时间 robots.txt 被替换成了限制性版本，但手动访问时看到的始终是正常内容。
他面前有两个选择：
- 定时轮询：写一个任务，每 1–5 分钟请求一次 robots.txt，把状态码、响应头、正文哈希和抓取时间写入日志。代价是需要一个能长期运行的执行环境，且轮询频率越高，越可能被对方限流，反而制造噪声。
- 日志回查：不新增请求，直接从服务器访问日志里筛出爬虫对 robots.txt 的请求记录，看该时段返回了什么状态码、多大体积。代价是日志只记录结果，不记录正文内容，若文件被替换成体积相近的不同规则，仅凭日志无法还原。
选择条件：如果你能确认服务器日志完整保留了爬虫对 robots.txt 的请求行与状态码，且怀疑的是“读取失败”这类状态层面的问题，日志回查成本更低、不引入额外请求。如果你怀疑的是“正文被换但状态码仍是 200”，日志回查无法给出正文，只能靠定时轮询留证。两者并不互斥，但先做哪个取决于你怀疑的是状态还是内容。
把证据固定成可复查的形式
无论选哪种方案，都要让记录满足三个条件，否则事后无法用于判断：
- 带时区的时间戳：只写“凌晨 3 点”无法对齐多台服务器和日志，必须写明时区。
- 原始响应而非摘要：至少保留状态码、响应头中的缓存相关字段，以及正文的完整副本或可校验的哈希值。只留一句“返回 200”不足以证明内容正确。
- 同时记录爬虫侧与服务器侧：服务器记录的是“我返回了什么”，爬虫日志或抓取统计记录的是“它实际用了什么”。两边对不上，才说明中间存在缓存或代理层。
一个实际动作：在轮询脚本里，把每次响应的正文哈希与上一次不同时单独标记出来，并保留那一份正文副本。结果会直接决定下一步——如果只在特定时段出现哈希变化，说明有另一个进程或另一台机器在改写文件，排查方向转向发布流程和缓存层；如果哈希始终不变，问题就不在文件内容，应转向抓取频次与服务器响应时间。
拿到短暂证据后，先分清它证明了什么
短暂异常被捕捉到，不等于原因已确定。需要注意几点：
- 某时段抓取量下降，可能是 robots.txt 拦截，也可能是服务器该时段响应变慢、带宽被占、或爬虫自身调整了调度。抓取量归零本身不能单独证明是 robots.txt 导致的。
- robots.txt 只表达抓取限制，它不等于可靠的索引移除手段。即使某时段文件里出现了限制规则，也不应据此推断页面会从索引中消失或恢复。
- 站点地图的存在不保证收录，抓取限制的放宽也不保证抓取量立刻回升。把这些当作因果会误判修复效果。
- 不同搜索引擎对 robots.txt 的解析和支持范围需要分别核查，不能用一个引擎的表现推断另一个。
因此，捕捉到证据后应做的下一步是：用同一时间段的两份记录做对照——一份是文件内容记录，一份是抓取行为记录——只有当两者在时间上吻合，才能把嫌疑集中到文件本身；若只有行为异常而文件无变化，应继续排查缓存、CDN 回源和服务器负载，而不是急着改 robots.txt。
