站点做久了，收录表里总会出现一些“看起来是同一个页面”的 URL。它们不一定都来自技术配置错误，很多时候是业务本身产生的。处理之前先把它分成几类，比直接套一堆规则更有效。
先明确：什么才算需要处理的重复
判断标准可以简单一点：把 URL 全部去掉，剩下的正文主体、标题、主要信息是否基本一致。如果一致，只是入口不同，那才属于需要收口的重复版本。列表页、分页页、聚合页虽然内容形态接近，但各自承担导流与层级的作用，不能和重复正文混为一谈。
来源一：参数与 URL 变体
这类重复最好识别，常见来源有：
- 渠道追踪参数，比如 utm_、from、spm 一类的后缀；
- 排序、筛选、每页条数等参数；
- 同一路径的大小写、结尾斜杠、http 与 https 并存；
- 带与不带 index.html 之类的默认文件名。
它们的共同点是：URL 不同，返回的却是同一份内容。处理方式通常是规范化，让页面内部所有链接统一指向一个版本，再用 canonical 声明主版本。
来源二：分页与列表切分
内容被拆成多页时，会出现几种典型情况：正文文章被拆成 ?page=2、?page=3；列表页翻到很深的页码；“查看更多”用脚本加载出第二份可访问的 URL。这些页面不一定都要收口，关键看它们是否有独立的检索价值。分页的正文页通常应该给出 canonical 指向第一页，列表分页则更多是靠内链与抓取顺序来控制。
来源三：内容复用与同质化
这一类最容易被忽略，因为它不体现在 URL 上。比如：
- 同一篇文章同时发在多个栏目，各自生成一个 URL；
- 商品描述来自供应商，同一段文案套在几十个商品上；
- 聚合页把列表内容原样搬过来，正文几乎没有新增信息。
这类重复的根子在内容本身，单靠 canonical 只能缓解，真正的解法是合并、改写，或者让其中一个版本只做入口而不参与正文竞争。
核对顺序
如果已经把站点地图和内链整理过一轮，收录仍然不理想，可以按下面的顺序核对：
- 从抓取日志里找出被频繁抓取的参数型 URL，看它们是否返回 200；
- 在站内搜索几个核心页面的标题，看结果里出现了几个版本；
- 检查页面源码里的 canonical 是否自指，还是指向了别处；
- 检查内链与分页链接，是否把入口分散到了变体版本；
- 最后再看内容层面，确认是否存在跨栏目、跨语言的复制。
收口手段怎么选
canonical 适合“内容确实一样、但两个 URL 都有存在必要”的情况；robots.txt 屏蔽适合纯粹的工具型 URL，但要接受它仍可能出现在结果里的可能；301 适合旧版本已经不再使用；合并内容适合同质化严重的页面。几种手段可以叠加，但不要互相矛盾——同一个页面既被屏蔽又被 canonical 指向，信号很容易互相抵消。
判断标准始终是“用户是否需要这个 URL”。需要，就把它做成有独立价值的页面；不需要，就把它收掉，而不是让它长期处在半开放状态。
日常维护清单
- 新功能上线前，先确认会不会产生新的参数型 URL；
- 页面模板里的链接统一由一处生成，减少手工拼接；
- 每个月抽查一批被收录的变体 URL，看是否还有遗漏；
- 内容复用前先问一句：这个版本有没有新增信息。
重复内容的处理不是一次性的，它跟着业务功能走。把分类和核对顺序固定下来，比临时救火省力得多。