为什么同一个页面会有多个地址
很多时候不是站外链接带来的，而是站内自己生成的。同一个页面，在浏览器里看起来一模一样，在蜘蛛眼里却是若干个互不相干的 URL。
- 大小写不同：/About/ 和 /about/ 在多数服务器上会被当成两个地址。
- 尾斜杠有无：/about 与 /about/ 是否合并，取决于服务器配置。
- 默认文件名：/about/ 与 /about/index.html。
- 协议与主机名：http 与 https、带 www 与不带 www 的版本同时可访问。
- 参数顺序与无关参数：?a=1&b=2 与 ?b=2&a=1，以及后面拖着 ?from=xxx 之类的追踪参数。
- 排序、筛选、分页参数生成的大量变体地址。
- 移动版、打印版等历史遗留地址。
这些地址只要能被访问、能被链接到，蜘蛛就可能把它们各自排进抓取队列。
蜘蛛不会自动替你合并
内容相同并不等于蜘蛛知道它们是同一个页面。对抓取系统来说，每个 URL 是一条独立记录：各自入队、各自抓取、各自判断。由此带来的直接后果有几个：
- 抓取次数被重复消耗。同一份内容抓了五遍，本该用在其他页面上的机会就被占掉了。
- 站内链接分散到不同版本，页面收到的链接信号被拆成几份。
- 日志里出现大量难以判断归属的地址，排查问题时干扰很大。
不要指望蜘蛛聪明到替你挑出规范地址。它更擅长按你给出的线索走，而不是猜你的意图。
收敛的常规做法
站内链接只输出一个版本
这是最省事也最有效的一步。导航、面包屑、列表、正文里的内链，全部统一到同一种写法：固定协议、固定主机名、固定尾斜杠规则。站内自己都不一致，外部再怎么做都很难收口。
301 与 canonical 的分工
如果某个变体地址确实存在（老链接、历史结构），用 301 跳到规范地址更干净；如果两套地址都必须能直接访问（例如多域名或多端），可以用 rel=canonical 指明首选版本。要注意 canonical 是提示而非强制指令，它和 301、内链、Sitemap 给出的信号越一致，越容易被采纳。
参数收口
排序、筛选、会话、追踪这几类参数最容易生出无穷变体，常见处理方式：
- 追踪参数在服务端识别后 301 跳回干净地址，而不是直接渲染。
- 筛选组合页如果内容重复度很高，考虑用 robots.txt 或 noindex 收口，只保留有价值的组合。
- 保持参数顺序固定，避免同一组参数以不同顺序出现。
Sitemap 只放规范地址
Sitemap 是线索清单，不是全量清单。把变体地址也写进去，等于主动告诉蜘蛛这些都要抓。只放规范版本，并且让它和站内链接、canonical 的指向保持一致。
服务器与跳转也要一致
配置层面的不一致同样会制造变体。比如不同节点对同一路径返回的跳转目标不同、http 版本没有统一跳到 https、尾斜杠处理在不同目录规则下结果不一样。这类问题通常不会立刻暴露，而是慢慢在日志里堆积成一批零散地址。改完规则后，最好用几条固定的测试 URL 在多节点上分别请求一次，确认返回的状态码和 Location 完全一致。
怎么检查有没有漏网
- 翻服务器日志，把带参数的 URL 单独拎出来，看占比和抓取频次是否异常。
- 看站内链接写法是否有多种版本混用，尤其是列表页和分页组件。
- 抽查新发布的页面，确认它只有一个可访问的主地址，其他入口都指向它。
- 观察一段时间，看重复地址的抓取次数是否在下降。
URL 变体不是清理一次就结束的事。新的模板、新的参数、新的跳转规则都可能重新制造一批地址。把统一写法当成发布流程里的固定检查项，比事后补救轻松得多。