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

网站日志，如何制定阶段性交付物：一份可执行的证据清单

把网站日志工作拆成阶段性交付物，核心是让每个阶段都产出可核对的证据文件：先确认日志是否可用，再确认抓取行为，再定位异常，最后形成结论与整改项。交付物不是报告本身，而是能支撑结论的原始数据、筛选结果和判断依据。下面按顺序给出每项要查什么、怎么查、结果说明什么。

阶段一：日志可用性交付物

这一阶段的交付物是一份日志样本与字段说明，用来判断后续分析是否成立。

• 要查什么：日志文件是否包含时间、请求方法、URL、状态码、User-Agent、IP、响应大小等基础字段。
• 怎么查：取最近一段时间的日志，用文本编辑器或命令行查看前若干行，确认字段分隔方式是否一致，时区标注是否明确。
• 结果说明什么：如果字段缺失或格式混乱，后续的抓取分析无法可靠进行，需要先补全日志配置或改用其他数据源。如果字段完整，可进入下一阶段。

判断条件：日志时间与服务器时区不一致时，所有按小时或按天的统计都会偏移，必须先记录时区偏移量再继续。

阶段二：抓取行为交付物

这一阶段的交付物是一份按爬虫来源分类的请求统计，区分搜索引擎抓取、普通用户访问和其他自动请求。

• 要查什么：不同 User-Agent 的请求数量、访问的 URL 分布、状态码分布。
• 怎么查：按 User-Agent 字段分组统计，重点看已知搜索引擎爬虫标识的请求量，同时观察这些请求集中在哪些目录或参数上。
• 结果说明什么：如果爬虫请求集中在少数页面，说明抓取预算可能被低价值 URL 消耗；如果大量请求返回 4xx 或 5xx，说明存在死链或服务端问题，需要先修复再谈收录。

注意区分：抓取、索引、排名是不同环节。日志只能反映抓取行为，不能直接证明页面已被索引或获得排名。要判断索引情况，需要结合其他数据源核对。

阶段三：异常定位交付物

这一阶段的交付物是一份异常请求清单，每项包含现象、可能原因和已定位的原因。

• 要查什么：状态码异常、请求量突增或突降、重复抓取同一 URL、抓取不存在路径。
• 怎么查：按时间维度对比请求量曲线，标记突变点；对异常状态码的 URL 抽样访问，确认当前返回结果。
• 结果说明什么：同一现象可能有多个解释。例如请求量下降，可能是爬虫调整、服务器屏蔽、robots 规则变化，也可能是网站本身下线。只有结合服务器配置、robots 文件和实际访问测试，才能把“可能原因”收敛为“已定位的原因”。

短例子（假设）：某目录请求量三天内归零。可能原因是该目录被 robots 禁止抓取，也可能是服务器对该爬虫返回 403。检查 robots 文件与服务器访问控制规则后，才能确定是哪一种。

阶段四：结论与整改交付物

这一阶段的交付物是一份整改清单，每项写明问题、证据来源、建议动作和验证方式。

• 要查什么：前面阶段确认的问题是否都有对应的日志证据。
• 怎么查：把每个结论回溯到具体的日志行或统计结果，确保没有无依据的判断。
• 结果说明什么：有证据支撑的问题才进入整改清单；证据不足的列为待观察项，下一阶段继续收集。

验证方式要可执行：修改后重新采集同口径日志，对比同一指标是否变化。不要用“应该会改善”作为验证结论。

交付物之间的依赖关系

四个阶段是递进的：日志不可用则抓取统计无意义，抓取统计不清则异常定位容易误判，异常未定位则整改清单只是猜测。每个阶段结束时，用一句话写明本阶段结论和下一阶段的前提是否满足。如果前提不满足，先补数据，不要跳到结论。

下一步：从最近一段完整日志中导出字段列表和 User-Agent 分组统计，先完成阶段一和阶段二的交付物，再决定是否需要进入异常定位。