改版或迁移时,robots文件最需要核对的是:它是否仍然指向正确的站点结构、是否误屏蔽了应该被抓取的新路径、是否把旧规则原样搬到了新域名或新目录下。一个常见的错误是迁移后直接沿用旧robots文件,结果新站的核心栏目被旧规则挡住,或者旧站的屏蔽规则被带到新站,导致页面长期无法被抓取。核对的目标不是让robots文件“更好看”,而是确认它在新环境下不会产生意外的抓取限制。
如果你发现新站上线后,搜索引擎抓取量明显下降、新页面迟迟不出现、或者站点地图中的URL被大量标记为“已被robots.txt阻止”,就需要优先检查robots文件。这些现象可能有多个解释,robots规则只是其中一种可能,不要直接断定就是它造成的。可以按下面几步收集证据:
/robots.txt,确认返回的是新站内容,而不是旧站缓存或CDN上的旧文件。Disallow: /这类全站屏蔽规则,尤其是从测试环境复制过来的配置。如果以上检查发现规则与新站结构不匹配,就可以进入判断环节。如果全部正常,问题可能出在别处,比如服务器返回状态码、页面 canonical 设置或内链结构,不应继续在robots文件上反复修改。
迁移场景下,robots文件的风险主要集中在三类规则上。第一类是路径规则。旧站可能屏蔽了/search/或/tmp/,新站如果把这些路径改成了正式栏目,旧规则就会误伤。第二类是域名或子目录规则。从子目录迁移到独立域名时,旧规则里针对子目录写的Disallow可能不再适用,但被原样保留。第三类是Sitemap指令。迁移后站点地图地址通常变化,如果robots文件里的Sitemap仍指向旧地址,会影响搜索引擎发现新地图的效率,虽然站点地图本身不保证收录。
判断时可以问自己:这条规则屏蔽的路径,在新站里是否仍然是需要屏蔽的?如果新站已经删除了该路径,规则留着无害但也没有必要;如果该路径在新站变成了重要内容页,就必须删除或改写规则。另外要注意,robots.txt的抓取限制不等于可靠的索引移除。即使页面被Disallow,如果外部链接指向它,它仍可能出现在搜索结果中,只是摘要信息可能受限。所以迁移时不要把robots文件当作删除旧页面的手段。
下面是一套可以实际执行的核对流程,适用于域名更换、目录结构调整或整站改版后的上线检查。
/robots.txt,确认内容来自新服务器,而不是CDN缓存、旧站备份或测试环境残留。Disallow: /或针对/*的过度屏蔽规则。如果迁移期间需要临时全站屏蔽,上线后必须记得移除,并复查。Sitemap后面的地址改成新站的站点地图URL。如果站点地图有多个,逐条列出。注意站点地图不保证收录,它只是帮助发现URL。/robots.txt,确认返回200状态码且内容正确。然后观察一段时间内服务器日志中搜索引擎的抓取请求,确认之前被误屏蔽的路径开始出现抓取记录。如果抓取仍然为零,继续排查是否有其他阻止因素,比如防火墙、登录墙或页面返回错误状态码。第一个细节是大小写和路径结尾。robots.txt中的路径匹配通常是区分大小写的,旧规则写的是/Search/,新站路径是/search/,屏蔽可能不会按预期生效,也可能误伤。第二个细节是HTTPS迁移。从HTTP换到HTTPS时,robots文件本身通常不受影响,但如果你在旧HTTP站保留了robots文件并继续屏蔽某些路径,而新HTTPS站没有对应规则,行为可能不一致。HTTPS不保证安全无漏洞,也不直接保证排名,它只是迁移中需要一并核对的一个变量。
完成上述核对后,下一步是建立一份迁移检查清单,把robots文件核对和站点地图提交、重定向规则、 canonical 设置放在同一轮上线复查中执行,避免只改其中一项就认为迁移完成。