记录一下那天晚上的排查过程。主题的分页链接是 /page/2/，但翻页按钮里有旧代码拼出 ?paged=2，两种地址都能打开同一批内容，GSC 里两套都被索引。
刚开始盯着「站内搜索和归档页也带 paged 参数，混在一起」，折腾了半个多小时，排掉了。
排查方向其实有限，先把可能性排一排。旧模板的分页函数没有同步替换。少数情况下是canonical 按当前 URL 输出，两套地址各自自指。
另外，外链曾指向 ?paged=2，蜘蛛据此反复抓取。
先确认两套地址都能访问
curl -sI 'https://www.example.com/category/seo/?paged=2'给参数版加规范地址
add_action('wp_head', function(){ if(isset($_GET['paged'])){ echo '<link rel="canonical" href="https://www.example.com/category/seo/page/2/">'; } });接着统计残留的参数地址请求
awk '{print $7}' access.log | grep -c 'paged='等前面都确认过，再确认静态版返回正常
curl -sI https://www.example.com/category/seo/page/2/ | head -1别只看报错消失，验证要多做一步。参数版都带指向静态版的 canonical，GSC 里重复地址数量在两周内下降，日志里 paged= 请求只剩少量外链来源。
容易忽略的是，Nginx 的 rewrite 不匹配查询串，真要 301 得在应用层做，写错规则会连正常页面一起跳。拖得越久，排查成本越高，因为现场状态会被后续操作覆盖。