很多站点的 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。
参数治理不是一次性任务。推广方式一变、产品加一个新筛选，新参数就会冒出来。把“新增参数先登记、再决定是否放行”写进发布流程，比半年后集中清理省力得多。
最后提醒一点：不要为了追求地址干净而把有用的筛选页全部砍掉。先看日志和站内搜索词，判断用户是否真的在用这些入口，再决定是保留、收敛还是挡掉。