如何检查网站死链，部分页面正常而特定参数异常时怎样缩小复现条件
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /f3ce622d46df.html
📄
如何检查网站死链，部分页面正常而特定参数异常时怎样缩小复现条件
先别急着把整站扫一遍。正确的顺序是：从异常 URL 中拆出变量，固定其余条件，一次只改一个参数，直到找到能稳定复现的最小组合。下面用一个假设情境说明这个过程。
先确认你手里是同一类异常
假设某分类页 /list?page=2&sort=new 返回 404，而 /list?page=2 和 /list?sort=new 都正常。此时有两种解释：一是链接生成规则漏掉了参数组合；二是服务端对参数组合做了白名单校验，未登记的组合被拒。两者的修复方向完全不同。
区分方法：直接手工构造这几种组合并记录状态码，再看页面内其他链接是否也指向同样的组合。如果只有带 sort 的分页链接出错，而单独访问 sort 正常，问题更可能出在链接拼接环节；如果所有含该组合的请求都被拒，则更可能是服务端规则。
把变量拆开，一次只动一个
列出该 URL 上所有可能变化的成分：路径、参数名、参数值、参数顺序、大小写、编码方式、是否带尾斜杠。然后像做对照实验一样逐个固定。
- 固定路径，只改参数值：把
sort=new换成sort=old，看是否仍异常。 - 固定参数值，只改参数名：换成另一个已知可用的参数名。
- 固定参数内容，只改顺序：把两个参数前后对调。
- 固定全部内容，只改编码：对值做 URL 编码后再请求。
如果只有第 4 步恢复正常，说明问题出在编码处理而非参数本身，下一步应检查链接生成时是否对值做了必要转义，而不是去改服务端白名单。
用最小复现组合判断责任层
找到能稳定出错的最小组合后，再往上加条件，看异常在哪一步消失或出现。常见的分界点有三个：
- 只在站内跳转时出错：说明外部直接访问正常，问题在链接生成或前端拼接。
- 直接访问也出错：问题在服务端路由、参数校验或上游配置。
- 换一种请求方式就正常：说明差异来自请求头、方法或缓存层，而非 URL 本身。
这一步的实际动作是：把最小复现组合连同观察到的状态码、响应头和是否命中缓存一起记下来，交给对应环节的人。记录越具体，越不容易被当成偶发问题搁置。
别把抓取限制当成已解决的证据
有时异常页面在 robots.txt 里被限制抓取，有人据此认为问题已处理。但抓取限制不等于可靠的索引移除，被限制的 URL 仍可能因外部链接而被收录。同样，站点地图不保证收录，提交与否不能作为页面是否正常的证据。
如果异常 URL 是 HTTPS，也不能据此推断它安全或已被正确处理。协议与死链判定是两件事，需要分别核查。
还有一个容易被忽略的解释：请求量或抓取量下降，并不单独证明你的修复生效。它也可能来自抓取预算调整、外部链接变化或统计口径变化。要确认修复结果，应回到那个最小复现组合，重新请求并对比状态码，而不是只看总量曲线。
修复后只回归那一组条件
修复动作完成后，先验证最小复现组合是否恢复正常，再逐步加回其他参数，确认没有引入新的异常组合。如果不同搜索引擎对参数处理的支持情况不同，需要分别核查，不要用一家的结果推断另一家。
最后把这次的最小复现组合加入日常检查项，而不是重扫全站。这样下一次出现类似异常时，你能更快判断它属于同一类问题还是新问题。
