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

爬虫控制改动前怎样保存原始状态：先留可回滚证据

改动爬虫控制规则前，保存原始状态的核心做法是：把当前生效的规则文件、响应头、页面可见内容和访问日志同时留档，并记录采集时间与采集方式。只复制一份 robots.txt 往往不够，因为爬虫实际看到的可能是 CDN、反向代理或服务端动态生成后的结果。留档的目标不是备份好看，而是改动后能逐项对比，判断差异来自规则本身、部署环节还是缓存。

准备：确定要保存哪些原始状态

爬虫控制通常涉及 robots.txt、meta robots、X-Robots-Tag、canonical、站点地图和服务器访问日志。改动前至少保存以下内容：

• robots.txt 的原始响应体，以及 HTTP 状态码、Content-Type、响应头。
• 目标页面的 HTML 源码中与抓取、索引相关的标签，例如 <meta name="robots"> 和 <link rel="canonical">。
• 关键 URL 的 HTTP 响应头，重点看 X-Robots-Tag、Cache-Control、Last-Modified。
• 站点地图文件的当前版本和最后修改时间。
• 改动前一段时间的爬虫访问日志，按 User-Agent 和状态码统计。

如果站点使用 CDN 或 WAF，还要注明规则是在源站生效还是边缘节点生效。判断依据是：用不同网络环境请求同一 URL，对比响应头是否一致；如果边缘节点返回的 robots.txt 与源站文件不同，说明存在多层控制，改动前必须把两层状态都保存下来。

实施：用可复核的方式留档

推荐把留档做成带时间戳的目录，而不是随手另存为文件。假设目录名为 crawl-control-baseline-20250601，可以按下面的顺序操作：

1. 用命令行抓取 robots.txt 并保存完整响应：curl -i https://example.com/robots.txt -o robots-before.txt。其中 -i 会保留响应头，便于之后核对状态码和缓存字段。
2. 抓取首页和几个代表性栏目页的 HTML：curl -s https://example.com/ -o home-before.html。不要只保存浏览器渲染后的截图，源码里的 meta 标签才是需要对比的对象。
3. 记录响应头：curl -I https://example.com/ > headers-before.txt。如果站点区分移动端和桌面端，两种 User-Agent 都要各抓一次。
4. 导出访问日志中最近 7 天的爬虫请求，按状态码和路径汇总，保存为 CSV 或纯文本。
5. 在留档目录里写一个 README.txt，记录抓取时间、使用的命令、请求时带的 User-Agent、是否经过代理。缺少这些信息，事后无法判断差异是不是环境造成的。

最关键的一步是保存“爬虫实际看到的响应”，而不是“后台编辑器里显示的内容”。如果后台显示某页面允许抓取，但边缘节点给爬虫返回了不同的 X-Robots-Tag，以后者为准。适用条件是：站点存在 CDN、反向代理、多语言分发或服务端渲染；判断结果是，如果两者不一致，改动前应以实际响应作为基线，并在留档中标注冲突位置。

验证：改动后如何对比原始状态

改动完成后，用与留档时相同的命令、相同的 URL、相同的 User-Agent 再抓一遍，然后逐项对比。对比时不要只看文件内容是否变化，还要看响应层：

• robots.txt 状态码是否仍为 200，是否被重定向到其他地址。
• 目标页面的 meta robots 是否从允许变为 noindex，或反之。
• X-Robots-Tag 是否新增、删除或改变了作用范围。
• canonical 是否指向了不同 URL。
• 访问日志中爬虫命中规则后的状态码是否出现大量 403、404 或 5xx。

如果对比发现差异，先判断是预期改动还是意外副作用。例如，只改了 robots.txt 的 Disallow，却观察到页面响应头也变了，可能原因包括部署脚本顺带更新了配置、CDN 缓存刷新导致旧头失效，或者源站和边缘节点规则不同步。此时不要直接断言是某一种原因，应分别用回源请求和边缘请求各验证一次，确认差异出现的层级。

维护：让原始状态可追溯

留档不是一次性动作。每次改动爬虫控制规则前，都应在上一版基线之上新建目录，并保留改动说明。维护时可以执行这些检查：

• 基线目录是否包含响应头、HTML、日志摘要和采集命令。
• 是否记录了改动人、改动时间、改动范围和回滚方式。
• 改动后是否用同一套命令复测，而不是只靠后台预览。
• 如果使用版本控制管理 robots.txt 或配置，提交信息是否写明了改动目的。

需要区分的是：robots.txt 的抓取限制不等于可靠的索引移除，它主要约束遵守规则的爬虫行为；站点地图不保证收录；HTTPS 也不保证安全无漏洞或排名。不同搜索引擎对同一规则的支持情况可能不同，涉及具体搜索引擎时，应分别查看其官方文档并用实际抓取结果核对。

下一步可以选定一个代表性 URL，按上面的命令抓取一份基线，再执行一次小范围改动，用相同命令复测并记录差异。这样得到的对比结果，比只保存一份 robots.txt 更能支撑后续判断。