做收錄核對时，很多人會先看索引量。但真正值得留意的是另一種情况：索引里的 URL 數量，比站点實际存在的頁面還多。多出来的部分通常不是搜尋引擎凭空生成，而是同一份内容的不同地址被分別记了一筆。搞清楚它們的来源，比單纯盯着總量涨跌更有用。
先確認“多”是不是真的多
索引量是估算值，本身會波動，偶尔高一点低一点不必紧張。要判断是否真的膨胀，可以拿三份資料交叉比對：站点地图里提交的 URL、抓取日誌里出現過的 URL，以及從首頁出發顺着内鏈能走到的 URL。三者合並去重後，得到一個大致的“應有頁面數”，再和索引量對照。如果差出成百上千，而且集中在某几種地址形態上，就属于可處理的范围。
多出来的 URL 一般来自這几類
- 追踪與會话參數：utm_、gclid、fbclid、sid 這類參數，用戶点一次就多一個地址。
- 排序、篩選、视图參數：?sort=、?view=list、?page=2 這類组合，很容易被逐條發現。
- 同路径的寫法變体：大小寫不同、结尾斜杠有無、多带一個 index.html。
- 协议與域名變体：http 與 https、带 www 與不带 www，歷史上都留下過入口。
- 移動版、打印版、AMP 等副本：同一篇内容被輸出成多個模板。
- 站内搜尋结果頁：只要有人從外部点進来，就可能被当成獨立頁面。
- 接口或資料文件暴露的地址：JSON、XML、CSV 里的連結被顺藤摸瓜地發現。
- 舊域名、測試域名、CDN 域名上的镜像副本。
按形態归類，再看每组值不值得留
只導出一份 URL 列表意义不大，先按參數名、路径层級、域名分组。分组之後给每组打两個标记：數量，以及這组 URL 在過去一段時間有没有带来過搜尋点击。有轉化的參數頁可以考虑保留並做規范化，纯參數副本和明顯的寫法變体則倾向收敛。這样處理起来有優先級，也不至于一刀切誤伤。
處置的大致顺序
- 域名與协议层重复：優先用 301 统一到唯一版本，這一层影响面最大。
- 參數副本：主版本保留可抓取，其余版本用 canonical 指向主版本；确實不需要的，再考虑限制抓取。
- 站内搜尋與结果頁：通常不建议進索引，處理时注意不要只靠 robots.txt。
- 舊域名與镜像：统一跳轉到現行域名，避免两套地址同时被訪問到。
注意：被 robots.txt 挡住的 URL，搜尋引擎通常讀不到頁面上的 noindex。想让某個地址登出索引，要么让它能被抓取並返回 noindex，要么確認它不會再被外部連結訪問。两者混用很容易事與愿违。
顺手把内鏈和站点地图收一收
很多變体地址是被自己的内鏈喂出来的。检查頁脚、面包屑、标簽云、分頁控件，確認輸出的都是規范版本。站点地图只放希望被訪問的 URL，不要把带參數的變体一並提交。内鏈收敛之後，新产生的變体會明顯减少，這比事後清理省力得多。
改完之後看什么
不要只看索引總量。按前面分好的组分別跟踪，观察每一组的數量是否在缓慢下降，同时確認規范版本的抓取频次有没有上升。這個過程通常要按周看，几天的波動說明不了什么。如果某一组迟迟不動，再回头检查该组的連結入口是不是真的被断掉了。