做站点运营的人大概都遇到過這種场景：一篇内容被轉發到外部渠道，連結後面自動跟了一串 utm_source、utm_medium 之類的标记，几天後在服務器日誌里，搜尋蜘蛛也在請求這些带參數的地址。站内明明只有一個頁面，對外却派生出十几個 URL，入口就這样被摊薄了。
參數是怎么混進 URL 的
常见的来源可以分成三類。第一類是推廣與分享工具自動追加的标记參數，例如 utm_、gclid、fbclid、spm 等；第二類是程序把會话标识寫進了地址，例如 PHPSESSID、sid；第三類是站内篩選、排序、翻頁等交互控件把狀態同步到了 URL 上。前两類對訪問者几乎没有價值，第三類里有一部分是用戶真實需要的。
三類參數的差別處理
- 推廣參數：不影响頁面正文，理想做法是让带參數的地址 301 跳到不带參數的規范地址，或者在頁面的 canonical 中声明干净版本。
- 會话标识：典型的重复入口来源。能在服務器或應用层避免把會话寫進 URL 最好；做不到的话，至少不要让對外生成的連結带上它。
- 篩選與排序：如果某些组合頁确實有獨立價值，可以考虑做成稳定的獨立路径；如果只是给用戶临时看的视图，就不要為它生成可抓取連結。
301 與 canonical 的選擇
两種手段经常被混用，其實适用场景不同。參數集合有限、規律明确时，用 301 收口最干净：带參數的請求直接跳到規范地址，蜘蛛拿到的永遠只有一個版本。
參數组合不可枚举，或者參數由第三方平台随机追加时，301 規則容易寫漏，這时更适合用 canonical 表達偏好，同时把站内連結统一成干净地址。需要留意的是，canonical 是建议信号而不是强制指令，如果带參數的頁面在別處還有大量内鏈指向它，效果會被削弱。
不要用 robots.txt 一拦了事
有些站点图省事，直接在 robots.txt 里屏蔽带問号的路径。這種做法風險不小：一方面被屏蔽的地址仍可能被外部連結带到蜘蛛面前，只是抓不到内容；另一方面規則寫得太宽，容易把确實有用的參數頁一起挡掉。相比之下，把規范地址讲清楚更稳妥。
連結生成端才是源头
很多參數問题的根子在生成連結的那一步。分享按钮、複製連結功能、站内互推模块、編輯器里粘贴的外鏈，都會把參數传播出去。运营上可以定几條简單约定：對外分享一律使用站内規范地址；複製連結时剔除推廣标记；站内互推和目錄頁只寫干净路径。
顺手可以做的几項检查
- 用命令行請求一次带參數的地址，看响應头里的 Location 是否指向規范地址。
- 查看带參數頁面源碼中的 canonical，確認它指向的是自己期望的那個 URL。
- 翻一段時間的訪問日誌，統計带問号的請求占比，以及其中搜尋蜘蛛的比例。
- 检查 robots.txt，確認没有把正常目錄连带挡在门外。
两個容易忽略的细节
一是參數顺序。utm_source 與 utm_medium 前後調換，浏览器和服務端看到的都是不同的 URL 字符串，日誌里會多出一份记錄。如果一定要用重定向規則匹配，记得把顺序差异考虑進去。
二是锚点與參數的区別。井号後面的锚点通常不會产生新的服務端請求，問题一般不大；問号後面的參數則是實打實的獨立地址，需要單獨對待。
參數治理没有什么一劳永逸的方案，它更像日常的卫生习惯：生成連結时規范一点，服務器端收口一点，過段時間再翻日誌，重复地址自然會少下去。