打开一个电商站或内容站，URL 后面常常拖着一串问号：颜色、排序、utm 来源、会话 ID 混在一起。这些参数有些是给用户用的，有些是给统计工具用的，但对搜索引擎来说，每一个组合都可能变成一个全新的 URL。参数怎么管，直接影响索引的干净程度。
先分清：参数是为了改变内容，还是只为传递信息
绝大多数参数可以归成两类。一类会改变页面上看到的内容，比如筛选颜色、价格区间、排序方式、分页；另一类只是携带信息，页面上没有任何区别，比如 utm 系列、分享追踪码、会话 ID。第一类要不要收录，取决于用户是否真的会这样访问；第二类基本没有收录价值，因为它们和主 URL 展示的是同一份内容。
判断方法很简单：把两个 URL 分别在无痕窗口打开，遮住地址栏，看页面内容是否真的不同。如果只是排序顺序变了、商品集合没变，通常不值得为它单独建一个可收录的版本。
三类参数，三种处理思路
追踪类参数
utm_source、fbclid、gclid 这类参数不改变内容，理想状态是让它们不产生独立的可收录 URL。常见做法是：对外分享时尽量少带参数；来自站外、无法控制的参数，依靠页面上的 canonical 指向无参版本；同时保证站内链接不携带追踪参数，避免自己制造重复。
筛选与排序参数
这类参数最让人纠结。它们可能带来长尾流量，也可能生成成千上万个近乎重复的页面。比较稳妥的思路是：只保留少数几个真正有搜索需求、内容差异明显的筛选组合，并且用可读的静态路径承载；其余组合通过参数生成，但不主动暴露内链，也不放进 sitemap。如果某个筛选组合只筛出一两条结果，那基本没有收录价值。排序参数一般不改变结果集合，通常不需要单独收录。
会话与时间戳参数
sessionid、sid、时间戳这类参数会让同一个页面每天生成新 URL，是最容易造成索引杂乱的一类。它们通常由系统自动生成，正确做法是在服务端或前端就避免出现在链接里，而不是等到事后去补救。
参数太多会带来什么实际问题
- 抓取机会被分散：站点每天能被抓取的次数有限，大量参数 URL 会挤占本可以留给正文页的机会。
- 重复内容增多：同一份内容出现十几个 URL，搜索引擎需要自己挑选代表版本，选中的不一定是你希望的那个。
- 数据难分析：同一页面被拆成多条记录，统计访客和表现时容易失真。
- 内链信号分散：如果站内到处是指向不同参数版本的链接，原本集中的信号会被摊薄。
几种常见手段，各自的边界
处理参数时，经常被提到的几种方式作用并不相同：
- robots.txt 屏蔽参数路径：能阻止抓取，但被屏蔽的 URL 仍可能因为外链等原因出现在索引里，只是没有摘要。屏蔽前要想清楚，因为一旦屏蔽，页面上的 canonical 也就读不到了。
- canonical 指向规范版本：告诉搜索引擎哪个是代表版本，属于建议而非强制，通常要配合内链和 sitemap 一起使用才更有效。
- 限制筛选组合的数量：从产品层面控制，比如只允许最多两个筛选条件同时生效，这往往是最省事的做法。
- 把有价值的筛选做成静态路径：例如把常用的城市、品类组合写成独立页面，内容做实，而不是靠参数临时拼出来。
以前 Search Console 里有专门的 URL 参数工具，后来已经下线，现在参数的管理基本要靠站点自己在前端、服务端和链接结构上解决。
上线前后的自查清单
- 站内导航、面包屑、正文里的链接，是否都不带追踪参数？
- 筛选页是否有唯一的规范版本，翻页时参数是否稳定？
- 参数 URL 会不会出现在 sitemap 里？如果会，是不是你希望被收录的那几个？
- 同一页面的多个参数版本，canonical 是否都指向同一个地址？
- 屏蔽规则有没有误伤正文页？屏蔽之后，页面上是否还有需要被抓取的内容？
处理参数的目标不是让所有 URL 都被收录，而是让搜索引擎把有限的时间花在真正有内容、有需求的页面上。收录与否最终由搜索引擎判断，站点能做的只是减少干扰项。
如果拿不准某个参数值不值得保留，可以先问一句：用户会不会主动搜索它？如果答案是否定的，那它多半只是在给自己添乱。