📍 WDQWDWQD987AAAAA:216.73.217.100
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /a710f56717da.html
📄

死链优化：日志中应该核对哪些字段 - 交付前先看这四类记录

死链优化时核对日志，核心是看四类字段：请求时间、请求URL、HTTP状态码、来源页或引荐URL。只盯着状态码会漏掉大量问题，因为同一条404可能来自站内旧链接、站外引用、爬虫误抓或用户直接输入，处理方式完全不同。多人协作时，把这四类字段连同User-Agent一起导出，才能把“发现死链”和“决定怎么修”分开交付，减少返工。

常见误解：看到404就等于要立刻改链接

很多人拿到日志后，把状态码为404的URL全部列成清单，直接交给编辑去改。这会导致两类错误：一是把本来就不该存在的URL（比如被攻击产生的随机路径）当成需要修复的死链；二是把301、410、302等状态混在一起处理，结果改错了方向。

日志里的状态码是结果，不是原因。同一个404可能对应完全不同的处理动作，因此必须结合其他字段判断。适用条件是：你手里有服务器访问日志或CDN日志，并且能按URL聚合。如果只有前端监控的错误列表，缺少来源字段，就只能先补日志，不能直接下结论。

必须核对的字段清单

• 请求时间：区分是历史遗留还是近期新增。按天聚合后，突然出现的404更可能是新改版或外链变动导致。
• 请求URL：包含路径和查询参数。注意带参数的URL是否被误当成独立死链，很多参数只是追踪用途。
• HTTP状态码：404、410、301、302、403、500要分开统计。301是跳转，不是死链；500是服务端错误，不是链接失效。
• 来源页或引荐URL：判断用户是从站内哪个页面点过来的，还是从外部搜索、社交平台进入。站内来源可以直接定位到需要修改的模板或正文。
• User-Agent：区分搜索引擎爬虫、普通浏览器和监控工具。爬虫频繁抓取的404，和真实用户点击的404，优先级不同。
• 请求方法：GET和HEAD要分开看。有些监控只发HEAD请求，状态码正常不代表页面内容正常。

按来源字段决定处理顺序

拿到字段后，不要按URL数量排序，而应按“是否有真实用户点击”排序。判断方法如下：

1. 先筛出状态码为404或410、且来源页属于本站的请求。这类是站内死链，直接影响用户浏览，优先修。
2. 再筛出来源页为外部、且请求量持续存在的URL。这类可能是外链失效，考虑做301到最相关的新页面，而不是直接删除。
3. 最后处理只有爬虫访问、没有来源页的404。这类可能只是爬虫抓到了历史遗留地址，确认无价值后可以保留404或返回410。

假设某条日志显示：状态码404，来源页是站内文章A，User-Agent是普通浏览器，请求时间集中在近三天。这说明文章A里有一个链接指向了已删除页面，应该去文章A的正文里找到这个链接并替换。如果来源页为空，User-Agent是爬虫，请求时间分散在半年内，那更可能是旧URL被外部引用，处理方式应改为评估是否做301，而不是去改某篇文章。

多人协作时的交付格式

为了减少返工，日志核对结果不要只丢一张URL列表。建议按以下字段输出表格，每行一个待处理项：

• 请求URL
• 状态码
• 来源类型（站内/站外/无来源）
• 来源页URL（如有）
• 最近请求时间
• 建议动作（改链接/加301/保留404/返回410）
• 负责人

这样编辑只需要看“来源页URL”和“建议动作”两列，技术人员只需要确认状态码和跳转配置，职责边界清楚。注意：robots.txt的抓取限制不等于可靠的索引移除，站点地图也不保证收录，所以日志里看到的404是否会被搜索引擎保留，需要分别到不同搜索引擎的站长工具中核查，不能只凭日志下结论。

下一步：从最近七天的日志中导出状态码为404和410的记录，按来源页是否为空分成两组，先处理有站内来源的那一组，并把处理结果填进上面的交付表格。