📍 WDQWDWQD987AAAAA:216.73.216.73
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /f0fc42269690.html
📄

robots.txt写法改动前怎样保存原始状态：先留可回退副本再改

改动 robots.txt 前，保存原始状态的核心做法是：先把当前线上文件完整取回，按“原样内容+获取时间+来源路径”存成只读副本，再在副本上做修改和对比。这样做的目的不是留档好看，而是当抓取异常、协作冲突或规则写错时，能快速判断改了什么、能否回退。适用前提是多人协作或需要交付清楚；如果只是本地测试且文件未上线，也要保留改动前版本，但验收重点会不同。

保存原始状态要存哪些内容

只复制一行规则不够，至少应保存四类信息：

• 完整原文：包括注释、空行、大小写和行尾换行，不要用编辑器“格式化”后再存。
• 来源与时间：记录取自哪个环境、哪个路径、获取的具体日期时间，便于和线上状态对应。
• 当前生效状态：如果站点有多个环境或 CDN 缓存，要写清哪一份是线上实际返回的。
• 改动人意图：用一句话说明本次要解决什么，例如“放开某目录抓取”或“屏蔽测试路径”。

这些内容合在一起，才能让接手的人判断原始状态是什么，而不是只看到一份被改过的文件。

具体操作步骤：从取回到归档

可按下面顺序执行，适合多人协作时减少返工：

1. 先获取线上实际返回的 robots.txt，不要凭记忆或本地旧文件代替。若通过命令行获取，可把结果重定向到文件，例如 curl -s https://example.com/robots.txt -o robots-before-20240601.txt；这里的域名和日期只是示例，需替换为真实信息。
2. 打开文件确认内容完整，检查是否存在 BOM、多余空行或编辑器自动转换的换行符。若发现异常，先记录异常，不要直接“修正”后再当原始状态。
3. 把文件另存为带日期或版本标识的副本，例如 robots-before-20240601.txt，并设为只读，避免后续误覆盖。
4. 在副本之外新建一份改动稿，所有修改只在改动稿进行；原始副本不再编辑。
5. 改动完成后，用 diff 类工具对比两份文件，确认每一处变化都是有意为之。
6. 交付时同时给出原始副本、改动稿和一句变更说明，让审核人不必猜测。

如果站点使用版本控制，把原始副本和改动稿一起提交，提交信息写清“改动前状态”和“改动目的”，比只提交最终文件更利于回退。

协作交付时怎样验收保存是否合格

验收信号可以按检查项判断：

• 能否在三十秒内找到改动前的完整文件，而不是只找到差异摘要。
• 原始副本是否未被编辑，修改是否全部发生在改动稿中。
• 对比结果是否只包含预期变化，没有混入换行、空格或注释的意外改动。
• 交付说明是否写清了来源、时间和改动意图，接手人能否据此独立回退。

如果以上任一项做不到，说明保存原始状态还不合格，应先补齐再继续改。注意，保存原始状态只解决协作与回退问题，不代表抓取限制一定能移除索引，也不代表站点地图会被收录；这些是不同层面的判断，需分别核查。

容易出错的保存方式

常见错误包括：只保存改动后的文件、用截图代替文本、把本地未上线版本当作线上原始状态、在原始副本上直接改。还有一种情况是多人各自保存一份，但没有统一命名和时间标记，导致无法判断哪份最新。遇到这种冲突，应先以线上实际返回内容为准重建原始副本，再统一命名规则，而不是继续在多个版本上叠加修改。

下一步可以直接做一次小演练：取回当前 robots.txt，按上述方式存成只读副本，再新建改动稿并做一次 diff。若对比结果清晰、回退路径明确，这套保存方式就可以用于正式改动。