网站死链日志中应该核对哪些字段-短横线拆解排查起点
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /9c8c781ca5be.html
📄
网站死链日志中应该核对哪些字段-短横线拆解排查起点
网站死链排查时，日志里最该先核对的是请求状态码、请求URL、来源页面、User-Agent、请求时间和响应大小这几个字段。它们能帮你区分“链接本身失效”“服务器临时出错”和“爬虫或用户访问了不存在的地址”三类情况。没有这些字段，单看“死链数量”无法定位原因，也无法决定下一步是修链接、改跳转还是恢复页面。
先确认日志里有没有这六个字段
打开服务器访问日志或CDN日志，逐项检查表头。常见格式接近下面这样，字段顺序可能不同：
时间 客户端IP 请求方法 请求URL 状态码 响应大小 来源页 User-Agent
- 请求状态码：查什么——每条404、410、500、502记录的状态码。怎么查——直接筛选状态码列。结果说明什么——404和410通常表示地址不存在；500和502表示服务器端异常，不一定是死链，可能是程序或上游故障。
- 请求URL：查什么——被请求的完整路径和查询参数。怎么查——按URL分组统计出现次数。结果说明什么——同一个URL反复出现，说明有页面或外部来源持续指向它；带参数的URL要单独看，避免把动态参数误判为独立死链。
- 来源页面：查什么——Referer字段。怎么查——筛选状态码为404且Referer非空的记录。结果说明什么——能定位是站内哪个页面链到了失效地址，直接去那个页面改链接。
- User-Agent：查什么——请求方是浏览器还是搜索引擎爬虫。怎么查——看UA字符串中的爬虫标识。结果说明什么——爬虫频繁请求404，说明旧链接仍被索引或站点地图里还有该地址；普通用户请求404，说明站内导航或外链有问题。
- 请求时间：查什么——404出现的时段和频率。怎么查——按小时或按天聚合。结果说明什么——突然集中出现，可能是改版、删除页面或配置变更导致；长期零星出现，多为历史外链或旧索引残留。
- 响应大小：查什么——404响应返回的字节数。怎么查——对比正常页面和404页面的响应大小。结果说明什么——如果404返回了完整页面模板，说明错误页配置正常；如果返回0字节或极小值，说明服务器直接断开，用户体验和爬虫判断都会受影响。
用状态码区分“死链”和“服务器故障”
日志里出现非200不等于死链。判断依据如下：
- 404 Not Found：地址不存在。适用条件——页面已删除且不打算恢复。判断结果——需要决定是设置301跳转到相关页面，还是保留404并清理内链。
- 410 Gone：地址永久移除。适用条件——确认内容不再提供。判断结果——比404更明确，但不同搜索引擎处理方式需要分别核查，不能假设所有引擎行为一致。
- 500、502、503：服务器端错误。适用条件——同一URL在短时间内多次出现。判断结果——先查程序日志和上游服务，不要直接当死链删除或跳转。
- 301、302：跳转。适用条件——日志里出现大量301但目标页仍返回404。判断结果——说明跳转链末端失效，需要修正跳转目标。
如果日志里只有状态码没有URL，排查无法继续。此时应先调整日志格式，确保至少记录请求URL和状态码，再重新收集一段时间的数据。
把日志记录和站点地图、robots.txt交叉核对
日志能告诉你“谁在请求什么”，但不能单独告诉你“该不该收录”。交叉核对步骤：
- 从日志中导出所有返回404的URL列表。
- 检查这些URL是否出现在站点地图中。站点地图不保证收录，但里面如果包含404地址，说明站点地图需要更新。
- 检查robots.txt是否限制了这些路径。robots.txt的抓取限制不等于可靠的索引移除，被限制抓取的URL仍可能出现在搜索结果中，需要单独核查。
- 检查站内链接：用站内搜索或爬取工具，确认哪些正常页面还链向这些404地址。
- 对外链来源，记录Referer域名，判断是外部网站旧链接还是自己站内旧链接。
完成交叉核对后，你会得到一张表：每个404 URL对应“站内来源、外链来源、是否在站点地图、是否被robots限制”。这张表才是决定下一步行动的依据。
一个可执行的判断例子
假设日志中出现以下记录（仅为假设示例，非真实项目数据）：
2025-01-10 10:22 GET /old-page 404 512 https://example.com/blog Googlebot
逐项判断：请求URL是/old-page，状态码404，来源页是博客列表，UA是Googlebot。这说明博客列表里仍有指向旧页面的链接，且爬虫正在跟踪它。下一步应去博客列表模板或该篇文章中删除或替换这个链接；如果旧页面有对应新页面，设置301跳转到新地址。如果来源页为空且UA是普通浏览器，则更可能是外部旧链接或用户书签，需要评估是否值得恢复内容或设置跳转。
下一步行动
先导出最近7天状态码为404和410的日志记录，按请求URL分组计数，再按来源页面排序。从出现次数最多且来源页明确的URL开始处理：能恢复的恢复，能跳转的跳转，确认不再提供的保留404并清理站内链接。处理完一批后，隔几天再拉一次日志，对比同一URL是否还在出现，以此判断修复是否生效。
