把“有效地址集合”定义成一份可枚举的规则清单,而不是一份完整URL列表。当筛选参数、排序参数、会话参数可以任意组合时,URL总数在数学上就是发散的,你无法先穷举再修复。可执行的最小动作是:从你手上已有的日志、站点地图或页面模板中,选出参数名固定、取值可枚举的那部分,写成“允许保留的参数组合白名单”,其余组合统一归入“应返回410或301”的集合。这个动作能让你立刻得到一份可判定的规则,但推不出“所有坏链都已覆盖”——白名单之外的合法长尾组合会被一并判死,需要靠后续抽样验证来修正。
无限增长通常来自两层叠加:参数名本身可能被拼凑,参数值又可能是开放集合。处理顺序应当相反:先锁参数名,再谈取值。
sort、page、filter_color。这类可以逐条决策,进入白名单或黑名单。把这两层分开后,“有效地址集合”就从“所有能打开的URL”收缩为“参数名在白名单内、且取值满足约束的URL”。这一步是定义问题,不是修复问题,但没有它,后面的修复无法收敛。
假设你手上只有一份页面模板和一周的访问日志,没有全站爬取权限。可以按下面的结构写规则表,每一行是一个可判定的条件:
{sort, page, filter_color, filter_size} 内,且 page 为1至50的整数,其余参数取值在各自枚举表内。写完规则表后,先不要全量执行。取日志中出现频次最高的一批URL,按规则表逐条判定,人工核对判定结果与实际内容是否一致。如果发现某类被410的URL其实承载了独立内容,就把该类补进白名单。这个核对动作直接决定规则表能否上线:判定偏差集中在哪一类,就先修那一类,而不是先改全局规则。
在没有全站日志、没有抓取工具权限的情况下,仍然可以执行的最小动作是:
这个动作的结果是一个可观测的命中计数。它可以告诉你哪些参数组合在被实际请求,但不能告诉你这些请求是否来自搜索引擎、是否曾被索引、是否值得保留。命中量归零也不等于处理正确:可能是爬虫尚未重新访问,可能是规则误伤了合法组合,也可能是请求被上游缓存拦截。要区分这些解释,需要另取一份带来源标识的日志,或对规则命中样本做人工抽检。
假设某分类页支持 color 与 size 两个筛选参数,各有10个取值,另有 sort 3个取值。理论组合数为10×10×3=300,再叠加参数顺序和追踪参数后,可观测URL数会远超300。若把 sort 从URL中移除、改为页面内交互,有效地址集合立即从300收缩到100。这个收缩是定义层面的,不依赖任何抓取数据。但要注意:如果 sort 的某个取值对应独立落地页且已有外部链接指向它,移除后这些链接会指向410,需要先确认外链分布再决定是否保留。这一步的判断依据是外链数据,不是参数数量本身。
规则表上线后,可以用站点地图提交规范URL、用 robots.txt 限制无价值参数的抓取,但这两者都不构成对索引结果的保证。robots.txt 的抓取限制不等于可靠的索引移除,已被索引的URL仍可能出现在结果中;站点地图也不保证收录。验证时应分别核查不同搜索引擎对参数处理和410响应的支持情况,不要把某一家的表现当作通用结论。HTTPS 同样不解决这里的地址集合问题,它只影响传输层,与参数规范化无关。
最终可交付的不是一份“所有坏链已修复”的清单,而是一份带适用条件的规则表:它明确了哪些参数组合被定义为有效、哪些被排除、排除依据是什么,以及在哪些数据缺失的情况下该结论暂不成立。后续每获得一类新数据,就回来修正对应规则,而不是重新枚举URL。