很多站点上线几年之後，索引里會多出一批看起来一模一样的 URL：同一篇文章，既有 /News/123，也有 /news/123；有的带尾斜杠，有的不带；http 和 https 各存一份；www 和裸域各存一份。它們指向同一個頁面，却占了好几個索引位置。
這些變体通常從哪里来
- 内鏈寫法不统一：不同編輯、不同模板輸出的連結格式不一样。
- 程序自動补全：CMS、分頁组件、面包屑各生成一套規則。
- 歷史遗留：改版、換域名、迁移目錄时，舊寫法没有完全清掉。
- 服務器差异：Linux 下路径大小寫敏感，Windows/IIS 預設不敏感，同一套代碼換個环境就多出一批 URL。
- 外部来源：外鏈、分享、QR Code、第三方工具按自己的习惯拼地址。
為什么值得专门花時間收口
- 抓取预算被摊薄。同一份内容被抓多次，真正需要更新的頁面来得就少了。
- 收錄量虚高。报表數字涨了，不代表有效頁面變多，排查問题时還會被干扰。
- 信号分散。外鏈、点击、停留時間被拆到多個地址上。
- 日誌失真。統計抓取分布时，同一個頁面在日誌里出現好几行，看不出真實热度。
收口的顺序
顺序比工具重要，先做影响面最大的那一层。
- 先定主形態。协议用哪個、主机名用 www 還是裸域、路径是否带尾斜杠、大小寫規則如何，一次性定死並寫成文档。
- 在服務器层做 301。這是最彻底的一层，浏览器和爬虫都會被带到主形態。相比 canonical，301 是硬信号，不依赖對方配合。
- 改寫站内連結。導航、面包屑、分頁、正文内鏈、sitemap 全部輸出主形態，從源头减少新變体产生。
- canonical 兜底。對無法用 301 處理的场景，比如带參數但可訪問的地址，用 canonical 指向主版本。
- 顺手统一静態资源與接口。图片、CSS、JS、API 地址同样會有协议和主机名不一致的問题，一起改成本最低。
- 观察一段時間。看日誌里舊寫法是否還在被請求，看索引狀態里變体是否在减少。
常见坑
- 大小寫規則誤伤。把全站路径强制轉小寫，可能撞上本来靠大小寫区分的内容，也可能让带簽名的 URL 失效。
- 尾斜杠跳轉成环。服務器、CDN、程序各寫一條規則，互相跳来跳去，最後报重定向次數過多。
- https 强跳时机不對。證书還没配好就先把 http 全部跳過去，會直接打不開。
- HSTS 上得太早。浏览器一旦记住，回退成本很高，確認稳定後再開。
- 只看 canonical 不看 301。canonical 是提示，遇到冲突时搜尋引擎可能按自己的判断處理。
一份简單的自查清單
- 主形態是否明确寫下来，团队是否都知道。
- 随机抽 20 條内鏈，检查协议、主机名、尾斜杠是否一致。
- 带 www 和不带 www 的地址各訪問一次，看是否只剩一次跳轉。
- 把路径改成全大寫訪問一次，看是否回到主形態。
- sitemap 里的 URL 是否全部為主形態。
- 日誌里舊寫法的請求量是否在逐周下降。
URL 收口属于一次性的工程活，但需要周期性复查，因為新模板、新活動頁、新同事都會带進新的寫法。
做完這些，不會立刻让收錄數字變好看，但能让後續所有關于收錄、抓取和日誌的判断建立在更干净的資料上。