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

搜索引擎抓取：改动前怎样保存原始状态

改动 robots.txt、页面模板或站点结构之前，先把“改动前的原始状态”保存成可回看、可对比、可还原的证据。最小做法是：记录改动时间点，保存原始文件副本，抓取并留存关键 URL 的 HTTP 响应头与页面快照，同时记下当时生效的规则和服务器配置。只复制一份文件不够，因为抓取问题往往出在响应状态、重定向和抓取规则叠加之后的结果上。

先确定要保存哪几类原始资料

从验收目标倒推：改动后如果抓取量下降或重要页面消失，你需要能回答“原来是什么样”。因此原始状态至少要覆盖以下四类资料。

• 规则类原始文件：robots.txt、站点地图文件、页面模板或路由配置、必要的服务器重写规则。保存成带日期的独立副本，不要覆盖原文件。
• 响应类证据：对关键 URL 记录状态码、响应头中的 Content-Type、X-Robots-Tag、Location（重定向时）以及抓取时间。
• 内容类快照：保存关键页面的 HTML 源码或渲染后截图，用于对比改动后是否出现内容缺失、脚本阻塞或结构变化。
• 环境记录：改动时使用的账号、操作人、生效时间、是否走 CDN 或反向代理。这些信息决定“同一份文件为什么表现不同”。

可执行步骤：一次完整的改动前存档

假设你要调整 robots.txt 中一段 Disallow 规则，并按以下顺序执行。示例中的路径和值仅作演示，实际以你的环境为准。

1. 建立存档目录，命名包含日期和操作人，例如 2025-06-01_robots_before。目录内再分 files、headers、snapshots 三个子目录。
2. 复制 robots.txt 原始内容到 files，同时记录文件的修改时间和大小。若站点地图是动态生成的，保存一份当前输出结果，并注明生成方式。
3. 选取 10 到 30 个代表性 URL，覆盖首页、栏目页、详情页、分页、参数页和被规则限制的路径。数量按站点规模调整。
4. 对每个 URL 执行请求，把完整响应头保存为单独文本文件。命令行示例：curl -I https://example.com/page > headers/page.txt。若需要看正文，用 curl -s 保存 HTML。
5. 记录每个 URL 当时是否可被抓取：结合 robots.txt 规则、响应状态码和页面上的 robots 元标签，逐条写明判断结果和依据。
6. 把上述资料提交到版本库或带时间戳的归档位置，确保改动后仍能取回，而不是只留在本地临时目录。

验收标准与责任划分

存档是否合格，可以用三个检查项判断：

• 可还原：仅凭存档目录，能把 robots.txt 和模板恢复到改动前内容。
• 可对比：改动后重新采集同一批 URL，能逐项对照状态码、响应头和内容差异。
• 可追溯：每个文件都有采集时间、采集人和采集方式，出现争议时能说明证据来源。

责任上，执行改动的人负责在改动前完成存档，复核人负责确认关键 URL 清单是否覆盖了业务上最重要的页面。若站点由多方共同维护，应在改动前明确谁保存服务器配置、谁保存内容快照，避免只存了一半。

容易踩空的几个判断点

robots.txt 的抓取限制不等于可靠的索引移除。改动前保存的规则只能证明“当时是否允许抓取”，不能证明页面是否已从索引中消失。站点地图也不保证收录，它只是提交线索。HTTPS 不保证安全无漏洞，也不保证排名。这些边界决定了存档时要区分“抓取层证据”和“索引层证据”，不要把两者混在一份记录里。

另一个常见问题是只保存了文件，没保存响应结果。同一份 robots.txt，在不同 CDN 节点或不同 User-Agent 下可能返回不同内容。因此存档时应记录请求使用的 User-Agent 和请求地址，必要时对多个节点分别采集。若发现现象异常，先列出可能原因——规则误写、缓存未刷新、服务器返回 5xx、重定向链变化——再通过对比改动前后证据逐项排除，不要直接认定是某一个原因。

下一步：按上面的目录结构，先对当前 robots.txt 和 10 个关键 URL 做一次改动前存档，再开始实际修改。