很多站点的 URL 结构本来很干净，上线一段時間後却慢慢長出尾巴：?utm_source=...、?spm=...、?from=...、?ref=...。這些參數在推廣和产品功能上都有用，但對搜尋引擎来说，它們會把你的一篇内容變成几十個看起来不同的地址。
參數通常從哪里来
- 外部推廣：信息流、社群、邮件里带的 utm 系列參數，被用戶複製轉發後留在站内連結上。
- 站内功能：排序、篩選、视图切換、每頁條數、翻頁等交互产生的參數。
- 會话與追踪：老系統里常见的 sessionid、sid、ref 之類，新站少一些，但迁移时容易带過来。
- 站内搜尋與跳轉：搜尋词頁、标簽跳轉頁被当成普通内容頁传播出去。
- 前端用途：?share=1、?print=1、?preview=1 等只影响展示的參數。
為什么值得花時間處理
參數本身不會直接導致問题，但會带来几层连带成本：同一篇内容出現多個地址，外鏈和分享信号被分散；抓取队列里塞進大量内容相同的請求，真正需要更新的頁面排在後面；日誌被參數地址淹没，看不出哪些頁面真的在被抓；統計报表里同一篇内容的阅讀量被拆成多行，判断内容好坏时容易得出错誤结论。
先分類，再决定怎么處理
值得保留的參數
篩選和排序在部分站点是有真實搜尋需求的，比如按價格排序、只看有货、按地区篩選。這類頁面可以考虑做成静態化路径，或者允许抓取但把组合數量控制在少數几個，避免属性任意组合。
纯跟踪參數
utm、spm、from、ref、share 等對内容没有影响，處理原則是让蜘蛛和用戶最终看到同一個地址。
常见處理手段
- 服務器端 301：在入口處把带跟踪參數的請求跳到干净地址，注意检查跳轉目标本身不再带參數，避免形成鏈式跳轉。
- canonical 兜底：頁面声明規范地址，适合處理不易拦截的參數，但它只是提示，不能替代真正的地址收敛。
- robots 通配：用 Disallow: /*?utm_ 之類的規則挡住一類地址，寫好之後務必確認没有誤伤带參數的正規内容頁。
- 内鏈自己保持干净：模板、分頁、相關推荐、站点地图里不要輸出參數，否則等于自己持續制造新地址。
一份可执行的自查顺序
- 從近 30 天日誌里筛出带問号的 URL，按參數名分组，統計各自被請求的次數。
- 给每個參數打标簽：跟踪、功能，還是内容定位。
- 抽查這些地址的返回碼和 canonical，確認是否指向自身。
- 检查站内連結與站点地图，看是否混入了參數地址。
- 對纯跟踪參數做 301 或屏蔽，先小批量上线，观察一周。
- 复查日誌，確認參數請求量下降，且正常頁面的抓取量没有被一起压掉。
容易被忽略的几個细节
參數是组合爆炸的：單個參數只多一個地址，几個參數叠加就是几十上百個。處理顺序上，先關掉增長速度最快的那個。另外，重定向規則上线前要確認带參數的地址在移動端和 AMP 之類的版本上表現一致，避免一部分设备跳到 404。
參數治理不是一次性任務。推廣方式一變、产品加一個新篩選，新參數就會冒出来。把“新增參數先登记、再决定是否放行”寫進發布流程，比半年後集中清理省力得多。
最後提醒一点：不要為了追求地址干净而把有用的篩選頁全部砍掉。先看日誌和站内搜尋词，判断用戶是否真的在用這些入口，再决定是保留、收敛還是挡掉。