robots：改动前怎样保存原始状态
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /c7c84cd37123.html
📄
robots：改动前怎样保存原始状态
改动 robots.txt 前，保存原始状态最可靠的做法是：先把当前文件完整下载到本地，记录它的获取时间、HTTP 状态码和内容哈希，再在版本控制或带时间戳的备份目录中留存一份。这样做的目的不是走形式，而是当改动后出现抓取异常、收录波动或团队争议时，你能拿原始文件逐字节对比，判断问题是不是由这次修改引起的。只靠记忆或截图不够，因为 robots.txt 的生效依赖具体路径、User-agent 分组和规则顺序，肉眼很容易漏看。
先观察：确认你保存的是真正生效的那份文件
很多人以为打开域名根目录下的 robots.txt 就是全部，但实际生效的文件取决于访问协议和主机名。抓取工具请求的是 https://example.com/robots.txt 这样的具体地址，而不是“这个网站”的抽象概念。保存前先确认三件事：
- 你访问的是 http 还是 https，带 www 还是不带，两者可能返回不同内容。
- 返回状态码是 200、404 还是 301。404 表示没有该文件，此时“原始状态”就是“不存在”，也应记录。
- 响应内容是否被 CDN、反向代理或服务器规则改写。
如果站点有多个子域或测试环境，分别保存，不要假设它们内容一致。观察阶段的目标是锁定“改哪一份”，而不是急着编辑。
判断：用什么形式保存才算可追溯
保存形式决定日后能不能精确比对。推荐同时保留两种：
- 原始字节副本：用
curl -o robots-backup-20250101.txt https://example.com/robots.txt这类命令直接落盘，保留换行、空格和注释。假设你手动复制粘贴，行尾格式和空行可能被编辑器改掉，对比时会产生假差异。 - 可读记录：在备份文件旁写一个说明，记录获取时间、完整 URL、状态码、Content-Type，以及是谁在什么情况下获取的。时间建议用带时区的格式，避免跨团队协作时产生歧义。
如果站点已经用 Git 管理配置，把 robots.txt 纳入版本控制是最省事的做法，每次改动都有 diff 和提交记录。若没有版本控制，至少建立按日期命名的备份目录，例如 backup/robots/2025-01-01/，并保留最近若干份，不要只留最新一版。
还可以计算内容哈希作为指纹，例如 sha256sum robots-backup-20250101.txt。哈希的价值在于：日后只需重新计算一次，就能确认文件是否被改过，而不必逐行读。
处理：改动时把原始状态和变更意图绑在一起
保存原始状态之后，改动本身也要留下痕迹。建议在提交信息或变更记录里写清三件事：改了什么规则、为什么改、预期影响哪些抓取工具。例如“原本禁止 /search/，现放开，因为该目录已改为静态页”。
一个常见误区是把 robots.txt 当成索引移除工具。robots.txt 的抓取限制不等于可靠的索引移除：它阻止抓取，但已经收录的 URL 仍可能出现在结果中，而且不同搜索引擎对规则的支持和解释存在差异，需要分别核查。因此如果你的真实目标是让某页面从搜索结果消失，改 robots.txt 往往不是正确手段，保存原始状态的意义也在于能随时回退。
改动时还要注意 User-agent 分组和规则顺序。假设原始文件里有一段针对特定爬虫的 Disallow，你新增了通配规则，可能因为分组顺序或最具体匹配原则导致行为变化。保存原始文件后，用 diff 工具对比，能直观看到是哪一行引入了差异。
复查：改动后如何验证并决定是否回退
改动上线后，按以下检查项复查：
- 重新请求 robots.txt，确认返回的是新内容，状态码正常。
- 用 diff 对比备份与新文件，确认只有预期行发生变化。
- 在搜索平台的抓取测试工具中检查关键 URL 是否仍可抓取，注意不同搜索引擎的工具和判断标准不同。
- 观察服务器日志中相关爬虫的请求变化，判断是否出现异常下降或上升。
如果发现抓取量异常下降、重要目录被误屏蔽，或与预期不符，直接用保存的原始文件覆盖回退，再重新评估改动方案。回退后同样要重新请求确认生效，而不是改完就认为已经恢复。
下一步：现在就去获取你负责站点的 robots.txt 原始副本，记录 URL、状态码和时间，并计算一次哈希。这一步做完，你才有资格谈“改”。
