做站点运营的人大概都遇到过这种场景：一篇内容被转发到外部渠道，链接后面自动跟了一串 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 字符串，日志里会多出一份记录。如果一定要用重定向规则匹配，记得把顺序差异考虑进去。
二是锚点与参数的区别。井号后面的锚点通常不会产生新的服务端请求，问题一般不大；问号后面的参数则是实打实的独立地址，需要单独对待。
参数治理没有什么一劳永逸的方案，它更像日常的卫生习惯：生成链接时规范一点，服务器端收口一点，过段时间再翻日志，重复地址自然会少下去。