robotstxt改版或迁移时应核对什么，优先保住抓取通道
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /9dee2d8d4814.html
📄
robotstxt改版或迁移时应核对什么，优先保住抓取通道
改版或迁移时，robots.txt 最先要核对的是：它是否仍允许搜索引擎抓取新地址、是否误封了 CSS、JS、图片等渲染资源、是否还指向已失效的旧站点地图。抓取被挡住，后续收录和排名都无从谈起，所以这项工作应排在提交新链接之前。
准备阶段：先备份旧文件并列出差异
动手改站之前，把当前 robots.txt 原样保存一份，记录它的每一行规则。然后列出改版涉及的地址变化：哪些目录改名、哪些子域合并、哪些页面从动态参数变成静态路径。核对的依据不是“看起来差不多”，而是逐条比对旧规则与新 URL 结构是否冲突。
重点检查三类写法：
Disallow是否覆盖了新目录，例如旧规则封了/search，而新站把重要栏目也放在该路径下。Allow与Disallow的先后顺序是否仍符合预期，路径长短不同会导致匹配结果变化。Sitemap行指向的地址是否为新站可访问的站点地图。
如果时间和人手有限，这一步只需产出一张“旧规则—新路径—是否冲突”的对照表，不必重写全部规则。
实施阶段：最关键的一步是确认没有全站误封
本题最关键的一步，是在新站上线后立刻用 Disallow: / 之外的规则做一次抓取测试，确认首页和核心栏目能被正常抓取。全站误封往往来自测试环境残留：开发时为了屏蔽爬虫写了禁止全部抓取的规则，上线时忘了删除。
可以执行的检查方式：
- 在搜索引擎的抓取测试工具中请求新站首页，观察返回的是“允许抓取”还是“被 robots.txt 阻止”。
- 换一个核心栏目页重复测试，确认不是只有首页放行。
- 用
curl直接读取https://新域名/robots.txt，确认返回 200 且内容为预期版本，而不是旧缓存或 404。
判断结果：若返回“被阻止”，先修正规则再继续；若返回 200 但内容是旧版，检查服务器、CDN 或反向代理是否缓存了旧文件。这里要区分“可能原因”和“已定位原因”——抓取失败可能来自规则本身，也可能来自缓存或解析，需逐项排除，不要一看到失败就断定是规则写错。
验证阶段：区分抓取限制与索引移除
robots.txt 只能阻止抓取，不能可靠地把已被收录的旧页面从索引中移除。如果迁移后旧地址仍出现在结果里，正确的处理是让旧地址返回 301 指向新地址，而不是靠 robots.txt 屏蔽。屏蔽抓取反而可能让搜索引擎无法看到跳转信号。
验证时分别核对：
- 新地址是否可抓取、可访问，返回状态码正常。
- 旧地址是否做了 301，且指向最相关的新页面，而非统一跳到首页。
- 站点地图是否只列新地址，并已提交。站点地图不保证收录，它只是帮助发现 URL 的线索。
- 对确实需要移除的页面，使用对应的移除工具或返回 404、410，而不是依赖 robots.txt。
另外，HTTPS 只保证传输加密，不保证站点无漏洞，也不直接等于排名提升，迁移时不要把它当作抓取问题的解决方案。
维护阶段：把核对变成固定检查项
迁移完成后的一段时间内，定期查看抓取统计和站点地图的抓取情况，确认没有新增的误封路径。每次新增目录、调整 URL 规则或更换 CDN 时，重新读一遍线上 robots.txt，而不是只改本地文件。
维护清单可以压缩成三条：线上文件内容与预期一致、核心路径未被阻止、站点地图地址有效。不同搜索引擎对 robots.txt 的支持细节和抓取测试入口不完全相同，需要分别核查，不能只验证一家就认为全部通过。
下一步：打开新站的抓取测试工具，请求首页和一个核心栏目页，确认两者都返回“允许抓取”，再提交新的站点地图。
