站点做久了，收錄表里總會出現一些“看起来是同一個頁面”的 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，看是否還有遗漏；
- 内容复用前先問一句：這個版本有没有新增信息。
重复内容的處理不是一次性的，它跟着业務功能走。把分類和核對顺序固定下来，比临时救火省力得多。