做收录排查时，常会遇到一种情况：搜索某个关键词，点进去发现落地页不是自己提交的那条 URL。你提交的是 A，索引里留着的是 B；或者站点地图里写的是 A，搜索结果展示的却是带参数的 A?from=xxx。页面能抓、内容也在，就是地址对不上。
这通常不算收录故障，而是搜索引擎在重复内容聚簇里重新选了一次规范版本。它会把一组内容相近的 URL 归到一起，挑一条作为代表留在索引里，其余的当作重复项跟随。你需要判断的是：被挑中的那条，是不是你希望用户看到的。
它通常会参考哪些信号
- 页面上的 canonical 声明，以及它是否自指、是否指向一条真正可访问的 URL
- 站内链接：导航、面包屑、列表模板里指向该内容时用的是哪个版本
- 站点地图中提交的地址
- 重定向链的终点
- http 与 https、带 www 与不带 www、结尾带不带斜杠这些历史形态
- 页面主体内容的完整度与相似度，正文更完整、位置更靠前的那条往往更占优势
几种高发的改写场景
参数版本抢走主版本
跟踪参数、排序参数、会话 ID 都会参与进来。搜索引擎一般倾向于挑不带参数的版本，但这不是必然。如果站内链接大量指向带参数的版本，它也可能反过来被选中。
分页与筛选列表
第 2 页、第 3 页与第 1 页正文高度相似时，被归并很常见。列表页上不同筛选组合如果反复呈现同一批条目，也容易在索引里互相替换。
同一内容存在多个入口
比如商品同时挂在 /product/123 和 /category/a/product/123，两条都能打开且内容一致。站内哪个入口被链接得更多，哪条更容易被留下。
打印页、AMP 页、移动版
这类次级版本如果没有处理好对应关系，很容易出现索引里留的是体验较差的那一条，用户打开后内容和预期不一致。
排查顺序可以这样走
- 用 site: 搜索页面标题的完整字符串，看返回的是哪条 URL。
- 拿这条 URL 和预期 URL 做对比，找出差在协议、域名、路径、参数还是斜杠。
- 核对两条 URL 上的 canonical，看是自指、互指，还是指向了站外地址。
- 查服务器日志，确认搜索引擎实际抓取的是哪一条，抓取频次是否集中在非预期版本上。
- 检查站内链接，尤其是导航和列表模板，是否把非预期版本当成了主要入口。
排查这类问题的关键，是先确认「哪条被抓、哪条被留下」，而不是先动页面内容。地址层面的混乱，用内容手段解决不了。
想让它按你的意愿选，能做的是收敛
- 先选定一条规范 URL，全站统一使用，包括导航、面包屑、内链和分享按钮。
- canonical 保持自指，指向的地址要能直接打开并返回正常状态码。
- 站点地图只放规范地址，不要把同一内容的各种形态都塞进去。
- 对跟踪参数、会话参数做统一处理，减少同一内容产生大量变体。
- 确实多余的入口，用 301 指向规范版本，而不是让它和主版本长期并存。
这些动作不会立刻改变结果。规范版本是搜索引擎在多次抓取后逐步形成的判断，重新聚簇需要时间，别拿某一天的搜索结果下结论。
有些情况不必强行纠正
如果被选中的版本同样可正常访问、内容完整、移动端体验也没问题，用户从搜索结果进来看得到完整信息，那这次改写对站点并没有实质损失。真正需要处理的是：留下的是空壳页、纯参数页、重复目录，或者用户落地后看到的内容与标题明显不符。
与其追求让某一批 URL 严格按预期进索引，不如把重心放在减少同一内容的多种可访问形态上。地址形态收敛了，规范化选择的结果自然也更容易稳定。