如何检查网站死链：日志中应该核对哪些字段
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /28ae55e07ee3.html
📄
如何检查网站死链：日志中应该核对哪些字段
在服务器访问日志里查死链，核心是核对四个字段：请求时间、请求方法、请求URL、状态码。其中状态码决定“是不是死链”，请求URL决定“哪条链接坏了”，请求方法帮你排除非页面请求的干扰，请求时间则用来判断问题出现多久、是否仍在持续。只盯着状态码而不看URL和方法，很容易把图片缺失、接口报错误当成页面死链。
先看状态码字段，区分真死链和假死链
日志中的状态码字段通常写作 status 或 status_code，是判断死链的第一依据。
- 404：资源不存在，最常见，指向已删除页面或写错的链接。
- 410：资源被明确永久移除，和404一样属于应当处理的死链信号。
- 301 / 302：不是死链，是跳转。需要继续核对跳转目标是否有效，跳转链过长或指向404才算问题。
- 500 / 502 / 503：服务器或网关错误，属于临时或后端故障，不要当死链直接删链接，应先排查服务。
- 403 / 401：权限问题，可能被误判为死链，实际资源存在。
判断结果：只有404和410可以较有把握地归入死链；其余状态码要先排除跳转、权限、服务故障，再决定是否处理。
再看请求URL和请求方法，定位坏在哪条链接
URL字段（常见写法 request_uri、path、url）告诉你具体是哪条地址返回了404。核对时注意三点：
- 区分大小写和末尾斜杠，
/Page与/page、/about与/about/可能是不同资源。 - 去掉查询参数再统计，
/a?id=1和/a?id=2指向同一页面，避免重复计数。 - 把URL归类到来源目录，看是集中在某栏目、某批旧文章，还是零散分布。
请求方法字段（method）用于过滤：只保留 GET 请求，排除 POST、HEAD、OPTIONS 等非页面访问，否则会把表单提交、接口探测、健康检查的404也算进来。
假设一个例子：日志显示 GET /old-guide 404 出现多次，POST /api/query 404 只出现一次。前者是需要处理的页面死链，后者很可能是接口调用，不该混进死链清单。
结合时间字段和来源字段，判断优先级
时间字段（time、timestamp）用来回答两个问题：这条死链是历史遗留还是最近新增，以及它现在还在不在被访问。如果某URL在近七天日志里仍有稳定请求，说明站内或站外还有链接指向它，处理优先级更高。
来源字段（referer）能帮你找到链接从哪来：
- 来源是本站页面，说明站内某处链接写错了，改链接即可。
- 来源是外部站点，说明外链指向了失效地址，可考虑做301跳转到新页面。
- 来源为空，可能是用户直接输入、爬虫抓取或工具探测。
人手有限时，优先处理“近期仍被访问 + 站内来源 + 404”的组合，这类死链既影响体验又容易修复。
复查：改完之后怎么确认死链真的消失
处理动作完成后，不要只看一次日志就收工，按下面步骤复查：
- 对已改链接的页面重新抓取一次，确认返回200。
- 对做了301的旧地址，用工具请求原URL，确认状态码为301且目标页返回200，而不是跳到另一个404。
- 间隔几天再拉一次日志，统计同一批URL是否还出现404。仍出现，说明还有别的入口没改完。
- 把已确认修复的URL从清单移除，保留仍未解决的，避免清单越滚越大。
如果站点使用robots.txt限制抓取，要清楚它只影响爬虫是否访问，不能替代对死链本身的修复；站点地图提交也不保证收录。这两项都不能当作死链已解决的证据，判断依据仍然是日志里的状态码和实际请求结果。
下一步：从最近一段日志中导出状态码为404和410的记录，按URL去重后统计出现次数，把出现频率最高的前若干条先列入待处理清单，再逐条核对来源字段决定是改链接还是做跳转。
