直接回答:不要试图让抓取端去穷举所有参数组合,而是由你自己先声明一个“有效地址集合”——即哪些参数组合代表独立内容、哪些只是同一内容的变体、哪些组合根本不该生成页面。这个集合必须能从服务端逻辑中推导出来,而不是靠事后从日志里归纳。做不到这一点,参数组合的增长速度永远快过任何抓取配额。
常见的情形是:站内可访问的带参地址从几万涨到几十万,但真正有独立价值的页面数量基本没动。筛选、排序、分页、追踪、会话、展示偏好这些参数两两相乘,组合空间就是指数级的。抓取预算被摊薄,已收录的地址反复被抓,新内容反而进不了队列。
这里有一个容易被忽略的遗漏条件:你从未定义过“一个地址是否值得存在”的判定规则。常规做法——加 canonical、写 robots.txt、提交站点地图——都是在地址已经生成之后做补救,而参数组合是在生成之前就爆炸的。补救的速度追不上生成的速度。
解释一:抓取端在浪费预算。如果判断成立,那么带参地址本身是有意义的,只是被抓取时优先级排错了。处理方向是调整抓取引导,比如把有效组合写进站点地图、把无效组合用 robots.txt 挡掉、在页面里明确 canonical。
解释二:地址集合本身没有被定义。如果判断成立,那么问题不在抓取端,而在于服务端对任意参数组合都返回 200 和完整内容。抓取端只是忠实地发现了你允许存在的所有地址。这种情况下,改 robots.txt 或站点地图只能缓解表面症状,参数空间仍会继续膨胀。
两种解释的差别在于:前者是抓取优先级问题,后者是地址生成逻辑问题。用同一套手段处理两者,通常无效。
不需要复杂工具,用几组对照就能缩小范围:
curl -I 看返回码。如果大量语义上等价、只是参数顺序不同的地址都返回 200,说明服务端没有做规范化,偏向解释二。这些证据的共同点是:它们检验的是“地址是否被服务端主动约束”,而不是“抓取端是否听话”。参数顺序不同但内容相同的地址返回 200,是地址集合未定义的直接信号。
假设一个商品列表页支持品牌、价格区间、排序方式、页码四类参数。先列出哪些组合代表独立内容:品牌加页码可以是独立内容,价格区间加页码也可以是,但排序方式通常只是同一内容的展示顺序,不应生成独立地址。基于这个判断,在服务端做三件事:
做完这三步后,再观察抓取日志。如果带参地址的抓取比例下降、规范地址的抓取比例上升,说明约束生效;如果比例不变,说明重定向没有覆盖全部参数模板,需要回到第一步重新枚举。这个反馈循环本身就是定义集合的一部分。
robots.txt 的抓取限制不等于索引移除。一个地址被 robots.txt 挡住抓取后,如果它曾被索引或从他处获得链接,仍可能出现在结果里,只是摘要信息可能过时。所以用 robots.txt 处理参数地址时,要清楚它挡的是抓取,不是索引状态。
另外,不同搜索引擎对参数处理和重定向的支持程度不一致,规范化的效果需要分别核查,不能假设一处生效即处处生效。HTTPS 与地址集合的定义无关,它不解决参数膨胀,也不保证收录结果。
最后,如果请求量或抓取量在调整后归零,不能单独证明处理正确。归零也可能来自服务器故障、robots.txt 误封整站、或重定向链过长导致抓取中断。要结合返回码分布和规范地址的抓取比例一起判断,而不是只看总量变化。