大多数团队其实已经有了一份 Google 排名报告。那就是 Search Console 的"效果"标签页，按点击排序，截图粘进幻灯片。它显示了排名。它没有显示什么变了、为什么变、以及谁该做什么。
这套流程一次坐下就能解决这个问题。你定义一组查询，把一份写好的报告契约交给 Codex，然后让它每周产出形状完全相同的报告。首次搭建大约 90 分钟，之后每次运行不到十分钟。
整套流程：原始导出进去，固定形状的报告出来，最后人工做一次判断。
做完之后你会得到什么
适合谁： 负责站点报告、并且已经有 Search Console 权限的人。你不需要是开发者，但需要有一个 Codex 能读取的文件存放位置。
做完时你手上有什么： 一份保存好的报告模板、一份 Codex 每次都会遵循的书面指令文件，以及一份来自真实某一周的完整报告。
前置条件： 一个已验证的 Search Console 资源、一份你真正在意的 20 到 50 个查询清单、一个能访问项目文件夹的 Codex；如果想做进阶版，还需要对自家站点仓库的读取权限。
完成的定义： 你能把报告交给一个不做 SEO 的人，而他能说出该看哪三个查询以及为什么。
耗时： 首次搭建约 90 分钟，之后每次运行不到 10 分钟。
为什么"效果"报告不是排名报告
Search Console 给你四列：点击次数、展示次数、点击率、平均排名。那是一张测量表。而排名报告必须回答的是另一组问题，2026 年的信号让这个差距比过去更大。
Zyppy 于 2026 年 9 月 9 日发布的专家调研，从 131 位从业者那里收集了 13,665 个数据点。点击与行为信号为 29.4%，品牌信号为 27.0%，技术 SEO 健康度为 17.5%。在这三个排名高于技术健康度的信号里，有两个在排名列里是看不见的。这些数字会带来什么改变，我们在实操指南里有单独拆解；但就报告而言，简短版本是这样的：如果你的报告只展示排名，那你报告的正是变动最小的那个信号。
这就是 Codex 补上的缺口。它不会告诉你 Google 为什么改了东西。它会把变化的证据组装得足够一致，让你能自己说出来。
开始之前：四个决定
在动笔之前先把这些定下来，因为之后改动意味着重做报告。
- 查询集合。 20 到 50 个查询，分成两到三个符合业务思考方式的桶。"产品""对比""支持"比"高流量 / 中流量 / 低流量"更好用。
- 对比窗口。 用最近 28 天对比此前 28 天。窗口更短噪声大，更长则会掩盖你要找的变化。
- 阈值。 决定什么才算值得报告。查询移动超过五个位次，或者点击持平而展示次数变动超过 30%，都是可用的默认值。
- 存放位置。 一个文件夹，一条命名规则。
reports/ranking/YYYY-MM-DD.md，再加一个放原始导出的data/子文件夹。Codex 需要一个稳定的写入位置。
第 1 步：导出原始数据
打开 Search Console，选中你的资源，进入"效果"页面。把日期范围设为 56 天，这样一次导出就能做 28 天对 28 天的比较；然后用"导出"按钮下载"查询"标签页的 CSV。
"网页"也照做一遍；如果你打算报告移动端与桌面端的拆分，"设备"也做一遍。
预期产出： data/ 里三个 CSV 文件，文件名带上导出日期。
质量检查： 打开查询 CSV，确认第一行数据不是一个包含 "anonymous" 一词的查询。Search Console 会隐去冷门查询，否则这些行会在报告里显示为无名的变动。
如果失败： 如果导出被截断，说明你的日期范围相对行数上限太宽了。分次导出 28 天窗口，让 Codex 把它们拼接起来。
第 2 步：写下报告契约
这一步决定了这套流程能否活过第三周。把契约放进一个 Codex 每次运行都会读取的文件里——项目根目录的 AGENTS.md，或者报告文件夹里一份专门的指令文件。
契约只需要五样东西，别的都不要：
契约区块 | 写什么 | 为什么重要 |
|---|---|---|
输入 | 确切的文件路径和日期范围规则 | 阻止智能体自己发明窗口 |
阈值 | 你的分档，用数字写 | 把一张表变成一次决策 |
输出形状 | 三个小节，按顺序 | 让第 30 周和第 1 周可比 |
置信规则 | 数据解释不了变化时该怎么写 | 防止自信的胡话 |
边界 | 智能体绝对不能做的事 | 在信任它之前保持只读 |
一个能用的版本长这样：
## 排名报告契约
输入: data/queries-*.csv, data/pages-*.csv
窗口: 最近 28 天对比此前 28 天。两个日期都要写在报告头部。
只报告三件事:
1. 变动的查询: 移动超过 5 个位次的，或点击持平而展示次数
上涨超过 30% 的，或任何跌出前十的查询。
2. 可能的原因: 只用文件里的数据。如果文件解释不了这次变动，
就写"本数据无法解释"。
3. 下周检查: 每个被标记的查询一行，指名要检查的确切页面或
查询。
绝对不要陈述你在数据里指不出来的原因。绝对不要建议站点改动。
绝对不要编辑 reports/ranking/ 之外的任何文件。预期产出： 一个指令文件，提交到版本库，或保存在数据旁边。
质量检查： 把契约朗读一遍。如果任何一行在不做修改的情况下也能适用于另一个站点，那它就模糊到约束不了任何东西。
如果失败： 如果 Codex 总在加小节，说明输出形状不够具体。把三个标题按你想要的措辞原样写出来。
报告的结构。列出所用确切文件的页脚是复核者最信任的部分，也是大多数模板会漏掉的部分。
第 3 步：生成第一份报告
把 Codex 指向那个文件夹，让它按契约产出一份报告。要文件，不要聊天里的回答，这样产出才可复核、可对比差异。
第一次运行正是你发现自己的数据实际长什么样的地方。预计会有两三轮修正。这很正常，也是整套流程里最便宜的部分。
预期产出： reports/ranking/YYYY-MM-DD.md，带一个头部、三个小节，以及一个列出所用确切文件的页脚。
质量检查： 挑两个被标记的查询，在 Search Console 里手工核对数字。如果对得上，管道就是可靠的。如果对不上，停下来先修数据步骤。不要在坏掉的输入上去排查分析。
如果失败： 最常见的失败是导出与契约之间的日期不一致。每次运行都把两个日期钉在头部，这样两天的偏移就不会悄悄把一个持平的月份变成一场崩塌。
我搭的第一版，在一个其实没怎么动过的星期里报告了十一个变动查询。契约没问题，是导出有问题。一个 30 天的文件拿去和 28 天窗口比，两天缺失的数据看起来就像全站崩塌。现在契约在两个范围不一致时会拒绝运行，那个故障再没出现过。
第 4 步：加上智能体写不了的那一行
每份报告都要有一段人写的文字：我们上周上线了什么、改了什么、弄坏了什么。
这不是装饰。这是抓住"把你自己发的版本归咎于算法更新"的智能体最快的办法。当报告说一批产品页掉了，而你的备注说模板在周二改过，解释范围立刻就收窄了。
预期产出： 报告顶部由人写下的两到三句话。
质量检查： 如果备注和变动小节互相矛盾，那个矛盾就是整份报告里最有价值的一行。让它留在那里，别抹平。
第 5 步：发送之前先验证
在报告离开你的桌子之前，跑完这三项检查。
- 日期。 两个窗口都写在头部，并且与导出相符。
- 两次抽查。 两个被标记的查询已人工核对。
- 一次矛盾检查。 有没有哪个声称的解释引用了底部文件清单里没有的数据？
三项全过，报告就可以放心分享。它是你判断的草稿，不是判断的替代品。
准备好了再走进阶路线
先手工跑四周。等你把同一类错误改了两次之后，再考虑自动化。
之后的升级是渐进的：
- 把运行排进日程。 每周定时运行会在你打开笔记本之前把报告写好。把人工段落设为必填项，这样报告不带上它就发不出去。
- 把快照存进版本控制。 每次运行都是一个提交。两周之间的差异比任何一份报告都读得更快。
- 加上第二个资源。 竞品或品牌查询放在一份用同一契约的独立报告里，不要合并进主报告。
- 加一个外部信号。 品牌搜索或回答占有率的检查，能让 2026 年调研里的品牌信号从理论变成可测量。
不要自动化的东西：建议这一步。智能体一旦开始提议站点改动，你就已经从报告跨到了发布，而复核负担的增长速度会快过省下的时间。
故障排查
症状 | 可能原因 | 处理 |
|---|---|---|
每个查询看起来都在跌 | 两次导出之间的日期范围偏移 | 把两个窗口同时钉在契约和头部里 |
报告是空的 | 相对于你的流量水平阈值太严 | 先调低展示次数阈值，再考虑调低位次阈值 |
每周都是同样那五个查询 | 查询集合太窄 | 往桶里加入长尾词和对比类查询 |
有变动但没有解释 | 对低流量查询来说很正常 | 保留"本数据无法解释"这个输出，继续往下走 |
数字与 Search Console 不一致 | 导出时的资源或过滤器不匹配 | 每次都从同一个资源、同一组过滤器导出 |
维护这套流程
三个维护习惯能让它在第一个季度之后继续有用。
每季度审查查询集合。 一份还在追踪去年优先级的报告是历史课，不是排名报告。
Search Console 一变就重读契约。 Google 会定期更新"效果"报告的界面和导出字段。如果某个字段消失了，契约当天就要改。
保留旧报告。 拿本季度的报告对比去年同季度，是区分真实下滑与季节性最便宜的办法。
常见问题(FAQ)
一定得用 Codex 吗? 不一定。只要一个智能体能读文件、能按日程运行、能写出可复核的产出，这套流程就能跑。如果你的站点本来就放在仓库里，Codex 很合适，因为报告会变成一个可以对比差异的提交。
只用免费工具能做到吗? 可以。整套流程跑在免费的 Search Console 数据加上智能体之上。只有当你需要竞品排名、或在自己资源里看不到的排名时，才需要付费的排名追踪工具。
这和 Search Console 的"效果"报告有什么不同? "效果"报告给你一张表。这套流程产出一个决策：哪些查询越过了阈值、数据解释了和解释不了什么、下周该检查什么。它还留下了记录，而界面不会留。
如果我的站点流量很少呢? 调低展示次数阈值，并且用 28 天对比去年的同一段 28 天，而不是对比此前 28 天。低流量站点从同比比较里拿到的信号，比从周环比里拿到的更多。
报告里该包含 AI 概览或 AI 引用吗? 想加就加一个独立小节，给它自己的契约。别放进排名报告里，因为来源和度量方式都不同，混在一起会让两边都更难读。
作者：Leo Harrington，Auspia 的 SEO 分析转译者，处理过 500 多份高管报告。Leo 写的是如何把搜索数据变成非专业人士也能据以行动的报告。
