这个坑值得记一笔。换主题后详情页源码里出现了两条 rel=canonical，一条指向 https 正式地址，一条指向带 ?utm_source 的地址。GSC 里开始出现带参数的规范网址。
刚开始盯着「插件在页面头部输出，主题在后，解析器取了第一条」，折腾了半个多小时，排掉了。
真正麻烦的地方在于，几个原因的现象几乎一样。主题的 header.php 里手写了 canonical，与插件的输出叠加；手写那条用了当前请求 URI，带上了推广参数；缓存插件把带参数的 HTML 缓存下来，污染更多页面。
数一下页面里有几条 canonical
curl -s 'https://www.example.com/post/1024?utm_source=x' | grep -c 'rel="canonical"'然后删掉主题里手写的那条
grep -rn 'rel="canonical"' wp-content/themes/随后让插件接管并统一去掉跟踪参数
curl -s https://www.example.com/post/1024 | grep -o '<link rel="canonical"[^>]*>'剩下的就是清掉缓存后批量复验
python check_canonical.py --sitemap sitemap.xml --count 1改完先别撤，确认这几项。所有页面只剩一条 canonical 且不带参数，GSC 里带 utm 的规范网址两周内清零，收录量恢复。
canonical 只该有一个来源，主题和插件同时输出是常见事故，换主题后一定检查源码头部。同一份配置在测试环境跑通，不代表线上没事，两边的默认值经常不一样。