网站死链检查日志中应该核对哪些字段
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /7b6bd7da2479.html
📄
网站死链检查日志中应该核对哪些字段
做网站死链检查时，日志里最该先核对的是请求状态码、请求URL、来源页URL、User-Agent、请求时间和请求方法这几个字段。它们能帮你区分“真正的死链”和“扫描器误报”，并决定先修哪一条。下面从一个假设例子讲起。
先看一个假设例子
假设你的网站日志里有这样一条记录：状态码404，请求URL是/old-page，来源页是https://example.com/blog/a，User-Agent是Googlebot，请求时间是某天上午。另一条记录同样是404，但来源页为空，User-Agent是某个批量扫描工具。这两条的处理优先级完全不同：前者可能是真实用户或搜索引擎从站内点进去后遇到的死链，后者很可能只是外部扫描产生的噪声。
所以，网站死链检查不是把所有404都当成要立刻修的问题，而是先靠字段把“谁在访问、从哪里来、访问了什么、结果如何”还原出来。
状态码要分清404、410、301和5xx
状态码是判断死链的第一依据，但不能只看一个数字。
404：资源不存在。若来源页是站内页面，通常说明站内链接指向了已删除或改名的地址。410：资源已永久移除。它和404都表示不可访问，但语义更明确，是否使用取决于你的服务器配置和内容策略。301或302：不是死链，但要看跳转目标是否也返回404。跳转链过长或最终落到错误页，同样会造成用户和爬虫访问失败。5xx：服务器错误，不是死链本身，但会让检查结果失真。先排除服务器故障，再判断链接问题。
常见错误是只导出404，把301和5xx全部忽略。实际排查时，应把“最终状态码”和“跳转次数”一起看。
URL、来源页和User-Agent决定优先级
请求URL告诉你坏在哪里，来源页告诉你用户或爬虫是从哪里走到这个坏地址的。来源页为空时，可能是直接访问、外部引用未记录，或扫描器请求，不能直接判定为站内死链。
User-Agent用于区分访问者类型。Googlebot、Bingbot等搜索引擎爬虫的请求，和普通浏览器、监控工具、批量扫描器的请求，处理顺序不同。若日志中大量404来自同一个User-Agent且来源页为空，优先怀疑扫描或旧监控规则，而不是站内链接大面积失效。
判断时可执行这一步：
- 先按状态码筛出404和410。
- 再按来源页是否属于你的站点域名分组。
- 然后按User-Agent查看是否集中在搜索引擎爬虫或真实浏览器。
- 最后按请求URL出现次数排序，先处理高频且来自站内来源页的地址。
这样做的结果是：站内真实死链排在最前，扫描器噪声排到后面。适用条件是日志字段完整；如果来源页字段缺失，就需要结合站内链接抓取工具交叉验证。
时间和请求方法用于排除偶发与误判
请求时间能看出问题是持续存在还是集中在某个时段。若某URL只在几分钟内出现大量404，可能是改版、发布或缓存刷新期间的临时现象；若连续多天都有来自站内来源页的404，则更可能是稳定死链。
请求方法主要看GET和HEAD。普通用户点击链接通常是GET；部分检查工具会用HEAD。若日志里只有HEAD返回404，而GET正常，问题可能出在检查方式或服务器对HEAD的处理，不一定是页面真的不可访问。
常见错误是把HEAD的404直接当成页面死链，或者把短时间内的404高峰当成永久问题。核对时间分布和方法后，再决定是否修改链接或配置跳转。
核对字段后的处理顺序
时间和人手有限时，可以按这个顺序安排：
- 先修来源页是站内页面、状态码为404或410、且出现次数较高的URL。
- 再检查301跳转链，确认最终目标不是404或5xx。
- 然后处理来源页为空但User-Agent为常见搜索引擎爬虫的URL，核实是否应保留或跳转。
- 最后把来源页为空、User-Agent为扫描工具的记录降级，避免占用修改时间。
需要提醒的是，robots.txt的抓取限制不等于可靠的索引移除；站点地图不保证收录；HTTPS也不保证安全无漏洞或排名。日志核对解决的是“哪些链接真的坏了、先修哪些”，不是收录或排名保证。
下一步，你可以从日志中导出最近7天的404和410记录，按来源页是否为站内域名分成两组，先处理第一组里出现次数最多的20条URL。
