robots.txt：改版或迁移时应核对什么
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /145564961f74.html
📄
robots.txt：改版或迁移时应核对什么
改版或迁移时，robots.txt 最需要核对的是：它是否仍然准确反映新站的结构、是否误封了需要被抓取的目录、是否还指向旧域名或旧路径，以及它是否被用来承担它做不到的事——比如靠 Disallow 移除已经收录的页面。核对的目标不是“文件存在”，而是“文件与当前站点意图一致”。
先分清两种处理方案：保留原规则，还是重写规则
迁移时通常有两种做法，适用条件不同。
- 保留原 robots.txt 规则：适用于 URL 路径结构基本不变、只是换服务器或换域名的场景。此时重点是确认文件能随新站正常访问，并检查其中是否写死了旧域名。
- 重写 robots.txt 规则：适用于目录结构、语言版本、后台路径或分站方式发生变化的场景。此时旧规则可能指向已不存在的路径，或漏掉新增的需要屏蔽的区域。
判断依据是：把新旧两版的 URL 清单各列一份，逐一比对哪些路径被抓取、哪些被屏蔽。如果差异只涉及域名，保留加替换即可；如果差异涉及目录层级，就应重写。
从交付结果倒推要核对的内容
改版上线后，你希望得到的结果是：新站可被抓取页面正常被抓取，不该被抓取的页面不被抓取，旧 URL 的处置符合迁移策略。倒推回来，robots.txt 至少要核对以下几项。
- 文件可访问性：新环境下
/robots.txt是否返回正常状态，而不是 404 或跳转到首页。 - User-agent 分组：是否针对需要区别对待的爬虫单独写了规则，还是全部用
*覆盖。 - Disallow 路径：每条被屏蔽的路径是否仍然存在、是否仍然应该被屏蔽。改版后旧路径常被新路径取代，屏蔽清单要同步更新。
- Allow 与 Disallow 的冲突：同一爬虫分组内，更长匹配的规则通常优先，但要逐条确认意图，不要依赖记忆。
- Sitemap 指令：里面写的站点地图地址是否指向新域名，且该地址可访问。站点地图只是发现线索，不保证收录。
- 旧域名残留：文件内是否还有旧域名、旧 CDN 地址或旧目录名。
容易踩错的三个判断
第一，把 Disallow 当成移除工具。robots.txt 的抓取限制不等于可靠的索引移除。已被收录的 URL 即使被屏蔽，仍可能出现在结果中，因为爬虫无法重新抓取确认内容变化。需要移除时应使用对应的移除或更新机制，而不是只加一条 Disallow。
第二，屏蔽了整站却不自知。迁移时若临时加了 Disallow: / 做测试，上线后忘记删除，会导致新站无法被抓取。核对时要把这一条单独列为检查项。
第三，以为 robots.txt 对所有搜索引擎效果一致。不同搜索引擎对指令的支持情况须分别核查，尤其是非标准扩展指令。不要假设一处生效即处处生效。
责任与验收怎么定
改版项目里，robots.txt 常处于“开发以为 SEO 管、SEO 以为运维管”的缝隙。建议明确：由谁在新环境部署文件，由谁在迁移后逐条比对规则，由谁在验收时确认屏蔽清单与抓取需求一致。
验收时可执行的最小步骤是：迁移完成后，用新域名访问 /robots.txt，确认返回内容与预期版本一致；再挑一条被 Disallow 的路径和一条允许抓取的路径，分别确认其实际状态码与内容是否符合迁移策略。若被屏蔽路径返回 200 且内容仍可访问，说明该屏蔽是否保留需要重新判断。
假设某站迁移时把后台路径从 /admin/ 改为 /manage/，而 robots.txt 仍只屏蔽 /admin/，那么新后台路径就处于可被抓取状态。这类差异只能靠新旧路径清单比对发现，不能靠肉眼扫一遍文件。
下一步：把当前 robots.txt 的每条规则与迁移后的 URL 清单做一次逐条对照，标出“保留、修改、删除”三类，再据此生成新版本并安排验收。
