同一篇内容對搜尋蜘蛛来说可能並不止一個地址。浏览器的容错能力很强，用戶把首字母打成大寫、结尾少寫或多寫一個斜杠、带上几個看不懂的參數，頁面照样能打開。但蜘蛛看到的是字符串：字符串不同，URL 就不同，會各自進入待抓队列，各占一次請求。结果是抓取量看着在涨，真正需要更新的頁面却迟迟等不到重新訪問。
常见的入口不一致類型
多數重复入口不是刻意做出来的，而是拼接习惯加上服務器配置共同造成的。以下几類在日誌里最常出現：
- 大小寫差异：/About 與 /about 都返回 200，服務器不区分，但两條 URL 字符串不同。
- 尾斜杠差异：/list 與 /list/ 都能打開，内鏈一處寫一種，Sitemap 又寫第三種。
- 預設文件名與端口：/index.html 與 /、带 :80 的寫法、http 與 https 混用。
- 參數顺序與冗余參數：?a=1&b=2 與 ?b=2&a=1，以及排序、来源追踪類參數。
- 分頁參數寫法：?page=1 與 ?p=1 並存，第一頁又和列表頁本身重复。
這些差异單獨看都很小，但同一内容若有两三種寫法被内鏈和 Sitemap 同时引用，就會被稳定地重复發現。
為什么它會影响抓取效率
蜘蛛在單位時間内能取的頁面數量是有限的。同一内容被拆成几個地址後，抓取预算被平均分掉，真正有内容更新的地址得到的訪問次數反而變少。更麻烦的是判断被干扰：後台看到的抓取總量不低，但按内容去核對时，會發現大量請求落在同一個頁面的不同副本上。
還有一层隐性問题。如果一個頁面的多個副本都能返回 200，蜘蛛無法從响應本身判断哪個是主体，只能依赖 canonical 或跳轉来归集。归集信号一旦缺失或互相矛盾，抓取路径就會長期分裂。
怎么核對是否存在重复入口
- 從服務器日誌按路径聚合，統計同一個内容出現了几種請求形態，分別對應的狀態碼是什么。
- 用抓取工具手動模拟：把带斜杠、不带斜杠、大小寫變化的版本各請求一次，记下狀態碼和最终落点。
- 對比内鏈與 Sitemap 中同一頁面的寫法，两邊不一致是最常见的源头。
- 检查服務端跳轉是否稳定，同一非規范地址多次請求後的落点是否始终一致。
核對时以日誌為主，頁面报告類資料可以作為參考，但不适合当作唯一依據，因為它們的更新有明顯的延迟。
收敛的合理顺序
建议先统一站内寫法，再動服務端跳轉，這样中途不容易产生新的断鏈。
- 统一内鏈與 Sitemap：同一頁面在所有位置只保留一種寫法，這是成本最低、见效最直接的一步。
- 對非規范形式做 301：跳轉到唯一的規范地址，不要用 302，也不要跳轉鏈套多层。
- 用 canonical 兜底：指向規范地址，作為跳轉失效时的补充，而不是替代跳轉。
- 不要用 robots.txt 處理重复：Disallow 只阻止抓取，不传递归集信号，還可能连带影响規范頁的發現。
两個容易踩的誤区
只看狀態碼是否正常
301 和 200 對用戶来说都能正常訪問，但從抓取角度看完全不同。一個把請求導向唯一地址，一個則让副本繼續存活。核對时要看的是落点，而不只是能否打開。
把带參數的地址一刀切屏蔽
篩選頁、排序頁里有一些确實承载獨立内容，全部拦掉可能让這部分頁面失去發現路径。更稳妥的做法是先按參數類型分類，確認哪些只是装饰、哪些真的区分内容，再分別處理。
規范化的目标不是消灭所有重复地址，而是让蜘蛛用尽可能少的請求，找到唯一需要更新的那一份。
收敛完成後建议再做一次复查：同一内容在日誌里的請求形態是否只剩一種，跳轉是否稳定返回 301，内鏈與 Sitemap 是否已经全部切換到規范寫法。這些观察比單看抓取總量更有參考價值，也更容易發現新的不一致從哪里冒出来。