robots协议，改动前怎样保存原始状态
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /d3665ea12559.html
📄
robots协议，改动前怎样保存原始状态
改动 robots.txt 之前，最重要的一步不是先写新规则，而是先把当前线上文件完整、可追溯地留存下来。具体做法是：从线上地址下载原始文件，记录下载时间、HTTP 状态码和文件内容哈希，连同当时使用的完整 URL 一起归档；确认备份可读之后，再动线上文件。这样做的目的是，一旦新规则导致抓取异常，你能拿回一个经过验证的旧版本，而不是凭记忆重写。
准备：先分清你要保存的是什么
需要保存的对象是搜索引擎抓取时实际读到的那份文件，而不是你本地编辑器里的草稿，也不是 CMS 后台某个字段的截图。判断依据是：用抓取工具请求 https://你的域名/robots.txt，看返回的正文是否与线上一致。
- 记录完整请求地址，包括协议和路径，robots.txt 固定放在站点根目录。
- 记录响应状态码。返回 200 表示存在可读文件；返回 404 表示没有该文件，此时“原始状态”就是“不存在”，也要如实记录，而不是伪造一份空文件。
- 记录响应头中的内容类型与最后修改时间，作为辅助证据。
- 保存原始字节，不要经过编辑器自动格式化或去除空行。
如果站点使用 CDN 或反向代理，还要确认你抓到的是回源内容还是缓存内容。可以对比源站直接访问与经 CDN 访问的结果，两者不一致时分别留存，并注明各自来源。
实施：把原始状态存成可回溯的版本
推荐用命令行完成，因为输出可复制、可校验。下面示例中的域名是假设的，替换成你自己的即可：
curl -sS -D headers.txt -o robots.original.txt https://example.com/robots.txt
这条命令把响应头和正文分开保存。随后计算内容指纹：
sha256sum robots.original.txt
把哈希值、下载时间、请求地址、状态码写进一个说明文件，和 robots.original.txt 放在同一目录。命名建议带日期，例如 robots-2024-06-01.txt，避免多次改动后分不清先后。
如果团队使用 Git，可以把这份原始文件和说明文件一起提交，提交信息写清“保存改动前状态”。这一步的价值在于：哈希能证明文件未被改动，提交记录能证明保存时间，两者结合才构成可追溯的起点。
验证：确认备份真的能用
保存完不要直接开始改。先做三项检查：
- 打开备份文件，确认内容非空且与线上正文逐字一致，可再用一次哈希比对。
- 确认文件编码与换行符没有被改动，避免恢复后解析行为变化。
- 把备份放到一个改动范围之外的位置，例如独立目录或另一台机器，防止误删同目录文件时一起丢失。
判断结果很简单：如果备份文件的哈希与下载时记录的一致，且内容与线上一致，就可以进入修改环节；任何一项对不上，重新下载，不要将就。
维护：改动后如何对照与回退
新文件上线后，再次用同样的方式抓取并计算哈希，与备份并列保存。这样你手里至少有“改动前”和“改动后”两个可验证版本。若出现抓取量异常下降或重要目录被意外屏蔽，回退依据就是改动前那份文件，而不是猜测原规则写了什么。
需要提醒的是，robots.txt 的抓取限制并不等于可靠的索引移除。被屏蔽抓取的 URL 仍可能因为外部链接出现在搜索结果中，只是摘要信息受限。因此不要把 robots.txt 当作删除已收录页面的手段，改动它的目标应限定在抓取管理上。同样，站点地图不保证收录，HTTPS 也不保证安全无漏洞或排名，这些都与本文的备份问题无关，不必混在一起处理。
不同搜索引擎对 robots.txt 的具体支持细节需要分别核查，保存原始状态的方法对各家是一致的。下一步：先按上面的命令抓取并归档当前文件，确认哈希与说明文件齐备，再打开编辑器修改规则。
