死链接检测, 怎样判断问题属于哪一层
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /f663a4ad7fbe.html
📄
死链接检测, 怎样判断问题属于哪一层
判断死链接检测中的问题属于哪一层，核心是看“链接是在哪一步失效的”：是页面里写错了地址，是服务器返回了错误状态，是跳转链断了，还是搜索引擎根本没抓到它。先分层，再决定是改内容、改服务器还是改抓取配置，能避免把服务器问题当成编辑问题反复修。
先分清死链接检测的四个常见层
做死链接检测时，同一个“打不开”的现象可能来自不同层。可以按下面顺序排查：
- 内容层：
href写错、相对路径拼错、锚文本指向了已删除页面。 - 服务器层：地址本身没错，但返回 404、410、500 或 503。
- 跳转层：原地址 301 或 302 到另一个地址，而目标地址又失效，形成跳转链断裂。
- 抓取层：链接在浏览器能打开，但被
robots.txt禁止抓取，或页面没有被搜索引擎发现。
判断顺序建议从服务器层开始，因为状态码最客观。用命令行对单个 URL 发起请求，看返回状态：
curl -I -L https://example.com/old-page
如果返回 404 或 410，问题在服务器层或内容层；如果返回 200，说明地址可访问，问题可能出在跳转层或抓取层。这里的 -L 会跟随跳转，去掉它可以看到第一跳的状态。
准备阶段：先确定检测范围和基准
在判断层级之前，先固定三件事：检测哪些链接、以什么为正确基准、用什么工具记录。范围可以按栏目、按模板或按全站划分；基准是“这个链接本来应该指向哪个有效页面”。没有基准，就无法区分“链接写错”和“目标页面被删”。
准备一个表格，至少记录：来源页面、链接地址、HTTP 状态、跳转次数、最终地址。这些字段能直接对应到不同层。例如状态 404 且无跳转，多半是内容层或服务器层；状态 200 但最终地址与预期不符，多半是跳转层配置问题。
实施阶段：用状态码和跳转链定位问题层
批量检测时，不要只看“是否 404”。把结果分成三类处理：
- 4xx：先确认目标页面是否真的不存在。若页面已迁移，改链接或加 301；若页面永久删除，用 410 比 404 更明确。注意，
robots.txt的抓取限制不等于可靠的索引移除，它只影响抓取，不直接等同于删除索引。 - 3xx：检查跳转链长度和终点。如果 A 跳 B、B 跳 C、C 返回 404，问题在跳转层，应把 A 直接指向有效终点，减少中间跳。
- 5xx：属于服务器层，先查服务日志和上游依赖，不要急着改页面链接。
如果状态码全部正常，但搜索结果里仍出现死链接，要进入抓取层核查：查看该 URL 是否被 robots.txt 拦截，查看站点地图是否包含它。站点地图不保证收录，它只是提交候选地址；HTTPS 也不保证安全无漏洞或排名。不同搜索引擎对抓取和索引的处理须分别核查，不能用一个平台的结果推断另一个平台。
验证阶段：确认修复发生在正确的层
修复后要回到同一层验证，而不是只看首页能否打开。若改的是内容层，重新抓取来源页面，确认 href 已更新；若改的是服务器层，重新请求原地址，确认状态码从 404 变为 200 或 301；若改的是跳转层，确认跳转次数减少且终点返回 200；若改的是抓取层，确认 robots.txt 不再拦截，并等待搜索引擎重新抓取后再观察。
验证时保留修复前后的状态码记录。判断结果的标准是：原问题地址不再返回 4xx 或 5xx，跳转链不超过合理层数，且来源页面中的链接指向有效目标。如果验证后仍失败，说明之前判断的层不对，应回到服务器层重新取状态码。
维护阶段：把分层判断变成固定检查项
死链接检测不是一次性任务。维护时可以固定一套检查项：新内容发布前检查内链目标是否存在；栏目调整后检查旧地址是否有 301；服务器变更后抽查关键 URL 的状态码；定期对比站点地图与可抓取页面。每次只改一个层，避免同时改链接和服务器配置导致无法判断哪一步生效。
下一步，选一个当前返回异常的 URL，用 curl -I 取第一跳状态码，再决定是改链接、改跳转还是查服务器日志。
