KEEL · 龙骨 · A CURRICULUM FOR THE AI ERA

10 · 度量与归因：三方数据对账与因果判断 — keel 龙骨

本章目标：建立一套能把"搜索引擎报表、服务器日志、站点分析"三方数据对齐的度量体系，并据此做因果判断。验收标准：能对一次排名波动，在算法更新/抓取故障/上线事故之间做出有证据的判断。

本章目标：建立一套能把"搜索引擎报表、服务器日志、站点分析"三方数据对齐的度量体系，并据此做因果判断。
验收标准：能对一次排名波动，在算法更新/抓取故障/上线事故之间做出有证据的判断。

为什么要对账：三个数据源各说各话——GSC 说"曝光降了"，日志说"抓取正常"，分析工具说"流量降了"。不把它们对齐，你永远在猜。归因能力是 SEO 从"手艺"变成"工程"的最后一块拼图。

一、三方数据源的分工与口径

数据源	看什么	口径	盲区
GSC / 平台报表	曝光、点击、平均排名、覆盖率	仅该引擎、已脱敏	不含其他引擎、数据延迟
服务器日志	抓取量、状态码、路径	全部爬虫、原始	不含用户行为
站点分析（RUM/分析工具）	访问、停留、转化	真实用户（含 JS 依赖）	被广告拦截/无 JS 影响

核心认知：没有哪个源能单独给出真相。GSC 的"点击"是它自己的口径，日志能看到它抓了什么但看不到它展示了什么，分析工具能看到用户但看不到爬虫。

二、三方对账的实用方法

对齐的关键是找到一个共同维度——通常是日期 + URL 路径。

-- 日志侧：某路径每日 Googlebot 抓取量（事实表见第 02 章）
SELECT substr(ts,1,10) d, count(*) n
FROM crawl WHERE bot='googlebot' AND uri LIKE '/learning/%'
GROUP BY d ORDER BY d DESC LIMIT 14;

对账表（人工/脚本汇总）：

日期	GSC 曝光	GSC 点击	日志抓取量	分析工具访问	判读
D-7	10000	300	850	240	基线
D-6	9800	290	840	235	正常波动
D-5	9700	288	860	230	正常
D-4	4000	90	200	80	异常，三源同时降
D-3	4100	95	210	85	未恢复

判读规则：

三源同向下降 → 大概率是站点级事件（上线事故、抓取故障）。
GSC 降但日志抓取正常 → 排名/展示层问题（算法、竞争）。
分析工具降但 GSC 与日志正常 → 用户侧问题（性能、前端报错）。

三、排名波动的三类归因

这是本章的核心能力：把"排名掉了"拆成三种假设，并各自找证据。

假设	特征	证据来源	验证方法
算法更新	全站/多页同时、无技术改动	官方更新记录、行业波动	比对日期与更新公告
抓取故障	抓取量骤降、5xx 上升	日志事实表	抓取 vs 5xx 序列（第 02 章）
上线事故	紧接发版、单页或新版	发版记录、canonical/robots diff	回看发版前后 diff

判定流程：

排名/流量下降
   │
   ├─ 有发版记录在下降前 24h 内？ ── 是 → 查上线事故（diff 配置与模板）
   │
   ├─ 抓取量同期骤降 / 5xx 上升？ ── 是 → 抓取故障
   │
   ├─ 站点级同时下降、无技术改动？ ── 是 → 疑似算法更新
   │
   └─ 单页下降、其余正常？ ── → 内容竞争（去比对该词头部结果）

# 关联检查：发版时间点前后的关键配置是否变化
# 记录每次发版的 canonical/robots/sitemap 快照，事后可 diff
curl -s https://www.xxxxxx.cn/learning/ | grep -oE '<link rel="canonical"[^>]*>' > /tmp/canonical.now
curl -s https://www.xxxxxx.cn/robots.txt > /tmp/robots.now

工程化建议：每次发版时自动快照 canonical、robots、sitemap、关键模板 HTML。事故发生时，一次 diff 就能定位。

四、实验设计与 A/B 的可行边界

SEO 的实验比产品实验更难，因为你无法对同一个 URL 同时给不同用户不同排名。可行的与不可行的要分清。

方案	可行性	说明
同页面对用户 A/B	❌ 不可行	排名不由你控制
两组相似页面（URL A/B）	⚠️ 有条件	页面需高度相似，且分流量
时间前后对比（Before/After）	✅ 常用	需排除同期算法波动
分区域对比	⚠️ 有条件	需区域足够独立
灰度发布	✅ 可行	技术上可回滚，SEO 效果滞后

判据：

同内容双 URL 做 A/B 会制造重复内容，得不偿失。
前后对比必须排除算法更新——否则你无法区分"你的改动"与"算法波动"。
实验周期要足够长（SEO 反馈以周计），短于 2 周的结论不可信。

最小可行的实验法：对新增内容用两种写法，观察其在数周后的收录与排名差异。这是唯一相对干净的对比。

五、建立归因看板

看板字段	来源	频率
曝光/点击/平均排名	GSC	周
抓取量/状态码	日志事实表	日
收录数	site: 抽样 + GSC 覆盖率	周
核心词排名	人工/工具	周
CWV 分层	RUM/CrUX	周
发版快照 diff	CI	每次发版

六、故障速查

现象	归因	处理
三源同降	站点级事件	查最近发版与抓取
GSC 降、日志正常	排序层	查算法更新与竞争
分析降、其余正常	用户侧	查性能与前端错误
单页突降	内容竞争	比对头部结果
抓取骤降	抓取故障	查 5xx 与 robots

七、本章验收

三方数据能按"日期 + 路径"对齐成一张对账表
能对一次波动在三类归因间做有证据的判断
每次发版自动快照 canonical/robots/sitemap，可事后 diff
明确哪些实验可行、哪些会制造重复内容
有归因看板与固定节奏

# 本章核心：发版快照（接进 CI 后每次自动执行）
curl -s https://www.xxxxxx.cn/learning/ | grep -oE '<link rel="canonical"[^>]*>'
curl -s https://www.xxxxxx.cn/robots.txt

归因能力就绪后，最后要面对的是一个全新的、规则尚未稳定的变量——AI 搜索。

进入 keel 阅读