一句话：选定一种 URL 形式、在代码里用跳转强制它、让 canonical 标签和 sitemap 与之一致，并接受「已经拆开的索引合并回来要好几周」——这正是为什么应该在发布更多页面之前先修它。
拆开的真实代价
这个实验我们非自愿地在自己身上做过。一处末尾斜杠不一致，让 46 张页面各自以两个 URL 被收录。曝光和平均排名对每个双胞胎分别计算——大约 1,980 次曝光被拆在这些配对之间，两个版本都没能积累到足够信号去排上去。有一篇文章不带斜杠的版本排 39.8 位，带斜杠的排 40.5 位：同一份内容，被评估了两次，在和自己竞争。
什么都不报错。构建通过、页面正常渲染、分析看起来也正常。唯一的症状是什么都排不太上去。
会产生重复的几种形式
| 配对 | 常见成因 |
|---|---|
/page 与 /page/ | 框架默认值与站内链接或 sitemap 不一致 |
www 与裸域 | 服务器层没做跳转，两边都返回 200 |
http 与 https | 换证书之后跳转没做全 |
| 带查询串的变体 | 跟踪参数没被剥离，也没做规范化 |
| 大小写不同的路径 | 服务器不区分大小写，而链接区分 |
按正确顺序修
- 定下形式并在代码里强制，让每个生成的链接、canonical 标签和 sitemap 靠结构而不是靠自觉保持一致。
- 用 301 跳转，并保留路径与查询串。把所有深层 URL 打到首页的跳转是一台软 404 制造机——它为并不存在于那里的内容返回 200，比你正在修的重复问题更糟。
- canonical 标签指向强制后的形式，用绝对地址，每张页面都写，包括规范版本自己。
- 重新提交 sitemap，让合并早点开始。索引稳定下来预计要四到八周。
canonical 是提示，不是指令
canonical 指向一处，而站内链接、sitemap 和跳转链指向另一处，这是一个矛盾；而矛盾是由爬虫来裁决的，不是由你。只有当其余一切已经和它一致时，这个标签才起作用——这意味着标签是最后一步，不是修复本身。
为什么它要排在「发更多页面」前面
重复问题会随站点规模放大。在 400 个 URL 时修它是一次路由改动；在 4,000 个 URL 时修它是同一次路由改动，外加十倍的索引欠账和十倍的等待。如果你打算把页面数做上去，这是要先收掉的那件事。