robots协议改版或迁移时应核对什么：别让旧规则挡住新页面
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /f477397c40f1.html
📄
robots协议改版或迁移时应核对什么：别让旧规则挡住新页面
改版或迁移时，robots协议最需要核对的是三件事：新环境里是否还存在一份可访问的robots.txt、其中的Disallow与Allow规则是否仍指向真实路径、以及旧规则有没有把新页面或新目录一并挡住。判断标准不是“文件存在”，而是“抓取规则与当前站点结构一致”。只要路径、子域、协议或目录层级发生变化，旧规则就可能从保护变成障碍。
观察：先确认新站实际返回了什么
迁移后不要只看本地文件或代码仓库。抓取工具读取的是服务器返回的内容，因此要以线上响应为准。可以执行以下检查：
- 访问新站根目录下的
/robots.txt，确认返回状态码是200而不是404或403。 - 查看响应内容是否仍是旧站规则，尤其是带有旧域名、旧目录或旧子域的路径。
- 检查是否存在多条User-agent记录，确认目标抓取工具命中的是哪一段。
- 如果站点同时有测试环境和生产环境，确认测试环境的限制规则没有随配置一起发布到生产环境。
这里要区分“可能原因”和“已经定位的原因”。页面未被抓取，可能是robots.txt禁止、可能是服务器返回异常、也可能是内链或站点地图没有指向新地址。只有看到robots.txt中确实存在匹配的Disallow规则，才能把robots协议列为已定位原因。
判断：哪些改动会让旧规则失效或误伤
以下变化最容易引发问题：
- 目录结构调整。旧站文章在
/blog/下，新站改到/news/，而robots.txt仍写着Disallow: /news/，新内容会被直接挡住。 - 子域或协议变化。从
http迁到https，或从主域迁到子域后，robots.txt需要在新地址下单独确认，旧地址的规则不会自动跟随。 - 多套规则叠加。多人协作时，运维、开发、SEO各自维护一份规则，合并后可能出现互相矛盾的Allow和Disallow。
- 误把robots.txt当移除工具。robots.txt只能限制抓取，不能可靠地让已收录页面从索引中消失。需要移除索引时，应使用对应的noindex或移除请求方式，并分别核查不同搜索引擎的支持情况。
判断某条规则是否误伤，可以把新站需要被抓取的目录逐条与Disallow规则做前缀比对。假设新站需要开放 /product/，而规则中有 Disallow: /prod，由于前缀匹配，/product/ 也会被挡住。这类问题在改版时很常见，必须逐条核对。
处理：按协作交付方式修改并留痕
多人协作时，建议把robots.txt当作需要评审的配置文件，而不是随手改的文本。可执行步骤：
- 从线上拉取当前robots.txt，与代码仓库中的版本做差异对比，确认哪一份是实际生效版本。
- 列出本次迁移涉及的新目录、新子域和需要屏蔽的旧路径，逐条写成待核对清单。
- 修改时保留注释，说明每条规则的用途和负责人，减少后续返工。
- 发布前在测试环境验证规则，发布后再次抓取线上文件，确认返回内容与预期一致。
如果旧站仍需保留一段时间，可以在旧站robots.txt中保留必要的抓取限制，但不要用旧规则去管理新站。新旧两套环境的规则应分别维护、分别核查。
复查：迁移完成后验证抓取与索引状态
规则发布不等于问题解决。复查时至少确认：
- 目标页面在robots.txt中不再被禁止，且返回状态码正常。
- 站点地图中列出的新地址可以被抓取；站点地图本身不保证收录，它只是发现入口。
- 已收录的旧地址是否按计划跳转或保留，避免新旧规则冲突。
- 不同搜索引擎对同一份robots.txt的解析可能不同，必要时应分别用各自的抓取测试工具核查。
复查结果只有两种：规则与当前站点结构一致，或存在需要继续修正的路径。若发现某目录仍被挡住，回到判断环节重新比对规则，不要直接删除整份robots.txt，以免把本该屏蔽的后台或临时目录暴露出来。
下一步：把新站需要抓取的目录和需要屏蔽的路径各列一份清单，与线上robots.txt逐条比对，确认无前缀误伤后再发布变更。
