很多站点的 URL 看起来差不多，点开才发现后面挂着一串参数：?utm_source=...、?from=...、?ref=...。对访客来说，地址栏长一点可能无所谓；对搜索蜘蛛和站点运营来说，同一篇内容如果存在多个参数版本，就会带来重复地址、抓取浪费和统计噪声。URL 参数本身不是问题，问题在于没有边界地使用。
参数通常从哪里来
在动手清理之前，先弄清楚参数是谁加上的。常见来源包括：
- 筛选和排序：列表页按价格、时间、热度排序，或按分类、标签筛选。
- 分页：部分程序用 ?page=2 而不是静态路径。
- 广告和渠道跟踪：utm_source、utm_medium、gclid 等。
- 站内搜索：?s=关键词 或 ?q=关键词。
- 会话与用户标识：sessionid、uid 等。
- 分享和外链：来自社交平台、邮件或合作方的跳转参数。
这些参数有些是功能必需，有些只是运营标记，还有一些是第三方自动追加。判断标准很简单：去掉参数后，页面主体内容是否基本不变。如果不变，它大概率只是一个“地址变体”。
参数泛滥会带来什么
最直接的影响是蜘蛛可能把同一个页面抓很多次。抓取预算有限，尤其是中小站点，如果大量参数地址被反复发现，真正需要更新的内容反而排不上队。其次，用户分享出去的链接可能五花八门，统计工具也会把一次访问拆成多个来源，导致渠道数据失真。再次，缓存和 CDN 可能把带参数的请求当成新资源，降低缓存命中率。
URL 参数自查清单
- 导出样本 URL：从访问日志、搜索控制台、站点地图和站内链接中，收集最近一段时间的 URL，按参数名分组。
- 标记内容型参数：哪些参数会改变页面主要内容，比如筛选出不同商品列表、不同文章分页。这类需要保留，但要控制组合数量。
- 标记跟踪型参数：utm、ref、from、spm 等，通常只影响统计，不影响内容。
- 检查 canonical：确认主要内容页是否指向不带跟踪参数的规范地址。canonical 不能跨内容使用，也不要把分页全部指向第一页。
- 检查 robots 与 noindex：对站内搜索结果页、复杂筛选组合、会话参数页，可以考虑屏蔽抓取或禁止收录，但不要误伤正常内容。
- 检查内链：站内链接尽量使用干净地址，避免复制带跟踪参数的 URL 作为导航或正文链接。
- 检查站点地图：站点地图中不要放入带跟踪参数、会话参数或大量筛选组合的地址。
处理策略：保留、收敛、屏蔽
该保留的
分页参数、真正改变内容结果的筛选参数，可以保留。但要尽量让参数数量少、命名稳定，并给每个筛选组合一个可被理解的含义。不要为了“多生成页面”而随意组合参数。
该收敛的
- 广告跟踪参数只在落地页生效，站内跳转时去掉。
- 分享链接使用统一短链或规范地址，而不是直接复制带参数的浏览器地址。
- 会话 ID 尽量用 Cookie 承载，不要长期出现在 URL 中。
- 相同内容的不同参数版本，用 canonical 指向主地址。
可以屏蔽的
站内搜索结果页、排序参数、价格区间等组合数量很大的地址，可以通过 robots.txt 限制抓取，或在页面层面加 noindex。但要注意，robots.txt 只是阻止抓取，不是阻止收录；如果其他页面链接过去，搜索引擎仍可能收录无描述的结果。所以通常要配合 noindex 和链接控制。
容易踩的坑
不要把 robots.txt 当成万能钥匙：屏蔽抓取后，如果外部链接大量指向该地址，它仍可能出现在搜索结果里，只是没有摘要。更好的做法是从源头减少这类地址的暴露。
另一个常见问题是 canonical 写错。比如把所有分页都指向第一页，或者把不同筛选结果都指向同一个列表页。这类操作可能让蜘蛛忽略真正有差异的内容。canonical 应该用于“相同或高度相似”的页面，而不是用来掩盖内容差异。
小结
URL 参数自查不需要一次做完，可以先从跟踪参数和站内搜索参数开始。每周抽一点时间，看看日志和搜索结果中出现了哪些奇怪的参数地址，判断它是功能所需还是运营噪声。把该保留的保留，该收敛的收敛，该屏蔽的屏蔽，站点结构会清爽很多，蜘蛛和统计工具也能少做一些无用功。