robots.txt文件改版或迁移时应核对什么：先看路径、规则与线上返回
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /7b2cc7b05964.html
📄
robots.txt文件改版或迁移时应核对什么：先看路径、规则与线上返回
改版或迁移时，robots.txt文件最需要核对的是三件事：它是否还能被正确访问、里面的规则是否仍指向真实存在的路径、以及它是否在无意中挡住了不该挡的目录。robots.txt只表达抓取限制，不等于可靠的索引移除；它放行也不保证收录。因此核对目标不是“让它存在”，而是确认交付后的文件与线上实际结构一致。
先确认交付物：文件位置与访问结果
robots.txt必须放在域名根目录下，例如 https://example.com/robots.txt。改版或迁移后，先确认这个地址返回的是纯文本内容，而不是首页、404页面或登录跳转。若返回HTML，抓取方通常不会把它当作有效规则。
- 检查项：用浏览器直接打开根目录下的robots.txt，确认显示的是规则文本。
- 检查项：查看响应状态。200表示可读取；301或302要确认最终落点是否仍在同一域名根目录；404或403说明文件缺失或被拦截。
- 检查项：确认没有把robots.txt放进子目录，例如
/new/robots.txt，除非你明确知道它不会替代根目录文件。
判断结果：如果根目录返回404，但子目录里有一份新文件，线上实际生效的仍是根目录状态，不能按“已配置”验收。
再核对规则：Allow、Disallow与路径是否匹配新结构
迁移常把旧目录改成新目录，例如从 /old/ 改为 /product/。此时要逐条核对Disallow和Allow里的路径是否仍对应真实目录。规则写的是路径前缀，不是页面标题或参数含义，改版后路径变了，旧规则可能挡住新页面，也可能放行本该挡住的测试目录。
- 列出线上实际存在的主要目录和需要抓取的关键路径。
- 对照robots.txt中的每一条Disallow，确认它挡住的路径是否确实不该被抓取。
- 检查Allow是否误放了后台、购物车、搜索结果页等动态路径。
- 若使用通配符或结尾符号，确认它们的作用范围符合预期，而不是凭感觉判断。
假设示例：某站迁移后新文章路径为 /article/，但robots.txt仍写着 Disallow: /article/，这是从旧测试环境复制来的规则。结果抓取方不会抓取新文章目录。这个例子说明必须用实际路径逐条比对，不能只看文件是否存在。
区分抓取限制与索引移除，不把两者混为一谈
robots.txt的Disallow是抓取限制，不是可靠的索引移除手段。若某个URL已被索引，仅靠Disallow通常不能让它在短时间内从搜索结果中消失，因为抓取方可能无法读取页面上的noindex指令。需要移除索引时，应优先让页面可抓取并返回noindex，或使用相应搜索引擎提供的移除工具，而不是只改robots.txt。
另外，站点地图不保证收录，HTTPS也不保证安全无漏洞或排名。核对robots.txt时不要把它当成收录或排名的开关，它只解决“是否允许抓取”这一层问题。
迁移后要留证据：状态、内容与时间点
为了在出现流量或收录波动时定位原因，改版或迁移交付时应保留以下资料：
- 迁移前后robots.txt的完整文本与抓取时间。
- 根目录URL的响应状态与最终跳转地址。
- 与站点地图、主要目录清单的对照记录。
- 谁负责修改、谁负责验收、发现问题后的回滚方式。
判断结果：如果只有一份“已上传”的说明，没有线上返回内容和时间点，出现抓取异常时就无法判断是规则写错、文件没生效，还是路径本身已变更。不同搜索引擎对robots.txt的支持细节须分别核查，不能只测一个就认定全部通过。
下一步：用浏览器或命令行读取当前域名的根目录robots.txt，把返回状态和规则文本复制到迁移核对表中，再与线上目录清单逐条比对。发现路径不匹配时，先修正规则并记录修改时间，再观察抓取日志中的对应请求。
