一個頁面為什么會變成几十個地址
URL 膨胀往往不是從外鏈開始的，而是從自己頁面里的連結開始的。列表頁的「按價格排序」、文章底部的分享連結、投放落地頁带的 UTM 參數，只要被寫進 HTML，蜘蛛就會把它們当成新的地址排队。同一個商品頁，可能因為 ?sort=price、?from=weibo、?sid=abc123 這几個後缀，在抓取队列里出現十几個版本。
這些變体頁面内容大同小异，蜘蛛抓到之後要么判定重复，要么反复確認两者之間的關系。無论哪種结果，消耗的都是同一份抓取時間。
三類參數，處理顺序不一样
追踪參數：最该先清掉
utm_source、from、ref、spm 這類參數只服務于統計，對頁面内容没有任何影响。它們最好在連結輸出阶段就不要出現。統計需求可以由脚本在点击时上报，不必通過改寫連結来實現。
排序與篩選：保留少量可控入口
排序和篩選參數确實能产生有價值的頁面组合，但组合數量是乘法級的。可以先確認哪些组合有真實搜尋需求，把這几组做成可抓取的静態入口，其余组合通過 robots.txt 或參數屏蔽規則收口。
會话與身份參數：從源头避免
sid、sessionid、token 這類參數會让同一個 URL 對每個訪客都不同。蜘蛛每次抓到的都像是「新地址」，缓存和去重都失去意义。這類信息應改為 Cookie 或請求头传递，不要出現在連結里。
内鏈是第一道關
參數治理最省力的位置是模板层。检查一遍站点模板，通常能找到大部分問题来源：
- 分享组件自動附加的来源參數；
- 分頁連結里带的時間戳或随机數；
- 面包屑、相關推荐里拼接的追踪參數；
- 站内搜尋结果的連結被直接輸出到頁面上。
把這些位置改成干净連結，比事後寫規則去拦截要可靠得多。規則是补丁，連結輸出才是源头。
robots.txt 和 canonical 的分工
如果短期内改不完模板，可以用 robots.txt 挡住參數型 URL。多數主流蜘蛛支持通配符寫法，但要小心別把正常頁面一起挡住，比如規則寫得過宽，可能连带參數的正規内容頁也一起屏蔽了。
canonical 的作用不同：它不阻止抓取，只表明「這個變体属于哪個主版本」。适合用在參數确實需要保留、且希望把權重归並的情况。
把 robots.txt 当成屏蔽、canonical 当成归並，两者不要互相替代。被 robots.txt 挡住的 URL，蜘蛛通常不會去讀它頁面里的 canonical。
用日誌確認收口效果
規則上线不等于生效，回到服務器日誌里看才踏實。可以按下面几步核對：
- 篩選出带問号的請求，統計參數種類和請求量占比；
- 观察同一路径下不同參數版本各被請求了多少次；
- 對比收口前後，蜘蛛在有效頁面上的請求量有没有變化；
- 留意是否出現新的參數组合，說明還有没被清理的連結出口。
一個可以照着走的顺序
先清模板里的追踪參數，再把篩選组合收敛到少數可控入口，然後用 robots.txt 挡住剩余的參數型 URL，最後用 canonical 處理必须保留的變体，並回到日誌驗證。整個過程不必一次性做完，但顺序尽量不要颠倒——先改連結輸出的收益，通常比後面几條規則加起来都大。