很多站点都存在這種情况：一份内容通過好几種寫法都能打開，服務器對每一種都返回 200。對用戶来说没差別，對爬虫来说却是若干個互不相干的 URL。處理這類等價地址，不需要多复杂的工具，關键是顺序別搞反。
先確認哪些寫法指向同一個頁面
常见的等價變体大致有這几類：
- 协议：http 與 https 同时可訪問，且没有互相跳轉。
- 主机名：带 www 與不带 www 都能打開。
- 末尾斜杠：/page 與 /page/ 各返回一份内容。
- 大小寫：在大小寫敏感的服務器上，/Page 與 /page 是两個地址。
- 預設文档：/page/ 與 /page/index.html 並存。
- 端口：把 :80、:443 顯式寫進連結。
- 參數顺序：?a=1&b=2 與 ?b=2&a=1 對應同一结果頁。
- 跟踪參數：連結被加了 utm、分享来源等附加參數，頁面内容不變。
先做一次抽样：從日誌或站点地图里捞一批 URL，把這些形態各訪問一遍，看哪些返回 200、哪些已经跳轉、哪些跳到別處。這一步的结论决定了後面要改什么，不要凭印象動手。
不统一會带来什么
問题通常不是立刻顯現，而是慢慢累积：
- 内鏈和外部連結被分摊到多個地址上，頁面得到的信号被稀释。
- 同一個頁面的多個形態都被抓取，抓取次數花在了重复的事情上。
- 日誌分析失真，你以為某個栏目流量好，其實拆成了几條。
- 站点地图、canonical、跳轉規則三者不一致时，爬虫收到的提示互相矛盾。
這些後果都不是必然發生，但一旦出現，排查成本會明顯高于提前统一。
治理顺序：先定主形態，再让其他形態退场
- 确定唯一主 URL。 域名用带 www 還是不带、协议用 https、目錄结尾用哪種、大小寫怎么定，逐條寫進团队規范。主形態一旦确定，就不要因為改版或換人再改第二次。
- 在服務器层做 301。 非主形態统一 301 到主形態，不要用 302、307 這類临时跳轉代替。跳轉要一步到位，避免 A 跳 B、B 再跳 C 的鏈式结构。
- 让 canonical 與 301 目标一致。 頁面上的 canonical 指向的地址，必须是能直接返回 200 的主形態，而不是跳轉鏈的中間地址。两邊指向不同，等于自己给自己制造信号冲突。
- 统一站内連結、導航與站点地图。 内鏈是爬虫發現地址的主要入口，只要站内還混用着舊寫法，前两步的效果就會被持續抵消。歷史文章里的舊連結建议安排一次批量替換。
- 參數分两類處理。 影响頁面實质内容的參數（例如篩選、排序结果頁）适合保留，但控制组合數量並给出可索引的范围；纯粹的跟踪參數則统一去掉或在服務器层跳回無參數地址。
- 观察收口情况。 看日誌里各變体的抓取占比是否下降，看同一内容的重复條目是否减少，看站点地图里的 URL 數量是否和實际主 URL 數量接近。
顺序上最容易搞反的地方
不少站点先给頁面加 canonical，却迟迟不改服務器跳轉，结果同一個地址既能打開又声明指向別處。更稳妥的做法是先固定服務器层規則，再统一頁面上的信号，最後统一内鏈。层與层之間的目标地址保持一致，爬虫才不需要猜。
不建议做的几件事
- 用 JavaScript 或 meta refresh 做規范化跳轉，识別慢，還容易留下中間地址。
- 對同一份内容既做 301 又加 noindex，两種信号叠在一起。
- 為了省事把带内容的參數頁整体屏蔽，可能同时挡住有效的入口。
- 只改首頁和導航，不管歷史内鏈和已经存在的外部連結。
等價 URL 的治理不是一次性任務。新增模板、新接的統計脚本、运营临时加的分享連結，都可能重新引入變体。把它当成發布流程里的一個检查項，比事後集中清理省力。
怎么判断有没有收口
可以盯几個简單的指标：日誌中各變体的抓取次數是否在下降；站内搜尋同一關鍵詞时，是否還會出現同一内容的多個地址；站点地图提交的 URL 與主形態清單是否一致；頁面上的 canonical 是否長期稳定指向同一個地址。若這些指标没有明顯變化，先回头检查跳轉是否一步到位、内鏈是否還有漏改，而不是急着調整内容本身。