先给一个有条件的结论:当参数组合理论上无限增长时,不要试图枚举或逐一修复所有地址,而应先用“参数白名单 + 规范化规则”定义一个有限的有效地址集合,只让落在这个集合内的 URL 返回正常内容,其余一律返回 404 或 410。这个结论成立的前提是:你的站点确实存在一批业务上有效的参数页面,且团队能就“哪些参数参与内容生成”达成一致。如果参数只是用于跟踪、排序、会话或分页偏移,那么这个结论会失效,因为此时任何参数组合都不该被当作独立有效地址。
参数组合增长通常来自筛选、排序、分页、追踪码几类入口的叠加。假设一个列表页有 5 个筛选维度,每个维度 3 个可选值,仅筛选组合就有 3 的 5 次方种,再乘上排序与分页,数量会迅速超出任何人工清单能覆盖的范围。此时把每个组合都当成一个待修复的死链接,工作量没有上界;把每个组合都当成有效页面,又会制造大量内容重复或空白页。真正需要先定的是有效集合的边界,而不是修复动作本身。
不同角色对“同一事实”的理解差异往往就在这里:运营认为带追踪参数的地址是同一个页面,开发认为参数不同就是不同请求,SEO 认为只有返回实质内容的地址才值得保留。把这三种理解混在一起讨论,结论永远对不齐。可行的做法是把分歧转成可核对的规则,而不是继续争论哪个地址“算不算死链”。
第一层是参数白名单。列出所有会改变页面主体内容的参数名,例如分类、地区、页码这类参与查询的参数;把追踪、会话、来源标记类参数排除在白名单之外。只有白名单内的参数参与地址有效性判断,白名单外的参数在规范化阶段被剥离或忽略。
第二层是组合约束。即使参数名在白名单内,也不是任意组合都有效。可以规定:同一维度只允许一个取值,维度之间存在互斥关系时只保留优先级最高的一个,页码超过实际结果范围时返回 404 而非空列表。这样有效地址集合就从“参数名的笛卡尔积”收缩为“业务上真实存在的组合”。
一个注明假设的短例子:假设某站只有“颜色”和“尺码”两个筛选维度,颜色有 4 个取值,尺码有 5 个取值。若不加约束,理论组合是 20 个;若业务上只有 12 个组合存在对应库存,那么有效集合就是这 12 个,其余 8 个应返回 404 或 410。这里的数字只为说明比较方法,不代表任何真实站点数据。
确定规则后,实际动作是给站点加一层地址规范化:对进入的请求先解析参数,剔除白名单外参数,检查组合是否落在有效集合内,再决定返回内容、重定向还是 404/410。这个动作的结果会直接影响下一步:
需要提醒的是,robots.txt 的抓取限制不等于可靠的索引移除,把无效参数地址写进 robots.txt 只能减少抓取,不能保证它们从索引中消失。站点地图也不保证收录,它只是提交你认为是有效集合的地址。不同搜索引擎对参数处理和规范化信号的支持情况须分别核查,不能假设一套规则在所有引擎上表现一致。
如果参数并不参与内容生成,而只是用于前端排序、会话保持或广告追踪,那么“参数白名单 + 组合约束”这套定义方式就会失效。此时正确的有效集合应是不含这些参数的单一地址,任何带这类参数的请求都应被规范化到该地址,而不是被纳入有效集合。判断依据可以核对:关掉该参数后页面主体内容是否发生变化。若内容完全相同,它就不该进入白名单。
另一个会让结论失效的情况是:团队无法就哪些参数参与内容达成一致,且没有可核对的证据。这时先不要动手改地址规则,而应把每个候选参数单独做一次内容对比,用“参数变化是否引起主体内容变化”作为可核对的判据,把分歧转成一份有证据的参数清单,再回到白名单步骤。
先取一个参数最多的列表页,记录它当前接受的全部参数名。对每个参数名做一次单独对比:只改这一个参数,观察页面主体内容是否变化。把引起变化的参数列入候选白名单,不引起的列入排除清单。然后检查候选白名单内参数之间是否存在互斥或从属关系,写出组合约束。最后用这组规则去核对一批实际请求,看返回结果是否符合预期。只有这一步核对通过,才值得把规则推广到全站,否则先修正规则本身。