robots 里 /*?sort= 一条规则把 2 万条详情页封了

商品站从别的项目抄了一段 robots，为了挡排序参数页加了 Disallow: /*?sort=，上线三天后 GSC 里被 robots 屏蔽的网址从 0 涨到两万三千条，详情页的默认排序地址本身也带 ?sort=，一起被封。日志里这些地址全是 200，却再没被抓过，回滚规则后屏蔽数也没马上降。

把日志和配置对完，能解释这个现象的基本就这几处。通配符匹配整条路径，详情页的默认链接里就有 ?sort=，一条规则连正常页一起挡了；列表页和详情页共用一套参数命名，规则没法只针对列表；已经被判为屏蔽的地址不会因为改回 robots 立刻恢复，需要重新被发现；边缘节点缓存了 robots.txt，一半节点还在返回旧规则。

先把线上规则原文拉下来核对

curl -s https://www.example.com/robots.txt

再往下改成只挡列表页的参数组合

Disallow: /list?sort=
Disallow: /list?order=

给详情页的排序参数统一收口

add_filter('wpseo_canonical', function($u){ return strtok($u, '?'); });

等前面都确认过，再逐节点验证 robots 已是新版本

curl -s https://www.example.com/robots.txt | grep -c 'sort'

别只看报错消失，验证要多做一步。GSC 里被 robots 屏蔽的数量一周内回落到两位数，日志中带 ?sort= 的详情页重新出现 200 抓取，索引量同步回升。

提醒一点。通配符写在路径中间最容易误伤，宁可多写两条精确规则，也别用一条覆盖全站的问号匹配。报错文案容易误导，真正的原因往往在相邻那一层的日志里。