死链接日志中应该核对哪些字段：先看状态码、来源页与目标地址
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /c03854f396c9.html
📄
死链接日志中应该核对哪些字段：先看状态码、来源页与目标地址
排查死链接时，日志里最该优先核对的是响应状态码、请求URL（原目标地址）和来源页URL（Referer）这三类字段。它们能直接回答“哪个链接坏了、坏成什么样、用户或爬虫从哪里点进来”。时间和人手有限时，先按状态码筛出4xx与5xx，再按来源页聚合，就能把修复顺序排出来，而不必逐条翻完整日志。
准备阶段：确认日志里有哪些可用字段
不同服务器和CDN记录的字段名不完全一样，但语义相近。打开一份日志样本，先确认是否存在这些信息：
status或sc-status：HTTP响应状态码，判断是否死链接的核心。request或cs-uri-stem：被请求的路径，即可能失效的目标地址。referer：来源页，能定位是哪个页面挂了这个坏链接。user-agent：区分搜索引擎爬虫与真实用户，决定处理优先级。time：请求时间，用于判断问题是长期存在还是刚刚出现。method：请求方法，GET与HEAD的处理含义不同。
如果日志只有状态码没有来源页，仍可定位坏目标，但难以找到需要修改的页面。这种情况下要先把日志字段补全，再谈批量修复。
实施阶段：按字段优先级筛选与归类
最关键的一步是先按状态码分组，再按来源页聚合。顺序如下：
- 筛出状态码为404、410的记录，这是明确的死链接。
- 把301、302单独放一边，它们不是死链接，但可能指向失效目标，需要继续跟踪跳转终点。
- 把5xx单独归类，这类多为服务端临时或持续故障，处理方式与404不同。
- 按来源页URL分组，统计每个页面挂了多少个坏目标。
- 按目标URL分组，统计同一个坏地址被多少页面引用。
判断优先级时，来源页被引用越多、目标被引用越多，越应先修。若日志中user-agent显示为搜索引擎爬虫且状态码为404，说明该坏链接已被抓取到，通常比仅用户点击的更值得优先处理。
需要区分“可能原因”和“已经定位的原因”。例如某个URL返回404，可能是页面被删除、路径拼写错误、大小写不一致，也可能是重定向链中断。仅凭状态码不能断定是哪一种，必须结合来源页和目标地址逐条核对。
验证阶段：确认修复是否真正生效
修改后不要只看日志里旧记录消失，而要用可复现的方式检查：
- 直接请求原目标地址，确认返回200或预期的301。
- 从来源页点击该链接，确认跳转终点正确。
- 检查重定向链是否过长或形成循环。
- 确认新目标没有被robots.txt误挡，但要注意：robots.txt的抓取限制不等于可靠的索引移除。
若修复方式是删除链接，验证重点是来源页不再输出该地址；若方式是改指向，验证重点是终点页面可访问且内容相关。站点地图不保证收录，因此不能把“已提交站点地图”当作修复完成的证据。
维护阶段：把核对字段固化成例行检查
时间和人手有限时，不必每天全量分析。可以按周或按月抽取日志，固定核对状态码、目标地址、来源页三项，并记录新增的4xx目标。对反复出现的坏目标建立清单，优先处理来源页集中、爬虫访问频繁的条目。
如果站点使用HTTPS，也不要因为协议安全就跳过链接检查，HTTPS不保证安全无漏洞或排名。维护动作应聚焦在链接本身是否可达、来源页是否仍引用它。
下一步：从最近一份日志中导出状态码、请求URL、来源页三列，先筛出404记录并按来源页计数，排出本周要修的前十个坏链接。
