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

百度爬虫改动前怎样保存原始状态：先做可回退快照

改动 robots.txt、页面模板、URL 结构或服务器配置前，保存“原始状态”的核心不是备份整站，而是先记录百度爬虫当前能看到的版本：文件原文、HTTP 响应头、页面可访问状态和抓取入口。最省事的做法是：把关键文件按原样复制到独立目录，同时用命令行保存响应头与状态码。这样一旦改动后抓取异常，你能拿出改动前的证据逐项对比，而不是凭记忆回滚。

先确定哪些对象算“原始状态”

对百度爬虫而言，它实际接触的是“响应”，不是你的本地文件。因此原始状态至少要覆盖四类对象：

• 规则文件原文：robots.txt 的完整内容，包括注释和空行，不要重新排版。
• HTTP 响应信息：状态码、Content-Type、Last-Modified、重定向链。
• 页面可见内容：改动涉及的那几个模板页或栏目页的 HTML 快照。
• 抓取入口：站点地图地址、内链入口、必要的登录或 CDN 放行配置。

时间人手有限时，不要全站抓取。优先保存“改动会直接影响”的那一小块，例如只改 robots.txt，就只存 robots.txt 和几个代表性 URL 的响应头。

用命令保存，比手动复制更可靠

手动复制容易漏掉响应头，而百度爬虫判断是否抓取，恰恰依赖响应头。可以用下面这组命令建立快照目录：

mkdir -p snapshot_before/headers && cp robots.txt snapshot_before/robots.txt.bak

再对每个代表性 URL 保存响应头：

curl -sSI https://example.com/ > snapshot_before/headers/home.txt

如果要连页面正文一起存，用 curl -sS https://example.com/ -o snapshot_before/home.html。注意把示例域名换成你自己的域名；这里只演示方法，不代表任何具体站点。

保存后立刻做一次检查：打开 home.txt，确认里面有状态码和 Content-Type；打开 robots.txt.bak，确认和线上内容逐字一致。如果响应头文件是空的，说明请求被拦截或域名写错，这份快照不能用。

快照要能回答“改动前后哪里不同”

只保存不对比，等于没保存。建议在改动前先记录三个基线值：

1. robots.txt 是否允许抓取目标目录，用原文对照即可，不要只记“允许”或“禁止”。
2. 目标 URL 返回的状态码，例如 200、301 还是 403。
3. 页面标题和主要正文是否与线上一致。

改动后用同样命令再抓一次，把两份响应头并排看。如果改动前是 200、改动后变成 403，问题多半出在服务器规则、CDN 或权限配置，而不是 robots.txt。如果改动前 robots.txt 允许、改动后禁止，那就是规则文件本身的问题。这种对比能帮你把“可能原因”缩小到“已经定位的原因”。

时间和人手有限时的处理顺序

按代价从低到高排：

• 先存 robots.txt 原文，成本最低，影响面最大。
• 再存改动涉及页面的响应头，几分钟即可完成。
• 最后才考虑存页面正文快照，只在模板或内容改动时做。

适用条件是：你只改一处配置或一个模板。如果改动涉及整站 URL 重写，单靠文件快照不够，还需要保留旧 URL 列表，否则回滚时无法还原入口。判断结果是：快照能逐字还原规则文件、能证明改动前某个 URL 返回什么状态，才算合格；只能还原页面外观、还原不了响应行为，就不合格。

需要留意的边界

robots.txt 的抓取限制不等于可靠的索引移除，改动它也不会立刻改变百度已收录的结果；站点地图不保证收录，保存它只是保留入口证据。HTTPS 不保证安全无漏洞或排名。若改动涉及百度搜索资源平台里的具体配置项，应以你账号内当前可见的界面为准，不要照搬旧版入口描述。

下一步：在改动前先执行一次 curl -sSI 并保存 robots.txt 副本，然后才动配置。改完立即用同一命令复抓，两份响应头不一致时先回滚，再逐项排查。