先分清：差异是“字符串差异”还是“资源差异”

URL 本质上是一串字符，但判断它是不是同一个页面，看的不只是字符串，还要看服务器怎么响应。同一份 HTML，如果两个地址都返回 200，且内容一致，索引里就有可能出现两版；如果其中一个 301 到另一个，通常只会保留目标地址。

所以处理这类问题，第一步不是急着写 canonical，而是先看服务器对几个变体分别返回什么。

三类常见的 URL 变体

1. 大小写

在 Linux 环境下，路径部分通常区分大小写，/About 和 /about 很可能被当成两个不同地址，各自返回 200。而在一些 Windows 环境或部分框架路由下，两者指向同一页面，但返回的仍是 200 而非重定向。前者容易产生两份副本，后者容易出现“两个地址、同一内容”的情况。

域名部分不区分大小写，这一块基本不用担心。

2. 结尾斜杠

/news 和 /news/ 是否等价，取决于服务器配置。有的服务器会自动 301 到带斜杠的版本，有的则两者都能正常打开。如果两者都返回 200，就形成了两个可访问地址。

这类问题常出现在目录页和列表页上。检查方法很简单：分别访问两个地址，看返回码和最终 URL。

3. 追踪参数与排序参数

?from=wechat、?utm_source=xxx、?sort=price 这类参数，如果服务器不做处理，会生成大量只差参数的地址。它们往往内容相同或高度相似，却各自能被访问、被链接、被抓取。

真正需要保留的，是那些会改变页面内容的参数，比如分页、筛选、排序。纯粹用于统计来源的参数，一般没有必要让它们生成独立页面。

优先用哪几种方式收口

1. 服务器层重定向：把不想要的变体 301 到规范地址。这是最干净的做法，因为它在抓取阶段就把两个地址合并成一个。
2. canonical 声明：无法做重定向时，用 canonical 指向规范版本。它属于提示，不保证一定被采纳。
3. 站内链接统一：内链、导航、站点地图里都用同一个版本的地址。链接本身就在不断强化哪个是主版本。
4. robots.txt 或参数处理工具：对于纯追踪类参数，可以在工具里声明忽略，或在 robots.txt 里挡掉特定参数组合。注意这挡的是抓取，不是收录，已经收录的地址不会因此消失。

一个常见的误区：以为加了 canonical 就万事大吉。如果站内到处链接的都是另一个版本，canonical 的作用会被明显削弱。

怎么验证处理是否生效

• 用不带缓存的请求分别访问各个变体，记录返回码和跳转链。
• 在服务器日志里看这几个地址的抓取情况，观察是否还有大量重复抓取。
• 过一段时间看索引覆盖，确认重复地址是否在减少。这个过程通常需要几周，不会立刻见效。

几个容易忽略的细节

第一，跳转链不要超过一跳。A 跳 B、B 跳 C 会延长处理时间，也容易在中间环节丢失信号。

第二，不要用 JavaScript 做归一。抓取阶段拿到的往往是不执行脚本的 HTML，指望前端跳转来合并地址，很多情况下不会生效。

第三，已经收录的地址不用急着删。做好重定向后，索引会随着重新抓取慢慢更新。急着返回 404，反而可能让用户和爬虫都收到错误信号。

第四，规范地址本身要稳定。如果规范版本响应慢、经常报错，那这套归一就没有意义。

总结一句：URL 归一不是为了“看起来整齐”，而是为了让同一份内容只有一个入口，让抓取和索引的位置都集中在一个地址上。先看服务器怎么响应，再决定用重定向还是 canonical，最后用日志和索引报告验证结果。