翻抓取日誌的时候，很多站点都會看到一個熟悉的現象：同一個内容頁被反复請求，区別只在地址尾巴上多了一串 ?utm_source=xxx&from=xxx&sort=price。内容一個字没變，但在蜘蛛看来，這是几十個彼此獨立的地址。抓取预算就那么多，重复消耗掉的部分，本来可以用来發現和更新真正需要更新的頁面。
參數膨胀是怎么形成的
參數本身不是問题，問题在于来源太多、又没人统一约束。常见的有几類：
- 营销来源參數：utm_source、utm_medium、utm_campaign、gclid、fbclid，被分享連結、投放連結、站外轉载带入。
- 會话與身份參數：sid、sessionid、token、uid，随登入狀態或临时會话出現。
- 篩選與排序參數：sort、order、price_min、brand、color，由前台篩選器生成。
- 视图與分頁參數：?page=2、?view=list、?p=1，和静態路径表達的是同一批列表。
- 時間戳與随机數：?t=1690000000、?_=1234，每次請求都不一样。
這些參數單獨看都有道理，但站内連結、分享按钮、統計脚本、外部轉载一起作用，同一個頁面就會不断分裂出新地址。
先按類型分類，再决定怎么處理
营销類參數：從入口連結里拿掉
utm 這類參數不影响頁面内容。站内跳轉、導航、分頁、面包屑里尽量不要带它；分享出去的連結可以带，但要保證落地後地址能收敛到干净版本，而不是把带參地址繼續散到内頁去。
會话類參數：優先改成 Cookie
把會话 ID 寫進 URL 是早期做法的遗留。現在用 Cookie 承载會话更合适。如果歷史原因没法立刻改，至少不要让蜘蛛看到带 sid 的地址，通過 robots.txt 或 canonical 做兜底處理。
篩選與排序類：看頁面有没有獨立價值
真正有搜尋價值的篩選组合（例如某品牌加某型号）可以保留，並给獨立的标题與描述；只用来切換视图的參數，例如 sort=asc 與 sort=desc，應当收敛回主列表頁，不要让它各成一個地址。
四種常见收敛手段
- canonical 指向主地址。带參頁面统一 canonical 到稳定、可直接訪問的干净地址，注意不要指向另一個带參地址，也不要指向重定向鏈中間的一跳。
- 服務器层跳轉。對無意义的參數直接 302 到干净地址，別用 301 把两套地址長期固化下来。這比纯靠 canonical 更彻底。
- robots.txt 谨慎屏蔽。只對明确没有索引價值的參數前缀使用 Disallow。带通配符的寫法要格外小心，寫错一個字符可能连带挡住正常列表頁。
- 連結自律。站内搜尋结果、标簽聚合、相關推荐里輸出的連結，尽量不带跟踪參數；外鏈投放时也把參數控制住。
canonical 是建议，不是强制命令。處理參數問题更稳的顺序是：先减少带參數的入口連結，再用服務器跳轉收敛，最後才用 canonical 兜底。只加标簽不清理入口，問题會一直复發。
怎么驗證有没有效果
可以從三個角度观察：抓取日誌里带參數地址的請求占比是否下降；索引中标题重复的頁面是否减少；同一内容最终被收錄的是哪個地址。站点地图里只提交主地址，不要提交带參版本。參數類改動的生效通常需要几周，別指望改完第二天就清干净，给自己留出观察周期。
几個容易踩的坑
- 只在頁面上加了 canonical，站内依然到處輸出带參連結，等于一邊堵一邊漏。
- robots.txt 用一刀切的寫法屏蔽所有問号，把篩選頁和分頁一起挡在门外。
- 參數顺序不同被当成两個地址，服務器端應對參數排序做归一，例如合並 ?a=1&b=2 與 ?b=2&a=1。
- 把带參數的地址寫進站点地图或内鏈锚点，等于主動把分裂的地址交给蜘蛛。
- 參數頁返回 200 却没有任何标记，蜘蛛只能当成正常新頁面處理。
參數不是错誤，缺少约束才是。把入口連結、服務器規則、canonical 和站点地图這几件事一起理顺，重复地址带来的抓取压力才會真正降下来，日誌也會變得干净好讀。