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

a5诊断，怎样记录改动前后的基线

做a5诊断时，记录改动前后的基线，核心是让同一套指标在改动前后用相同口径各测一次，并把原始数据、采集时间和环境条件一起留存。没有基线，改动后的变化就无法归因；基线不完整，诊断结论只能停留在猜测。最关键的一步是先固定测量口径，再动手改动。

准备阶段：先定义基线的范围与口径

基线不是随手截一张图，而是一份可复核的快照。准备时要明确三件事：测什么、怎么测、在什么条件下测。

• 测什么：根据a5诊断要回答的问题选定指标。若关注页面能否被抓取，记录抓取状态、返回码、robots限制、可索引状态；若关注收录与展现，记录索引数量、展现量、点击量、平均排名区间；若关注站内行为，记录入口页、停留、跳出、转化路径。
• 怎么测：优先使用能导出原始记录的渠道，例如站内统计后台、搜索平台提供的效果报告、服务器访问日志。第三方估算流量与站内统计、搜索平台报告口径不同，不能混在一张表里直接比较。
• 在什么条件下测：记录设备类型、地域、登录状态、采样时间窗。同一指标在不同时间窗波动明显时，应取一个完整周期而不是某一天的峰值。

把上述内容写进一张基线表，字段至少包括：指标名称、数据来源、采集时间、时间范围、筛选条件、数值、原始文件存放位置。这张表就是后续所有对比的锚点。

实施阶段：改动前先存证，改动时留痕

改动前必须完成基线采集，而不是改完再补。补采的基线已经受改动影响，无法代表改动前状态。

1. 导出改动前的原始数据文件，按“日期_指标_来源”命名，例如20250110_index_searchconsole.csv。文件不要只留截图，截图无法二次核算。
2. 记录改动内容本身：改了哪个页面、哪段代码、哪条规则、哪项配置，改动前后的具体值。若涉及模板或全站设置，写明影响范围。
3. 记录改动时间点，精确到小时。跨天改动会让当天数据处于混合状态，对比时应把改动当天单独标注。
4. 若同时改了多项，尽量分批发布并分别记录时间，否则无法判断是哪一项起了作用。

假设某页面标题与正文同时调整，且在同一天完成，那么当天及之后的数据都无法区分两项改动各自的贡献。这种情况下，基线只能支持“整体是否变化”的判断，不能支持单项归因。

验证阶段：用同口径对比，区分现象与原因

改动后按与基线相同的时间窗长度、相同的筛选条件重新采集一次，然后逐项对比。对比时注意三点：

• 看趋势不看单点。单日数值受抓取节奏、节假日、发布频率影响，至少观察一个完整周期再下结论。
• 区分“可能原因”与“已经定位的原因”。例如索引量下降，可能是抓取减少、可能是页面被设为不可索引、也可能是平台报告延迟；只有逐项排查并找到对应证据，才能说已经定位。
• 保留反例。若某项指标没变，也要记录，这能排除一部分假设。

判断结果时，可以按下面这张检查表逐项打勾：改动时间是否已记录；改动前后数据是否来自同一来源；时间窗长度是否一致；筛选条件是否一致；异常值是否有解释；结论是否有原始数据支撑。任何一项缺失，结论的可靠度都要下调。

维护阶段：让基线可追溯、可复用

基线记录的价值在于长期可比。建议固定存放位置，按时间顺序归档，每次改动都新增一版而不是覆盖旧版。若数据来源或统计口径发生变化，例如平台调整了报告定义，应在基线表中标注口径变更日期，并把变更前后的数据分段对比，不要跨口径直接连线。

日常维护只需做两件事：一是每次改动前复制上一版基线表作为新基线；二是定期核对原始文件是否仍可访问。文件丢失或权限变更会让历史基线失效，届时只能重新建立起点。

下一步，先为当前要诊断的对象建立第一版基线表，完成一次改动前采集，再开始实际改动。