站内带参数的地址很常见：统计用的 utm_、来源标记、筛选、排序、分页。对使用者来说，这些参数只是同一个页面换了种打开方式；但对蜘蛛来说，URL 字符串不同，就是不同的地址。参数处理不当，抓取队列里会堆积大量内容高度相似的页面，真正需要更新的页面反而排不上。
蜘蛛如何识别带参数的 URL
蜘蛛不会去猜参数含义。它看到的是完整字符串：?utm_source=a 和 ?from=a 在它眼里是两条独立记录，分别入队、分别抓取、分别判定内容。只有当服务端返回相同内容、页面上的 canonical 指向同一地址，或者存在明确的规范化跳转时，它才可能把两者归并处理。
一个参数组合就是一个 URL，这也是筛选页容易把抓取队列撑大的根本原因。
哪些参数通常值得放行
- 分页类：page、p 这类参数背后是真实不同的内容片段，通常需要抓。
- 内容确实不同的筛选：例如按品类、地区切分后页面主体内容有明显差异，且有稳定入口。
- 语言或版本区分：需要配合 canonical 或 hreflang，让蜘蛛明白彼此关系。
- 追踪类：utm_、ref、from、spm、share 等对内容没有影响，一般不需要被抓取。
几种常见的处理方式
robots.txt 里屏蔽
写法简单，但要注意副作用：被 Disallow 的地址，蜘蛛无法抓取页面内容，也就看不到上面的 canonical，页面里的内链也不会被继续跟随。所以更适合用在确定不需要抓取的追踪参数上，而不是一刀切屏蔽整类路径。
服务端规范化或重定向
识别出追踪参数后，用 301 跳到无参数版本，是把地址收敛到一条线上的做法。代价是每次访问都要多一跳，跳转链不宜过长，也不要出现 A 跳 B、B 又跳回 A 的循环。另一种更轻的做法是服务端忽略这类参数，直接返回主版本内容加 canonical。
用 canonical 声明首选地址
在带参数的页面上输出 canonical，指向规范地址，是较温和的方式。需要清楚：canonical 是建议，不是强制命令，蜘蛛仍可能按自己的判断处理。因此 canonical 要和内链、Sitemap 的方向保持一致，别一边声明首选是 A，一边把 Sitemap 和导航都指向 B。
从内链源头收敛
站内链接、导航、面包屑、Sitemap 里尽量不带追踪参数。蜘蛛的发现路径主要来自链接，入口干净，带参数的地址自然就少。这比事后屏蔽更省事。
筛选与排序参数的取舍
颜色、尺寸、排序方式、每页条数这些参数容易组合爆炸，用户点几下就能生成上千条地址。判断标准可以简单一些：这个组合是否有独立价值。有稳定需求、内容确实不同的筛选组合，可以保留并让地址固定；纯粹由交互产生的组合，可以让它们停留在前端交互层面，不生成可被抓取的新地址，或在 robots 里屏蔽参数组合的匹配模式。
参数顺序与大小写
?a=1&b=2 与 ?b=2&a=1 是两个 URL，?Page=2 和 ?page=2 也是。生成链接时固定参数顺序和大小写，能直接减少同一内容的出口数量。有条件的话，在服务端做一次规范化，把参数排序后统一处理。
分页参数的两个细节
- 第一页常常和列表首页内容是同一批，可以让首页不出现 page=1 的入口，或用 canonical 指向列表首页。
- 翻到没有内容的深分页，比如已超出实际页码，最好返回明确的状态码并停止输出下一页链接，避免蜘蛛在空页上反复走动。
一份可执行的检查清单
- 从访问日志或抓取统计里，看带参数 URL 占抓取总量的比例，判断是否异常。
- 抽查带参数页面的 canonical 是否指向正确，是否与内链方向一致。
- 检查站内链接是否被追踪参数污染。
- 确认 robots 里屏蔽的是不需要抓取的参数，而不是把有价值的分页也一起挡住。
- 统一参数顺序与大小写，减少重复出口。
- 控制分页深度，深分页返回明确状态。
不必追求把所有参数都消掉，重点是让内容没有差异的参数地址不占用抓取配额。地址结构稳定、可预期之后，蜘蛛对站点的抓取节奏也更容易保持平稳。