网站死链检测 - 识别配置互相冲突的排查顺序
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /4ab0f6c6cb8d.html
📄
网站死链检测 - 识别配置互相冲突的排查顺序
在网站死链检测中，识别配置互相冲突，关键是先把“谁在限制、谁在放行、谁在报告”三件事分开记录，再对比同一批URL在不同来源中的结果。最优先处理的是：让robots.txt、站点地图、页面内链接和重定向规则对同一个地址给出一致结论。只要有一处说“禁止抓取”，另一处说“可访问”，冲突就已经存在。
准备：先固定一份待检测URL样本
不要一上来就全站扫描。从栏目页、产品页、文章页、分页和已下线页面中各取若干条，组成一份小样本。每条记录至少包含：完整URL、期望状态（应返回200、应跳转、应返回404或410）、当前实际状态。
- 用浏览器开发者工具或命令行查看响应状态码，不要只看页面是否打得开。
- 把robots.txt中与样本路径相关的规则单独抄出来，标注是允许还是禁止。
- 把站点地图中出现的同一批URL抄出来，标注是否被收录在站点地图里。
- 记录页面内链、导航、面包屑中是否还指向旧地址。
这一步的产出是一张对照表。没有对照表，后面的“冲突”只能靠感觉判断。
实施：用四种来源交叉比对
识别冲突最有效的动作，是把同一URL放进四个来源里看结果是否一致：
- robots.txt：该路径是被允许抓取，还是被Disallow挡住。
- 站点地图：该URL是否被列入，列入的是否仍是可访问版本。
- HTTP响应：直接请求该URL，看返回200、301、302、404还是410。
- 页面链接：站内是否还有入口指向这个地址，入口是否经过跳转。
典型冲突包括：站点地图里列着一个已被robots.txt禁止抓取的地址；页面链接指向A，A又301到B，但站点地图只写了A；旧页面返回404，导航里却仍保留链接。发现这类情况时，先不要改规则，先把冲突点记下来，确认它影响的是抓取、索引还是用户体验。
如果同一现象有多个解释，例如“页面打不开”，可能是404、可能是服务器超时、也可能是被防火墙拦截。需要分别验证，不能直接断定是死链。
验证：判断冲突是否真的影响死链处理
不是所有不一致都要立刻修。判断优先级可以看三点：
- 该URL是否有外部链接或站内重要入口导入。
- 该URL是否仍在站点地图中，是否会被反复提交。
- 该URL返回的状态是否会让用户或抓取工具进入死胡同。
验证时，改完一处配置后重新请求同一URL，并再次核对robots.txt、站点地图和页面链接。只有四处结果一致，才算冲突解除。若只改了重定向，却忘了更新站点地图，冲突仍然存在。
需要特别区分：robots.txt的抓取限制不等于可靠的索引移除；站点地图不保证收录；HTTPS不保证安全无漏洞或排名。这些都不能拿来当作“已经修好”的证据。
维护：把冲突检查变成固定动作
时间和人手有限时，不必每天全站跑一遍。可以在每次改版、下线栏目、更换域名或调整重定向规则后，对样本URL做一次交叉比对。维护清单可以固定为：
- 新增或删除页面后，同步检查robots.txt和站点地图。
- 设置重定向后，确认旧地址不再出现在站内链接和站点地图中。
- 定期抽查返回404的URL，确认是否有重要入口仍在指向它。
- 把冲突记录和修复结果留在同一张表里，避免重复排查。
下一步，从你现有的死链检测结果中挑出同时出现在站点地图和robots.txt禁止规则里的URL，先处理这一批。它们最容易造成反复提交、反复失败，也是最值得优先解决的配置冲突。
