站长工具死链：部分页面正常而特定参数异常时怎样缩小复现条件
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /4ffa0d7d72c6.html
📄
站长工具死链：部分页面正常而特定参数异常时怎样缩小复现条件
先把“异常”从一句模糊描述改写成可复现的请求三元组：路径、查询参数组合、请求上下文。然后只保留一个变量，其余全部固定，逐次请求并记录返回。站长工具死链报告里同一条路径可能对应多个参数变体，若只盯着路径本身，就会把“参数组合触发”误判成“整页失效”。
先区分：是路径异常，还是参数变体异常
同一个路径下，无参数版本返回正常，带参数版本出现死链，说明问题不在页面模板本身，而在参数被服务端、CDN或前端路由处理的方式。缩小复现条件的第一步，是建立一张最小对照表，而不是急着改配置。
- 固定项：域名、协议、路径、请求方法、User-Agent、是否携带 Cookie。
- 变量项：查询参数的名称、顺序、数量、编码方式、是否为空值。
- 记录项：HTTP 状态码、最终跳转地址、响应体是否含错误提示、响应时间。
如果无参数正常、单参数异常，优先怀疑参数白名单或重写规则；如果单参数正常、多参数组合异常，优先怀疑参数拼接、转义或长度限制；如果同一参数换个顺序就正常，问题更可能在缓存键或路由匹配顺序。
用二分法缩小参数组合，而不是逐个试
当参数很多时，逐个组合成本高。更实际的做法是对参数集合做二分：把参数分成两组，分别请求，观察哪一组触发异常。触发异常的那组继续二分，直到剩下最少参数组合。这个动作的结果直接决定下一步查哪一层：如果异常只在“参数A+参数B”同时出现，就不必再查参数A单独的处理逻辑。
假设一个页面有五个查询参数，无参数正常，全参数异常。先请求前三个，正常；再请求后两个，异常。那么问题集中在后两个参数。继续拆开后两个，若只有一个触发异常，就得到单一可疑参数；若两个都正常但合在一起异常，则指向参数间的交互逻辑。这里的数字只是说明比较方法，不代表任何真实页面的统计结果。
检查参数在链路中哪一段被改写
缩小到具体参数后，还要确认它在到达源站前是否被改写。常见改写点包括：CDN 的缓存键与规范化规则、反向代理的重写规则、应用框架的路由解析、前端路由的 history 处理。判断方法是对比“直接请求源站”和“经过完整链路请求”的返回差异。
如果直接请求源站正常、经过完整链路异常，问题在中间层；如果两者都异常，问题在应用或源站配置。这个区分动作会直接影响下一步：中间层问题查缓存键和重写规则，源站问题查参数解析和错误处理。
需要留意，robots.txt 的抓取限制不等于可靠的索引移除，它只能阻止抓取，不能保证已索引的变体消失。参数变体若已被抓取，处理死链时还要考虑这些变体是否仍会被内部链接或站点地图引用。
把复现条件写成可交接的最小用例
缩小条件的终点不是“我这边能复现”，而是别人按记录也能复现。最小用例应包含：完整请求地址（含参数顺序与编码）、请求方法、必要请求头、预期返回、实际返回、复现次数。缺少参数顺序或编码方式，往往导致第二次复现失败。
如果异常只在特定 User-Agent 或特定 Referer 下出现，也要写入用例。这类条件容易被忽略，却常是缓存命中差异或访问控制规则触发的直接原因。
验证修复时，先确认异常变体不再被引用
修复参数处理逻辑后，还要检查站内是否仍有链接、站点地图或重定向指向该异常变体。站点地图不保证收录，但被站点地图引用的异常地址会持续制造新的抓取请求。处理动作是：从内部链接和站点地图中移除异常变体，保留正常路径，再观察站长工具死链报告中该变体是否停止新增。
如果新增停止，说明修复覆盖了引用来源；如果仍新增，说明还有未发现的引用位置，需要回到最小用例继续查请求来源。这个判断不能只看单次报告归零，因为报告存在延迟，且归零也可能只是抓取周期未到，需要结合引用来源是否清理完成来确认。
最终可执行的顺序是：固定上下文、二分参数、定位改写段、写最小用例、清理引用、复查新增。每一步的结果都决定下一步查哪里，而不是同时改动多个变量。
