很多站点上线几年之后，索引里会多出一批看起来一模一样的 URL：同一篇文章，既有 /News/123，也有 /news/123；有的带尾斜杠，有的不带；http 和 https 各存一份；www 和裸域各存一份。它们指向同一个页面，却占了好几个索引位置。
这些变体通常从哪里来
- 内链写法不统一：不同编辑、不同模板输出的链接格式不一样。
- 程序自动补全：CMS、分页组件、面包屑各生成一套规则。
- 历史遗留：改版、换域名、迁移目录时，旧写法没有完全清掉。
- 服务器差异：Linux 下路径大小写敏感，Windows/IIS 默认不敏感，同一套代码换个环境就多出一批 URL。
- 外部来源：外链、分享、二维码、第三方工具按自己的习惯拼地址。
为什么值得专门花时间收口
- 抓取预算被摊薄。同一份内容被抓多次，真正需要更新的页面来得就少了。
- 收录量虚高。报表数字涨了，不代表有效页面变多，排查问题时还会被干扰。
- 信号分散。外链、点击、停留时间被拆到多个地址上。
- 日志失真。统计抓取分布时，同一个页面在日志里出现好几行，看不出真实热度。
收口的顺序
顺序比工具重要，先做影响面最大的那一层。
- 先定主形态。协议用哪个、主机名用 www 还是裸域、路径是否带尾斜杠、大小写规则如何，一次性定死并写成文档。
- 在服务器层做 301。这是最彻底的一层，浏览器和爬虫都会被带到主形态。相比 canonical，301 是硬信号，不依赖对方配合。
- 改写站内链接。导航、面包屑、分页、正文内链、sitemap 全部输出主形态，从源头减少新变体产生。
- canonical 兜底。对无法用 301 处理的场景，比如带参数但可访问的地址，用 canonical 指向主版本。
- 顺手统一静态资源与接口。图片、CSS、JS、API 地址同样会有协议和主机名不一致的问题，一起改成本最低。
- 观察一段时间。看日志里旧写法是否还在被请求，看索引状态里变体是否在减少。
常见坑
- 大小写规则误伤。把全站路径强制转小写，可能撞上本来靠大小写区分的内容，也可能让带签名的 URL 失效。
- 尾斜杠跳转成环。服务器、CDN、程序各写一条规则，互相跳来跳去，最后报重定向次数过多。
- https 强跳时机不对。证书还没配好就先把 http 全部跳过去，会直接打不开。
- HSTS 上得太早。浏览器一旦记住，回退成本很高，确认稳定后再开。
- 只看 canonical 不看 301。canonical 是提示，遇到冲突时搜索引擎可能按自己的判断处理。
一份简单的自查清单
- 主形态是否明确写下来，团队是否都知道。
- 随机抽 20 条内链，检查协议、主机名、尾斜杠是否一致。
- 带 www 和不带 www 的地址各访问一次，看是否只剩一次跳转。
- 把路径改成全大写访问一次，看是否回到主形态。
- sitemap 里的 URL 是否全部为主形态。
- 日志里旧写法的请求量是否在逐周下降。
URL 收口属于一次性的工程活，但需要周期性复查，因为新模板、新活动页、新同事都会带进新的写法。
做完这些，不会立刻让收录数字变好看，但能让后续所有关于收录、抓取和日志的判断建立在更干净的数据上。