先把当时的情况摆出来。列表页 canonical 指向了聚合页，聚合页却带着 noindex，两边都不进索引，栏目流量几乎归零。
原因不止一个，得分开看。聚合页在模板里被统一加了 noindex。少数情况下是canonical 指向了未验证可索引的地址。
不容易想到的是，两个信号冲突时蜘蛛倾向于都不收录。
上来先确认 canonical 目标页的 robots 状态
curl -s https://www.example.com/hub/ | grep -i robots去掉聚合页的 noindex
add_filter('wp_robots', 'allow_hub');剩下的就是确认 canonical 指向的地址返回 200
curl -sI https://www.example.com/hub/ | head -1改之前我把相关日志按时间截了一段存着，事后对时间线用得上。
中途换过一次思路，把范围缩到最小的那一层，反而快了。
恢复的判定其实很直接。聚合页进入索引，列表页的权重传递恢复，栏目流量回升，两个页面都不再互相拖累。
容易忽略的是，canonical 的目标必须是可索引页面，指向 noindex 或 404 都等于自断链路，排查时要连目标页的状态和响应头一起看。监控比日志更早给出信号，事后回看经常能提前半小时发现异常。