一個商品頁，正常地址是 /item/1024，但站内連結、广告投放、分享按钮各自带上了不同的尾巴：?utm_source=、?from=、?sid=、?sort=price。對用戶来说這是同一個頁面，對抓取程序来说却是一串不同的地址。參數本身没有問题，問题在于它會把抓取机會摊薄，也让收錄时的版本判断變得模糊。
先分清：哪些參數改變了内容
處理參數之前，先按一個标准分類：加上這個參數後，頁面主体内容是否真的不同。
- 不改變内容：utm 系列、来源标记、分享来源、會话 ID、纯展示偏好（如列表/網格切換）。
- 改變内容：分頁 page=2、篩選品牌/價格区間、排序方式、語言或地区切換、搜尋结果。
第一類只需要收敛到無參地址；第二類要單獨判断是否值得被抓取和收錄，不能一刀切地全部屏蔽。
不改變内容的參數：從源头少生成
最有效的做法不是事後加标簽，而是让這類地址尽量不产生。
- 站内連結、面包屑、分頁、sitemap 里的地址统一寫無參版本，不要因為目前頁面带了參數就把參數繼續传给内鏈。
- 分享按钮和投放連結的跟踪參數，尽量不要在同一份頁面模板里扩散到所有内鏈。
- 會话 ID 能放 cookie 就不要放在 URL 上，URL 上的會话 ID 每次訪問都變，等于源源不断制造新地址。
- 頁面的 canonical 指向無參版本，並且要自洽——列表頁、分頁頁、詳情頁各自指向自己的規范地址，不要全站都指向首頁。
canonical 是建议不是指令，它的作用是帮助判断主版本，而不是保證带參地址一定不出現。連結层面少产生，比标簽层面多补救更省事。
排序和视图參數：優先級低，容易组合爆炸
排序參數單獨看影响不大，但一旦和篩選、分頁叠加，组合數量會迅速膨胀。常见的處理顺序是：
- 把排序、视图切換這類交互尽量做成前端行為，不改變地址；
- 如果必须改地址，给带排序參數的頁面指定 canonical 指向預設排序地址；
- 對明顯不會被搜尋需求的组合，考虑在抓取层面控制，而不是指望它們被收錄。
要留意的是，robots.txt 屏蔽和 canonical 不能同时用在同一批地址上。被 robots 屏蔽的 URL，抓取程序不會去讀頁面内容，也就讀不到里面的 canonical 和 noindex，站内信号和 robots 規則會互相打架。選擇一種手段，別叠两层。
篩選和站内搜尋：控制抓取面，而不是逐個處理
篩選组合頁和搜尋结果頁往往是參數地址的大头。逐個挑出「值得收錄」的几乎没有必要，更實际的是控制抓取面：需要保留的品類篩選頁给出稳定、干净的地址结构；纯组合型的篩選參數，則在抓取层面限制，或對頁面使用 noindex 並把連結正常輸出，让權重繼續传递。
分頁參數属于另一類。第 2 頁、第 3 頁通常有獨立内容，canonical 指向自身即可，不要指向第 1 頁，否則等于主動告诉搜尋引擎「這些頁面不用單獨存在」。
自查顺序：從日誌和連結入手
如果怀疑參數地址已经造成困扰，按這個顺序看比較快：
- 抓取日誌里带參 URL 占了多少比例，是否集中在少數几個參數上；
- sitemap 和内鏈里是否混進了带參地址；
- canonical 是否指向了正确的無參版本，是否存在循环或指向不存在的地址；
- robots.txt 是否有規則誤伤了需要被抓取的地址，或與頁面内的 noindex 冲突；
- 參數地址是否在被抓取後占用了大量訪問频次，却長期没有進入索引。
參數不會直接導致頁面被降權，它更像是把有限的抓取机會和判断信号分散掉了。把會产生地址的地方收紧一点，把该有獨立地址的頁面（分頁、有實际需求的篩選）明确保留下来，收錄狀態通常會逐渐稳定。