📍 WDQWDWQD987AAAAA:216.73.216.39
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /2023cd60c77a.html
📄

死链检查：动态页面怎样确认可见内容

动态页面做死链检查时，不能只看HTTP状态码。状态码200只说明服务器接受了请求，不代表页面主体已经渲染出有效内容；状态码404也不一定说明用户看不到东西，有些站点会用404状态返回一个“内容不存在”的提示页。要确认可见内容，核心方法是把“服务器返回的原始HTML”和“浏览器渲染后的DOM”分开检查，再判断链接目标是否真的可用。

先区分三种“可见”：源码可见、渲染可见、用户可见

动态页面的内容通常由JavaScript在浏览器端填充，因此同一URL可能出现三种结果：

• 源码可见：在原始HTML里就能找到链接、文字或目标地址。
• 渲染可见：执行脚本后，DOM中出现内容，但可能被CSS隐藏、被弹窗遮挡，或需要登录才显示。
• 用户可见：真实用户在常见视口、常见交互路径下能读到、点到。

死链检查要解决的是“这个链接指向的目标是否还有效”，所以不能停在源码层。对动态页面，至少要把渲染后的DOM作为主要证据。

用浏览器开发者工具收集第一手证据

打开目标页面，按F12进入开发者工具，按以下顺序操作：

1. 在Network面板勾选Preserve log，刷新页面，记录所有请求的状态码和响应类型。
2. 在Elements面板搜索目标链接文字或目标URL片段，确认它是否出现在渲染后的DOM中。
3. 如果链接由脚本生成，在Console执行document.querySelectorAll('a')，检查返回的锚点数量和href值。
4. 对可疑链接，右键选择“检查”，看它是否被父元素设置display:none、visibility:hidden或尺寸为0。

判断结果时注意：如果链接在DOM中存在，但被隐藏，它不算用户可见内容；如果链接可见但点击后进入404，它才是需要处理的死链。如果链接在源码中不存在、渲染后才出现，那么用普通爬虫抓源码做死链检查会漏报或误报。

动态页面死链检查的两种路线及代价

确认可见内容时，常见做法有两类：

• 渲染式检查：用无头浏览器或带渲染能力的工具，等待页面稳定后抓取DOM和网络请求。优点是接近用户所见，能发现脚本生成的链接；代价是速度慢、资源消耗高，等待时间设置不当会漏掉异步内容。
• 请求式检查：直接请求URL，只分析状态码和响应头。优点是快、适合大批量；代价是无法确认动态内容是否真的渲染出来，容易把“200但空白”的页面当成正常。

选择依据是页面动态程度和检查目的。如果只是定期扫描全站、找出明显404，请求式可以先跑一轮；如果要确认某个动态列表、筛选页或单页应用里的链接是否可见可用，就必须用渲染式复核。两者结果不一致时，以渲染后用户能看到的DOM为准，再回查请求日志定位原因。

检查项清单与结果判断

对每个可疑动态页面，逐项核对：

• 目标URL返回的状态码是什么，是否经过重定向，重定向终点是否200。
• 渲染后DOM中是否存在对应锚点，href是否为空、为javascript:void(0)或指向当前页。
• 锚点是否被CSS隐藏、被其他元素覆盖，或位于需要滚动、点击、登录后才出现的区域。
• 点击后是否进入有效内容页，还是进入统一错误页、空白页或跳回首页。
• 如果页面依赖接口返回数据，接口是否成功、返回结构是否变化，导致链接未生成。

判断规则可以简化为：状态码正常且渲染后可见、点击后到达有效内容，才算通过；状态码正常但渲染后无对应内容，记为“疑似失效”，需要继续查接口和脚本；状态码为404或410，且渲染后也没有有效替代内容，记为死链。

把结论落到可执行的修复与复检

假设某个商品筛选页的“下一页”链接在源码中不存在，渲染后DOM里也找不到，但接口返回了空列表。此时不能直接判定链接死链，而应先确认是筛选条件确实无结果，还是接口异常导致分页未生成。修复时优先处理数据或脚本问题；如果该链接已无对应内容，应返回410或做301到相关分类页，而不是保留一个点击后空白的按钮。

复检时用同一套渲染条件再跑一次：相同视口、相同等待时间、相同登录状态。只有条件一致，前后结果才可比较。对动态页面，建议把“渲染后DOM中是否存在有效href”作为固定检查项，而不是只看HTTP状态码。

下一步：挑一个你怀疑有问题的动态页面，按上面的清单记录状态码、渲染后DOM和点击结果，先形成一条可复核的证据链，再决定是修脚本、改数据还是调整链接指向。