robots.txt规则:改版或迁移时应核对什么

📍 WDQWDWQD987AAAAA:216.73.216.59
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /c662a100a6ee.html
📄

robots.txt规则:改版或迁移时应核对什么

改版或迁移时,robots.txt规则最需要核对的是:它是否仍在阻止抓取、是否误伤了新路径、是否与当前站点结构一致。很多迁移事故并非来自服务器宕机,而是旧规则被原样复制到新站,把新目录、新参数或整站都挡在了抓取之外。核对的目标不是让规则更复杂,而是确认它只挡住该挡的,放行该放行的。

先确认新站是否继承了旧站的禁止规则

迁移时常见做法是把旧站的robots.txt直接复制到新站。问题在于,旧站可能因为历史原因禁止了某些目录,而新站恰恰把这些目录当作主要入口。核对时逐条读取Disallow和Allow,问自己:这条规则针对的路径,在新站里还存在吗?如果存在,它是应该被抓取的吗?

可以按下面的顺序检查:

适用条件是:迁移前后URL结构发生变化,或旧站曾用robots.txt做过临时屏蔽。判断结果是:如果发现新站的主要栏目落在Disallow范围内,就应修改规则并重新发布。

核对规则与站点地图、实际URL是否一致

robots.txt里的Sitemap指令只是告诉抓取方站点地图的位置,它不保证收录,也不替代抓取规则。迁移后要确认Sitemap指向的是新域名下的地址,而不是旧域名。如果旧域名已经301跳转到新域名,Sitemap却仍写旧地址,会增加不必要的跳转和混淆。

同时核对三件事:

  1. robots.txt中允许抓取的路径,是否覆盖了站点地图里列出的URL。
  2. 站点地图里是否存在被robots.txt禁止抓取的URL。如果有,要么从地图移除,要么调整规则。
  3. 新站是否还有测试环境、旧版页面、带参数的重复URL被意外放行。

这里要区分抓取限制和索引移除。robots.txt禁止抓取,并不等于页面会从搜索结果中消失;如果页面已被索引,仅靠robots.txt通常无法可靠移除。需要移除索引时,应使用对应的noindex规则,并确保该页面仍可被抓取,否则抓取方读不到noindex。

用实际抓取测试验证规则效果

规则写得对不对,不能只看文本。迁移后应做一次抓取测试,确认关键URL没有被挡。可以使用搜索引擎官方提供的抓取测试工具,或直接请求/robots.txt并用工具模拟抓取。测试时选取首页、主要栏目页、详情页各一个作为样本。

假设某站迁移后把商品页从/product/改为/goods/,而robots.txt仍写着Disallow: /goods/。这时抓取测试会显示商品页被阻止。修改为允许/goods/后重新测试,若返回可抓取,说明规则已生效。这个例子是假设,用于说明核对方法。

验收信号包括:关键URL在抓取测试中显示允许;robots.txt返回200状态;Sitemap地址指向新域名;不存在误伤主要目录的Disallow。

迁移后持续观察抓取与索引变化

规则修改并发布后,还需要观察一段时间。查看服务器日志中抓取方的访问情况,确认新目录有抓取记录。如果发现某个重要目录长期没有抓取,可能是规则、内链或服务器响应的问题,需要逐项排查。不同搜索引擎对robots.txt的支持细节可能不同,应分别用各自的工具核查。

下一步:导出当前robots.txt的所有规则,与新版URL清单逐条比对,把误伤新路径的规则改掉,再用抓取测试验证关键页面。确认无误后,再提交新的站点地图。

图1 图2

nginx