核对收录时经常会遇到一种情况：明明只有一个页面，site 查询里却出现好几条结果，点开内容几乎一样，只是地址略有差别。多数时候这不是搜索引擎收错了，而是同一份内容可以通过多个 URL 变体访问，这些变体被抓取后各自留下了索引记录。
变体 URL 通常从哪来
- 大小写混用：/About 和 /about 在某些服务器上指向同一页面，在另一些服务器上则被当作两个地址。
- 协议不统一：http 与 https 同时可访问，或者 https 页面里仍残留 http 的内链。
- 主机名不统一：带 www 与不带 www 都能正常打开。
- 尾斜杠差异：/list 与 /list/ 都返回 200。
- 默认文件名：/news 与 /news/index.html 同时可访问。
- 参数顺序或冗余参数：/p?id=1&from=list 与 /p?from=list&id=1 被视为不同地址。
这些地址在服务器层面都是活的，蜘蛛抓到的每一个都可能被独立评估。问题不在于产生过一次，而在于内链、外链、sitemap、分享链接各指向不同版本，时间一长就分散成了多条索引记录。
先做一份变体清单，再谈处理
处理之前要先知道有哪些变体在流通。可以用站内链接抽取的方式把全站链接跑一遍，再加上服务器日志里出现过的请求路径。清单至少记录三列：变体地址、返回状态码、当前 canonical 指向。如果站点规模不大，用 site 查询配合几种写法交叉看一遍也能大致摸清。清单的价值在于，它能把感觉上的重复变成具体是哪几个地址，后面每一步核对都要拿这份清单比对。
三种归一化手段，作用范围不同
301 重定向
最彻底的做法。把非首选版本在服务端重定向到首选版本，蜘蛛抓到时得到的是跳转信号，通常会逐步把索引记录合并到目标地址。注意重定向链不要超过一跳，A 到 B 再到 C 这种链条会稀释信号，也容易在核对时看不清最终落点。
canonical 声明
适合无法做重定向的场景，比如参数页、打印页、排序页。canonical 写在页面头部，声明首选地址。需要提醒的是，它属于建议性信号，搜索引擎可以采纳也可以忽略。
把 canonical 指向一个 404 页面、被 robots.txt 屏蔽的地址，或者几个变体互相指来指去，都会让这条信号失去意义。核对时优先确认 canonical 是否自指或指向正确目标。
从源头统一出口
内链、sitemap、RSS、分享按钮、结构化数据里的 URL，都统一成首选版本。这一条最容易被忽略，也最影响长期效果：只要站内还在不断产生旧版本的链接，新的变体就会持续被发现。
推荐的核对顺序
- 确认首选版本：定下协议、主机名、路径写法，全站以它为准。
- 列出变体清单：从内链、日志、外链三个来源汇总。
- 逐个验证状态码：非首选版本返回 301，不要返回 200。
- 检查 canonical：每个变体页面的 canonical 是否指向首选版本，且目标可正常访问。
- 排查站内出口：模板、导航、文章正文里的链接是否还残留旧版本。
- 复核 sitemap：只提交首选版本，避免把变体也一并写进去。
- 观察索引变化：这一步最需要耐心，索引记录的合并通常以周为单位，不必每天反复查询。
几个常见误区
- 只改 canonical，不改内链，站内仍然在制造新变体。
- 301 指向的地址本身也能通过旧变体访问，等于绕了一圈又回到原点。
- http 与 https 同时保留可访问状态，只在页面上写一句请使用 https。
- 把参数页和静态页混在一起处理，实际这两类页面的取舍逻辑并不相同。
小结
URL 变体造成的重复收录，本质是出口不统一的问题。与其在收录结果出来后反复清理，不如先把站内的链接出口收敛到唯一版本，再用重定向和 canonical 处理历史遗留。顺序上建议是：先定首选、再列清单、然后重定向、统一出口、最后看索引，每一步都基于上一步的清单，减少凭印象判断。