做站点运营，很多人把注意力放在新页面怎么被更快发现上，却忽略了另一件更耗资源的事：站点自己在源源不断地生产 URL。列表页的筛选、排序、视图切换、每页条数、会话标识，每一项都可能让同一批内容对应出几十上百个地址。蜘蛛顺着这些链接爬，抓到的往往是高度重复的页面。
URL 膨胀是怎么发生的
假设一个列表页有 5 个筛选维度，每个维度有 8 个可选值，理论上能组合出三万多条 URL，而里面展示的内容大部分是重叠的。排序参数更典型：默认排序、价格升序、价格降序、销量排序、上架时间排序，只要这些是 HTML 里真实可点的链接，蜘蛛就会一个个爬过去。再叠加“每页显示 20/50/100 条”“列表视图/网格视图”这类参数，数量涨得比想象中快。
这些页面本身不算错误，问题在于它们会把抓取量摊薄。同一份内容被反复抓取，真正需要更新、需要被发现的页面反而排不上队。
先分清哪些参数代表内容
处理之前要先分类，思路大致是三种：
- 内容型参数：用户会主动搜索这个组合，比如某个颜色加某个尺码，这类组合有独立需求，可能值得保留。
- 排序与视图型参数：只改变了展示顺序或布局，内容没变，通常不需要被收录。
- 追踪与会话型参数：utm 来源、会话 ID、ref 之类，对用户和蜘蛛都没有意义，属于纯噪音。
只有第一类存在被收录的理由，后两类基本是抓取预算的消耗品。
一份可执行的自查清单
- 在服务器日志里按查询字符串做统计：带问号的请求占总请求的比例是多少，出现频率最高的参数是哪些。
- 用站内搜索指令查一下自己域名下带参数的 URL 大概有多少条进入了索引。
- 打开列表页源码，确认筛选和排序是普通链接、按钮，还是表单或脚本提交。
- 检查站内搜索结果页是否可以被直接抓取和收录。
- 检查分页与筛选叠加后产生的 URL，例如同时带 page 和多个筛选条件的地址。
把这五项跑一遍，通常就能看出问题集中在哪几个参数上，不必对全站动手。
处理手段和它们的边界
能改链接形式就先改
排序、视图切换尽量用表单或脚本触发，不在 HTML 里生成可爬的链接。这一步成本最低，也不会带来屏蔽风险，属于优先项。
想清楚是要“少抓”还是“不收录”
这两个目标对应不同手段，混用容易出问题。robots.txt 屏蔽的是抓取，不是索引；被屏蔽的 URL 如果被外链引用，仍可能出现在搜索结果里，只是没有摘要描述。
如果目标是“不希望它被收录”，让页面自己返回 noindex 更可靠；如果目标是“减少抓取压力”，才考虑用 robots.txt 屏蔽。反过来，一旦用 robots 挡住了抓取，蜘蛛就读不到页面上的 noindex，两者很难同时生效。
canonical 指向主版本
对于保留下来的参数页面，可以在页面里把 canonical 指向无参数的主版本，帮助搜索引擎理解哪一个是代表地址。注意 canonical 是建议而不是强制指令，如果参数页本身有独立搜索需求，就不适合强行指向主版本。
站内搜索结果页建议单独处理
站内搜索产生的页面数量不可控，且内容随查询词变化，多数情况下没有独立价值，可以设置为不收录，同时保留用户正常使用。
会话与追踪参数在服务端忽略
如果条件允许，让服务端直接忽略这些参数，用户看到的地址更干净，也不会额外产生新 URL。
改完之后看什么
回到日志里看两个指标：带参数 URL 的抓取占比有没有下降，以及被收录的参数页数量有没有收敛。这类变化通常不是立刻发生的，蜘蛛需要一段时间重新评估，观察周期拉长一点更稳妥。
最后提醒一句：不要一次性把所有带参数的地址全部屏蔽。有些参数确实承载着用户的搜索需求，一刀切会把本来能带来访问的页面一起挡掉。建议先从日志里占比最高、内容重复最严重的几个参数动手，观察一段时间再做下一步决定。