翻抓取日志的时候，很多站点都会看到一个熟悉的现象：同一个内容页被反复请求，区别只在地址尾巴上多了一串 ?utm_source=xxx&from=xxx&sort=price。内容一个字没变，但在蜘蛛看来，这是几十个彼此独立的地址。抓取预算就那么多，重复消耗掉的部分，本来可以用来发现和更新真正需要更新的页面。
参数膨胀是怎么形成的
参数本身不是问题，问题在于来源太多、又没人统一约束。常见的有几类：
- 营销来源参数：utm_source、utm_medium、utm_campaign、gclid、fbclid，被分享链接、投放链接、站外转载带入。
- 会话与身份参数：sid、sessionid、token、uid，随登录状态或临时会话出现。
- 筛选与排序参数：sort、order、price_min、brand、color，由前台筛选器生成。
- 视图与分页参数：?page=2、?view=list、?p=1，和静态路径表达的是同一批列表。
- 时间戳与随机数：?t=1690000000、?_=1234，每次请求都不一样。
这些参数单独看都有道理，但站内链接、分享按钮、统计脚本、外部转载一起作用，同一个页面就会不断分裂出新地址。
先按类型分类，再决定怎么处理
营销类参数：从入口链接里拿掉
utm 这类参数不影响页面内容。站内跳转、导航、分页、面包屑里尽量不要带它；分享出去的链接可以带，但要保证落地后地址能收敛到干净版本，而不是把带参地址继续散到内页去。
会话类参数：优先改成 Cookie
把会话 ID 写进 URL 是早期做法的遗留。现在用 Cookie 承载会话更合适。如果历史原因没法立刻改，至少不要让蜘蛛看到带 sid 的地址，通过 robots.txt 或 canonical 做兜底处理。
筛选与排序类：看页面有没有独立价值
真正有搜索价值的筛选组合（例如某品牌加某型号）可以保留，并给独立的标题与描述；只用来切换视图的参数，例如 sort=asc 与 sort=desc，应当收敛回主列表页，不要让它各成一个地址。
四种常见收敛手段
- canonical 指向主地址。带参页面统一 canonical 到稳定、可直接访问的干净地址，注意不要指向另一个带参地址，也不要指向重定向链中间的一跳。
- 服务器层跳转。对无意义的参数直接 302 到干净地址，别用 301 把两套地址长期固化下来。这比纯靠 canonical 更彻底。
- robots.txt 谨慎屏蔽。只对明确没有索引价值的参数前缀使用 Disallow。带通配符的写法要格外小心，写错一个字符可能连带挡住正常列表页。
- 链接自律。站内搜索结果、标签聚合、相关推荐里输出的链接，尽量不带跟踪参数；外链投放时也把参数控制住。
canonical 是建议，不是强制命令。处理参数问题更稳的顺序是：先减少带参数的入口链接，再用服务器跳转收敛，最后才用 canonical 兜底。只加标签不清理入口，问题会一直复发。
怎么验证有没有效果
可以从三个角度观察：抓取日志里带参数地址的请求占比是否下降；索引中标题重复的页面是否减少；同一内容最终被收录的是哪个地址。站点地图里只提交主地址，不要提交带参版本。参数类改动的生效通常需要几周，别指望改完第二天就清干净，给自己留出观察周期。
几个容易踩的坑
- 只在页面上加了 canonical，站内依然到处输出带参链接，等于一边堵一边漏。
- robots.txt 用一刀切的写法屏蔽所有问号，把筛选页和分页一起挡在门外。
- 参数顺序不同被当成两个地址，服务器端应对参数排序做归一，例如合并 ?a=1&b=2 与 ?b=2&a=1。
- 把带参数的地址写进站点地图或内链锚点，等于主动把分裂的地址交给蜘蛛。
- 参数页返回 200 却没有任何标记，蜘蛛只能当成正常新页面处理。
参数不是错误，缺少约束才是。把入口链接、服务器规则、canonical 和站点地图这几件事一起理顺，重复地址带来的抓取压力才会真正降下来，日志也会变得干净好读。