死链检查：入口页面正常但深层链路失效时怎样定位断点
📱 Mozilla/5.0 (compatible; QlyzeBot/1.0; +https://app.qlyze.io/bot)
🔗 /52fecd8a5dde.html
📄
死链检查：入口页面正常但深层链路失效时怎样定位断点
先给一个有条件的结论：当入口页面返回正常、而深层页面失效时，断点通常不在入口本身，而在入口到深层页面之间的某一跳——可能是链接指向的 URL 变了、中间层做了重定向、参数被丢弃、权限或会话状态在深层才生效，或者深层页面依赖的资源单独失效。要定位它，不能只看入口的状态码，而要把“入口→中间跳→目标”逐跳还原成可核对的项目。若入口页面本身是纯前端渲染且深层链接由客户端路由接管，那么服务端抓取到的入口 HTML 可能根本不包含真实深层链接，此时逐跳还原的前提就不成立，需要改用渲染后的 DOM 或抓取日志来核对。
先区分“链路断”与“页面断”
入口正常、深层失效，至少有两种不同性质：一种是链接关系断了，即入口里那个 <a href> 指向的地址已经不存在；另一种是页面本身还在，但深层 URL 只有在特定条件下才返回正常内容。判断方法很直接：把深层 URL 单独拿出来请求，看它返回什么。
- 单独请求深层 URL 就返回 404 或 410：断点在目标地址本身，入口只是把旧地址暴露了出来。
- 单独请求正常，但从入口点击后失效：断点在跳转过程，重点查重定向链和参数传递。
- 单独请求返回 200 但内容是空壳或错误提示：断点在内容层，状态码不能作为唯一证据。
这一步的动作是把深层 URL 从入口的链接里原样复制出来，脱离点击行为直接请求。结果会直接决定下一步：如果是目标地址本身失效，就去改链接或做跳转；如果是跳转过程失效，就去查中间每一跳。
把重定向链逐跳展开，找出哪一跳改变了语义
深层链路失效最常见的原因是中间发生了重定向，而重定向过程中丢失了路径、参数或大小写。例如入口链接指向 /list?page=3，中间层把它跳到 /list，页码参数被丢掉，于是用户看到的是第一页而不是深层内容，误以为“深层失效”。
核对时记录每一跳的地址、状态码和最终落点，重点看三件事：路径是否被截断、查询参数是否保留、协议或域名是否被改写。只要有一跳改变了这三者中的任何一个，后续页面就可能拿不到正确内容。这个动作的结果是得到一条完整跳转链，断点通常就落在语义第一次变化的那一跳。
用站点地图和抓取日志交叉验证，而不是互相替代
站点地图里列出的深层 URL 和实际被抓取的 URL 往往不一致。站点地图不保证收录，它只能说明你希望被发现什么；抓取日志才能说明实际发生了什么。把两者对照，可以区分两种原因：
- 站点地图有、日志里从没出现：链接可能根本没被爬到，问题在发现路径，不在目标页面。
- 日志里有、返回状态异常：问题在目标页面或它的响应条件。
- 日志里反复抓取同一深层地址但结果不同：问题可能出在参数、会话或缓存，而不是链接本身。
这里要避免一个误判：抓取量下降或某个深层地址在日志里消失，不能单独证明链路已经修好，也不能证明它已经失效。它还可能只是抓取预算重新分配、入口页面改版后链接位置变化，或日志采样口径不同。把日志当唯一证据会得出错误结论。
把分歧转成可核对的项目
多个角色对“深层到底通不通”有不同理解时，争论通常来自各自看到的层面不同：前端看到的是点击后的界面，后端看到的是接口返回，SEO 看到的是抓取到的 HTML。把分歧变成一张核对表，比反复讨论更有效。
- 列出从入口到深层的最短路径，标出每一跳的 URL。
- 对每一跳记录：请求地址、状态码、最终落点、是否保留参数。
- 对最终深层页面记录：返回内容是否包含预期的主体信息，而不只是状态码。
- 对入口页面记录：深层链接是出现在初始 HTML 里，还是渲染后才出现。
完成这张表后，多数分歧会收敛到同一跳。若仍然不一致，差异通常来自渲染方式或请求条件，而不是事实本身。
一个假设例子：参数在中间层被丢弃
假设入口页面 /category 正常返回 200，页面里有一个指向 /item?id=42&from=list 的链接。点击后用户看到的是列表页而不是详情页。逐跳核对发现：/item?id=42&from=list 被中间层 301 到 /item，id 参数丢失，于是 /item 返回一个通用页。此时断点不是入口，也不是详情页不存在，而是中间重定向没有保留查询参数。修复动作是让重定向保留原始查询串，然后重新核对最终落点是否回到 id=42 的详情内容。这个结果会直接改变下一步：如果重定向修好后仍失效，才需要继续查详情页本身的响应条件。
什么时候上面的方法会失效
如果入口页面是纯客户端渲染，服务端返回的初始 HTML 里可能没有任何深层链接，逐跳还原就无从下手。此时需要改用渲染后的 DOM 或实际抓取记录来定位，否则会把“服务端 HTML 里没有链接”误判成“深层链路断了”。另一个失效条件是深层页面依赖登录态或地域条件：未登录请求返回 200 但内容是登录提示，状态码正常不代表链路正常，必须结合内容判断。
下一步动作
先固定一条最短路径，逐跳记录地址、状态码、最终落点和参数保留情况，再对照站点地图与抓取日志确认发现路径是否成立。若某一跳改变了语义，就修那一跳并重新核对最终内容；若所有跳都正常但内容仍不对，就把判断标准从状态码切换到实际返回的主体信息。这样得到的结论可以复查，也能让不同角色在同一组事实上对齐。
