现场是这样的。季度巡检只查状态码和标题，三百条 canonical 指错的问题跑了三个月才发现，受影响页面全被合并到别的地址。
中间走过弯路，把「多域名并存时 canonical 写成了测试域名」当成主因，改完现象没变。
真正麻烦的地方在于，几个原因的现象几乎一样。巡检脚本只判断 200 和 title；canonical 由模板生成，改版后没做回归；巡检报告没有字段级对比。
巡检里加上 canonical 抽取
curl -s https://www.example.com/post/1024 | grep -o '<link rel="canonical"[^>]*>'批量抽取后与地址清单比对
for u in $(cat urls.txt); do echo $u; curl -s $u | grep canonical; done接着抽查指错的页面
curl -s https://www.example.com/post/1024 | grep canonical等前面都确认过，再确认修正后的指向
curl -s https://www.example.com/post/1024 | grep -c 'canonical'改之前先确认了最近有没有人动过配置，避免白查一遍。
这次没动代码，只在配置和运行环境上找原因。
怎么算真的好了，看的是同一批现象。下一轮巡检能直接列出 canonical 与地址不一致的页面，修正后数量归零。
这里还有个坑。状态码正常不代表页面正常，canonical、robots 这类字段级检查要单独加进巡检。如果同一现象隔几天又出现，说明根因没找到，别当偶发处理。