死链检查工具，批量重定向修好了却让参数页全变404怎么办
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /a5c0315df10e.html
📄
死链检查工具，批量重定向修好了却让参数页全变404怎么办
先别继续扩大重定向规则。这个现象通常不是“死链检查工具没查干净”，而是修复动作把两类原本独立的依赖绑在了一起：一类是旧路径到新路径的跳转，另一类是查询参数进入页面的解析逻辑。要拆开它，先把重定向规则按“是否保留查询参数”分组，再用死链检查工具分别验证无参数路径和带参数路径，确认异常只出现在哪一组。
两个解释：规则覆盖过宽，还是参数解析被跳过
第一种解释是重定向规则覆盖过宽。假设你把所有旧栏目路径统一指向新栏目首页，且规则里没有显式保留查询字符串，那么带参数的旧地址会被送到一个不带参数的落地页，参数页看起来就像全部消失。第二种解释是参数解析被跳过。即使查询字符串被保留，如果落地页不再读取某个参数，或者参数名在新路由里已经改变，页面仍可能返回404或空内容。
这两种解释的修复方向完全不同：前者要收窄规则并补上查询参数保留条件，后者要回到模板或路由层检查参数读取逻辑。把两者混在一起改，很容易出现“修好一批、又坏一批”的循环。
区分证据：同一路径加不加参数，结果是否分叉
用死链检查工具跑一组对照最直接：同一批旧路径，分别以不带参数和带参数两种形式请求，记录状态码、最终URL和页面标题。如果只有带参数形式异常，而同一路径的无参数形式正常，说明问题更偏向参数传递或解析；如果两种形式都异常，说明重定向本身没有命中或规则顺序有冲突。
- 带参数请求最终落到不带参数的URL，且返回200：优先怀疑重定向丢弃了查询字符串。
- 带参数请求最终URL保留了参数，但仍返回404：优先怀疑落地页不再识别该参数。
- 无参数和带参数都返回404：优先怀疑规则没有匹配到该路径，或规则被更靠前的规则拦截。
这些证据只能缩小范围，不能单独证明结论。比如带参数请求返回200，也可能是页面本身对未知参数做了兜底展示，并不代表参数仍被业务逻辑使用。
拆依赖链：把重定向层和参数层分开验证
先暂时停用所有新增的批量重定向，只保留一条最小规则，指向一个明确知道会读取查询参数的测试路径。用死链检查工具请求这条路径的无参数和带参数版本，确认参数层本身是否工作。这一步的结果决定下一步：如果参数层正常，问题就在重定向规则；如果参数层也异常，说明修复动作已经影响到了路由或模板，应该先回退参数相关改动，再谈重定向。
确认参数层正常后，再逐条恢复重定向规则，每恢复一组就跑一次对照请求。这里的实际动作是“按规则分组恢复并复测”，它的结果是让你找到第一条让带参数路径开始异常的规则。找到之后，不要直接删掉它，而是检查它是否缺少查询字符串保留条件，或者是否把带参数路径错误地归入了无参数规则。
一个假设例子：规则顺序如何制造假象
假设旧站有 /old/list 和 /old/list?tag=a 两类地址，新站对应 /new/list 和 /new/list?tag=a。如果第一条规则写成把 /old/list 全部指向 /new/list 且不保留查询，第二条规则又试图把带参数的旧地址指向带参数的新地址，那么第一条规则会先命中，第二条永远不会执行。死链检查工具看到的结果就是带参数地址全部落到无参数页面，看起来像参数页集体404。
这个例子里，修复不是增加更多规则，而是调整规则顺序，并给第一条规则加上“仅匹配无查询字符串”的条件。调整后再次用死链检查工具对照请求，如果带参数路径开始保留参数并返回正常内容，才说明依赖链被拆开了。
什么时候该换策略：前提变化后的判断条件
如果参数在新站已经不再承担筛选或定位作用，那么保留参数的修复方向就不成立。此时更合理的做法是让带参数旧地址跳到对应的无参数新页面，并确认这个无参数页面能覆盖用户原本想找的内容。判断条件可以看两点：带参数地址的访问是否仍会带来有效业务行为；无参数页面是否已经能表达同样的内容范围。两点都满足时，丢弃参数是取舍，不是故障。
反过来，如果参数仍决定页面展示哪一组内容，就必须保留参数并在落地页恢复读取逻辑。无论选哪条路，都要用死链检查工具分别验证无参数和带参数两组结果，而不是只看总量是否下降。请求量或异常数归零，可能只是规则把流量提前拦掉了，并不等于参数页恢复正常。
