记录一下那天晚上的排查过程。必应站长工具的 URL 规范化提示 4000 多组地址指向同一内容，成对出现的是 /p/123 和 /p/123/ 两种写法，还有带 ?utm_source=rss 的版本。站点刚升到 WordPress 6.7，固定链接结构没动，主题在末尾加了斜杠，插件又在 RSS 里拼了跟踪参数。
刚开始盯着「canonical 输出不带斜杠的地址，与实际返回的地址不一致」，折腾了半个多小时，排掉了。
原因不止一个，得分开看。服务器对 /p/123 和 /p/123/ 都回 200，没有统一跳转。也可能是RSS 模板把 utm_source 拼进正文链接，外站转载时一起带走。
另外，CDN 忽略尾斜杠，回源时又补上，两次请求落到不同缓存键。
上来先抽一对地址看返回码是否都是 200
curl -s -o /dev/null -w '%{http_code} %{redirect_url}\n' https://www.example.com/p/123 https://www.example.com/p/123/然后在 Nginx 里统一补斜杠并给 301
rewrite ^/(.+[^/])$ /$1/ permanent;接着把 canonical 写成带斜杠的固定地址
wp post meta update 123 _yoast_wpseo_canonical https://www.example.com/p/123/去掉 RSS 模板里的跟踪参数后重新抓取
grep -rn 'utm_source' wp-content/themes/别只看报错消失，验证要多做一步。规范化列表里的成对条目两周内清零，canonical 与返回地址完全一致，CDN 缓存命中率跟着回升。
补一句。跟踪参数只该出现在投放链接里，站内输出带上它，等于主动给蜘蛛造重复页。拖得越久，排查成本越高，因为现场状态会被后续操作覆盖。