做独立站时，每周一上午我都在重复同一件事。
打开 Google Search Console 手动导出上月查询数据，再打开 GA4 导出流量前50的落地页 CSV。用 Excel 合并两张表——对齐 GSC 的曝光点击与 GA4 的会话转化，手工标色：流量跌标红，转化低标黄。
全程约一个半小时，发群里只换回一句“收到”。
这活我干了三年，周周如此。
直到上月，一位技术朋友瞥见我的屏幕，说了一句扎心的话：“这不就是调个 API 的事吗？为何每周手动搞？”
我愣住了。他说得对。并非不知 GSC 和 GA4 有 API，而是一想到“写脚本调接口”，脑海便浮现庞大工程：写 Python、处理认证、分页、字段映射、前端展示……虽能省时，但启动成本高到让人懒得动手。
转折点，是 Codex。
一、Codex 是什么——为何不是 ChatGPT
提及 AI 写代码，常人首推"ChatGPT 写脚本”。我也试过：粘贴代码、配环境、装依赖、跑报错、回填修改……循环七八轮，比手动导数据更累。
Codex 定位截然不同。它是一个在终端直接运行的编程 Agent——拥有独立沙箱环境，能读写文件、安装包、执行命令、自动修错。无需拷贝代码，只需自然语言指令，它便自行规划、编写、运行并修复。
例如，我给它的一句指令：
“帮我把 GSC 最近 28 天的查询数据导出，与 GA4 落地页数据按 URL 合并，制作流量下降最多的前 20 个页面表格。”
它自主完成了以下任务：
全程我在旁观察，它自行跑完。中途 GA4 API 日期格式报错，它读取错误信息后自修重跑，一次通过。
🔴 AI 编程工具的核心差异不在“能否写代码”，而在“能否自行跑通”。
二、用 Codex 跑通 GSC+GA4 数据闭环全流程
以下按实操顺序复盘搭建流程，无理论空谈，皆为终端真实运行步骤。
1. 准备工作：Google Cloud 认证
此步无法绕过。GSC 与 GA4 API 均需 Google Cloud 的 OAuth 或 Service Account 认证。无论是否使用 AI，此步必须手工完成。
具体操作：
Codex 在此步无法代劳——认证授权属人机交互流程，无法替代点击 Google 授权页面。但后续步骤只要认证路径正确，它皆可无缝对接。
⚠️ API 自动化首要障碍非代码而是权限。Google 权限体系如俄罗斯套娃——GSC、GA4、Google Cloud 三入口权限互不相通。耐心走完此步，后续自顺。
2. 第一个 Skill：拉取 GSC 查询数据
Codex 的工作模式是将任务打包为可复用的 Skill（技能文件），置于 ~/.codex/skills/ 目录下。每次调用同一 Skill，即按相同逻辑执行。
初版仅拉取 GSC 查询维度数据。该 Skill 告知 Codex 三要素：API 类型、获取维度、输出格式。运行约40 秒，输出排名前100的查询词列表，含点击量、展示量、CTR 及平均排名。
对比上月手动导出 CSV——数据完全一致，顿感“手工时代终结”。
然非全然顺利。GSC API 默认仅返回1000 行，超限需翻页。首次运行时，站点月查询达3400 多条——Codex 自检发现行数不符，自动追加分页逻辑重跑，第二次即获全量数据。
自我发现、自我修复。此体验与用 ChatGPT 写脚本截然不同。
3. 第二个 Skill：接入 GA4
拉取 GSC 后，指令其拉取 GA4 落地页数据。
难度陡增。GA4 Data API 需自建“数据请求体”——定义维度（landingPage）、指标（sessions、conversions、eventCount）、日期范围及过滤条件。其 JSON 结构与 GSC 迥异，且返回包字段名为 eventName_xxx 格式，需自行解析。
Codex 读写 GA4 API 的方式令人印象深刻——调用前先行 Schema 探测：调用 GA4 Metadata API，拉取属性内所有维度、指标及字段命名规则，审视完毕后再构造请求体。
💡 这种“先勘察现场再动手”的模式，正是真人对接新 API 的做法。AI 将其自动化了。
两个 Skill 运行完毕，获得两张表：
接下来是合并。
4. 合并——从双表到优先级 Todo
双表合并看似简单——URL 对 URL 拼接即可。实则暗坑无数。
令 Codex 先行“审视”数据样本，它发现：GSC 页面 URL 带 https:// 前缀，GA4 落地页路径仅写 /blog/seo-guide；GSC URL 末尾含参数 ?utm_source=google，GA4 已剥离；部分页面在 GSC 有数据而 GA4 无，反之亦然。
Codex 自主清洗差异——去前缀、去参数、去锚点、统一末尾斜杠，再做交集合并。
合并后输出的非冰冷透视表，而是按问题类型标记优先级的诊断结果：
| 优先度 | 页面特征 | 诊断方向 |
|---|---|---|
| 🔴 P0 | 曝光下降30% 以上、排名从 top5 跌出 top10 | 排名丢失——查外链、查内容时效性 |
| 🟡 P1 | 高曝光低 CTR（CTR 低于平均50%） | 标题吸引力不足——改 Title 和 Meta |
| 🟡 P1 | 高点击低转化（转化率低于平均40%） | 落地页转化力弱——查页面内容和 CTA |
| 🟢 P2 | 排名8-20 位、有高搜索量 | 近在咫尺——加内链和内容补强 |
📊 将孤立报表转化为按严重程度排序的 Todo——这才是“数据闭环”的真义。不为看数据，而为知行动。
三、实战中踩过的坑
Skill 跑通后回望，一切似“顺理成章”。但当时确有数事实实在在卡住过我。
坑一：GA4 指标名不直观
GA4 API 中，会话数不叫 sessions 而叫 sessions（注：此处原文可能指特定语境下的命名差异，实际常为 eventCount 等混淆），转化数不叫 conversions 而叫 eventCount（仅限标记为转化的事件）。平均参与时间不叫 avgTimeOnPage 而叫 userEngagementDuration，需自行除以会话数。
查文档虽可明了，但需耗时一两小时逐条核对。Codex 省去此时间——构造 API 请求前，它自调 GA4 Metadata 接口，拉取该属性下所有可用指标的名称、类型、描述，按英文语义匹配“我要的是会话数”对应字段。
坑二：GSC API 配额限制
GSC API 每日配额与手动操作一样有上限。首次设分页过于激进——并发调20 页，直接触发限流。Codex 收到 HTTP 429 后暂停数秒重试，二次将分页速率降至每秒2 页，遂稳。
此经历让我意识到——AI 再聪明，调用的仍是人写的 API。限流规则、数据格式、字段命名等脏活它替你扛了，但你须知坑在何处。
坑三：Codex 偶尔过度工程化
曾令其“按页面类型分组”——本意是按 URL 路径前缀（如 /blog/、/product/）区分。Codex 却理解为读取每个页面 HTML 结构提取类型。它确实做到了——调用 requests 库逐页爬取 HTML，分析 meta 标签和 schema 标记后分类。
虽跑通，但耗时近4 分钟。而我所需仅是按 URL 路径前缀做条件分桶。
⚠️ 与 AI 协作时，问题颗粒度决定效率。指令越精确，执行越快；指令模糊，它便以最复杂方式“理解”——且未必告知走了弯路。
四、如何变为“可复用”而非一次性脚本
跑通一次易。将其变为每周可跑、换站可用的“数据闭环”，方显价值。
用 Codex 的 Skill 机制封装
Codex 支持 Skill 文件——即置于 ~/.codex/skills/ 目录下的 Markdown 格式指令文件。本质是一份精准操作手册。每次调用该 Skill，均按同样 SOP 从头执行，避免“上次临时修改未还原”之弊。
我将 GSC+GA4 的拉数→清洗→合并→诊断→输出流程，拆分为三个独立 Skill：
| Skill | 作用 | 输出 |
|---|---|---|
seo-gsc-pull |
拉 GSC 查询 + 页面维度数据，自动翻页 | 两个 CSV：gsc_queries.csv、gsc_pages.csv |
seo-ga4-pull |
拉 GA4 落地页 + 转化数据，自动匹配指标 | ga4_landing.csv |
seo-data-merge |
合并三张表，清洗 URL，输出诊断排序 | Markdown 诊断报告 + 合并后的 CSV |
拆分好处：GSC 异常仅跑 GSC 部分，GA4 配额不足仅跑 GA4 部分，互不阻塞。且不同客户站点，前两个 Skill 数据源不同，第三个 Skill（合并诊断）可复用——仅需修改站点 URL 参数。
一行命令触发全流程
拆分三 Skill 后，在 Codex 中编写“编排 Skill"：
/seo-weekly-report site=example.comCodex 见此指令，按序调用三 Skill——拉 GSC、拉 GA4、合并诊断——最终在终端输出按 P0/P1/P2 排序的页面级诊断报告。全程耗时约2 分钟出头。
💡 “自动化”非写一个永不坏的脚本。而是将重复工作变为一句话触发、且能适应数据变化的流程。
五、搭建完成后的实际变化
毫不夸张，我的周一上午彻底改变。
以前：
现在：
但同时有趣之事发生：昔日“忙很久”发报告，客户觉你工作量大；如今两分钟出结果，反有客户疑“这么快，是否未认真看？”
好笑吗？却是真实人性。
故调整策略：报告生成后，挑出 P0 页面，花15 分钟逐个查看，在报告中增添“人工复核意见”。这 15 分钟非浪费——是让客户感知“有人真看了”，而非 AI 吐出的机器报告。
🔴 AI 替你干脏活。但你的判断、经验、愿多看的那一眼——这些无法被自动化，且恰是客户最在意之处。
六、给想搭建者的几条实在建议
若你也想用 Codex 跑通 SEO 数据闭环，以下是我用真金白银（和时间）换来的经验：
① 勿一开始追求完美。先单独拉通 GSC。
仅一个 Skill：拉最近 28 天查询数据，输出 CSV。跑通即具“全自动排名追踪”能力。从零到一耗时半小时——多在搞 Google Cloud 权限。拉通首个 Skill 后，心理壁垒即消。
② 管好认证文件——此为整条链路“命门”。
Google Cloud 的 Service Account JSON 密钥一旦泄露，他人即可读写你的 GSC 和 GA4。此文件切勿放入 Git 仓库，应用环境变量引用路径，Codex Skill 中用 ${GSC_CREDENTIALS_PATH} 等方式引用，严禁硬编码。
③ 让 Codex 日志输出每一步耗时。
在 Skill 中加入“请在每步操作后记录耗时”。非为炫耀，而为知晓瓶颈所在——是 GSC API 拉取慢、GA4 分页多，还是 URL 清洗逻辑复杂。知己知彼，方能优化。
④ 跨站复用前，确保新旧站点 GA4 属性结构一致。
同 Skill 跑 A 客户正常，跑 B 客户报错——80% 因两 GA4 属性中自定义维度和事件名不同。首次跑新站时，令 Codex 先拉一次 GA4 Metadata 查看结构。
📊 实测数据：单客户从头搭完整套流程约需 45 分钟（含 Google 权限设置），后续每周运行时间约 2 分钟。
GitHub 上有数个开源 Codex SEO Skill 可直接借用——owensky-dev 编写了一套 seo-gsc-ga4-analyst，AminForou 制作了 mcp-gsc 的 MCP 服务端。无需从零造轮子。拿现成 Skill 跑一遍，观其输出，再按需修改。比从零写快10 倍。
当然，现成 Skill 输出未必完全契合需求。如 owensky-dev 那套默认拉90 天数据——我自习惯分析28 天窗口。此类小改动仅在 Skill 文件中改一参数即可，Codex 会读取修改并照做。
全过程——从想法到稳定运行——我耗时约两个下午。首日下午搞权限与 API 对接，次日下午写 Skill 并调优输出格式。此后每一周，它都在帮我省回那两个下午。
上周，一位做外贸站的同行问：“你用什么工具看数据？”
我说 Codex。
他问是否很贵。
我答：不比你上周花在 Excel 里的时间贵。
他沉默数秒，随后道——“那你把那个 Skill 发我一份。”
本篇完整干货已全部分享完毕，既然你已经看完
这份《SEO+GEO 实战清单》
直接送给你，希望能帮你少走弯路！
需要的朋友
我统一发给
（同步设有谷歌 SEO 同行交流社群，有交流需求可私信【社群】领取入群渠道）
这里就不方便放图片展示了.....
请记住这个：