整套系统搭建耗时约 60 分钟，不依赖任何云服务或数据库，所有数据在本地处理。
架构设计：三个脚本解决问题
设计原则是极简：Agent 收到请求 → 通过 exec 工具调用本地 Node.js 脚本 → 脚本调用官方 API → 返回纯文本 → Agent 分析并给出建议。
文件结构：
~/.openclaw/workspace/
├── scripts/
│ ├── gsc-report.cjs # Google Search Console 查询
│ ├── ga4-report.cjs # Google Analytics 4 查询
│ └── bing-report.cjs # Bing Webmaster 查询
└── credentials/
├── gcp-service-account.json # Google 服务账号密钥
└── bing-webmaster-api-key.txt # Bing API Key
三个脚本，两个密钥文件，没有中间层。
步骤一：Google Cloud Console 配置（15 分钟）
Google API 访问通过 Service Account（机器人账号）实现。
创建 Service Account：
- 打开 Google Cloud Console，创建新项目（如
openclaw-seo） - 进入 IAM & Admin → Service Accounts → Create Service Account
- 名称随意（如
openclaw-seo-reader），角色可暂不选 - 创建后点击该 SA → Keys → Add Key → Create new key → JSON
- 下载 JSON 文件，保存到
~/.openclaw/workspace/credentials/gcp-service-account.json
JSON 文件中的 client_email 字段形如 openclaw-seo-reader@项目名.iam.gserviceaccount.com，后续授权都需要这个邮箱。
启用 API：
在 APIs & Services → Library 中搜索并启用：
- Google Search Console API
- Google Analytics Data API
两个都必须启用，否则脚本会报 API has not been enabled 错误。
步骤二：Google Search Console 授权（10 分钟）
注意：GSC 权限不在 Google Cloud 设置，而是在 Search Console 网站本身。
- 打开 Search Console，选择站点
- 左侧「设置」→「用户和权限」→「添加用户」
- 输入上一步的
client_email，权限选「受限」（只读即可）
踩坑： 每个站点必须手动单独添加，没有全局批量授权。10 个站点就要重复 10 次。
步骤三：Google Analytics 4 授权（10 分钟）
流程与 GSC 类似：
- 打开 Google Analytics → 左下角「管理」→ 选择目标媒体资源
- 「媒体资源」→「媒体资源访问权限管理」→ 右上角「+」→「添加用户」
- 输入
client_email，角色选「查看者」
重要踩坑：GA4 的 Property ID 和数据流 ID 是两个不同的东西。
- Property ID：在「媒体资源详情」中查看，是一串纯数字（如
489888837） - 数据流 ID：在「数据流」中查看，也是数字但完全不同
脚本中使用的是 Property ID，格式为 properties/489888837。第一次配置时搞混这两个 ID，调试了很久才定位到原因。
步骤四：Bing Webmaster Tools 配置（5 分钟）
Bing 不需要 Service Account，直接用 API Key：
- 打开 Bing Webmaster Tools → 右上角「设置」→ API access
- 点击 Generate API Key
- 复制保存到
~/.openclaw/workspace/credentials/bing-webmaster-api-key.txt（纯文本，一行即可）
步骤五：安装依赖（5 分钟）
cd ~/.openclaw/workspace/scripts
npm install googleapis google-auth-library
踩坑： package.json 中不要加 "type": "module"。如果存在该配置，Node.js 会将所有 .js 文件当作 ES Module 处理，导致 require is not defined 报错。
解决方案： 将脚本文件命名为 .cjs 而非 .js。无论 package.json 如何配置，Node.js 都会以 CommonJS 模式加载 .cjs 文件。
步骤六：三个核心脚本实现（15 分钟）
GSC 脚本 gsc-report.cjs
查询关键词排名、点击、展示、CTR 和 Top 页面。
核心逻辑：
- 使用
googleapis库连接 Google Search Console API - 读取本地 Service Account JSON 密钥
- 配置站点列表，注意资源名格式区分：域名资源用
sc-domain:前缀，URL 前缀资源用完整 URL（含末尾斜杠） - 调用
searchanalytics.query方法，设置日期范围、维度（query/page/country）、行数限制
最大的坑在资源名格式上：
- 域名资源：
sc-domain:example.com - 网址前缀资源：
https://example.com/
格式不对时 API 返回 403 User does not have sufficient permission，这个错误信息极具误导性——实际问题是资源名写错了。建议先调用 searchconsole.sites.list() 列出所有已授权站点，确认正确格式。
运行方式：
# 查所有站点
node scripts/gsc-report.cjs
# 只查某个站
node scripts/gsc-report.cjs slitherlinks
# 查某个站的特定关键词
node scripts/gsc-report.cjs slitherlinks "puzzle"
GA4 脚本 ga4-report.cjs
查询用户、会话、页面浏览、流量来源、国家分布。
核心逻辑：
- 使用
google.analyticsdata连接 GA4 API - 配置 Property ID 列表（纯数字）
- 调用
properties.runReport，设置维度（sessionDefaultChannelGroup/country/pagePath）和指标（sessions/activeUsers）
运行方式：
# 查所有站点，默认 28 天
node scripts/ga4-report.cjs
# 指定站点和天数
node scripts/ga4-report.cjs slitherlinks 7
Bing 脚本 bing-report.cjs
代码最简单，无需 OAuth。
核心逻辑：
- 使用 Node.js 原生
https模块 - 读取本地 API Key 文本文件
- 调用两个端点：
GetRankAndTrafficStats（流量统计）和GetQueryStats（关键词数据） - 返回 JSON 格式数据
让 Agent 使用脚本
配置完成后，Agent 通过 exec 工具直接调用脚本。实际对话流程：
用户：帮我看看最近 slitherlinks.com 的 SEO 表现
Agent 内部调用：
exec: node ~/.openclaw/workspace/scripts/gsc-report.cjs slitherlinks
exec: node ~/.openclaw/workspace/scripts/ga4-report.cjs slitherlinks 7
→ 汇总分析，给出建议
Agent 拿到纯文本数据后可以做的事情：
- 对比本周 vs 上周变化趋势
- 找出展示量大但点击率低的关键词（优化机会）
- 发现流量下降的页面
- 生成每日/每周 SEO 报告
- 异常流量预警
进阶：定时自动报告
通过 cron 实现每日自动运行：
crontab -e
# 每天早上 8 点运行
0 8 * * * node /Users/yourname/.openclaw/workspace/scripts/gsc-report.cjs >> /tmp/seo-report.log 2>&1
也可以在 OpenClaw 的 HEARTBEAT.md 中加入 SEO 检查任务，让 Agent 定期主动查询并汇报。
安全事项
系统完全本地化，但密钥管理不能松懈：
credentials/目录已加入.gitignore，绝不上传到代码仓库- Service Account 仅申请只读权限（readonly scope），即使密钥泄露也无法修改数据
- API Key 文件设置严格权限：
chmod 600 ~/.openclaw/workspace/credentials/gcp-service-account.json
chmod 600 ~/.openclaw/workspace/credentials/bing-webmaster-api-key.txt
踩坑全记录
| 问题 | 原因 | 解决方案 |
|---|---|---|
require is not defined |
package.json 含 "type": "module" |
脚本文件改名为 .cjs |
403 insufficient permission |
GSC 资源名格式错误 | 用 sites.list() 确认正确格式 |
sc-domain: vs https:// 混淆 |
两种资源类型格式不同 | 域名资源用 sc-domain:，URL 前缀用完整 URL |
| GA4 查询无数据 | 误填数据流 ID | 去「媒体资源详情」确认 Property ID |
API not enabled |
未在 GCP 启用对应 API | 去 Library 搜索并启用 |
| 新站查不到数据 | Service Account 未添加到该站权限 | 每个站点单独授权 |
其中 GSC 资源名格式问题最耗时间——sc-domain: 和 https:// 的区别导致的 403 错误信息完全不指向真正原因。
给独立开发者的实操建议
- 先跑通一个站点再批量配置。 把 GSC、GA4、Bing 三个脚本在单个站点上调通，确认数据正确后再扩展到其他站点。
- 资源名格式用 API 确认，不要手写。 调用
sites.list()拿到精确格式，复制粘贴到配置中。 - 脚本输出设计为纯文本。 Agent 处理纯文本的效果远好于 JSON，格式化的文本也方便人工抽查。
- 从只读权限开始。 初期不需要任何写入能力，只读 scope 足够完成所有分析工作，也降低了安全风险。
- 把 SEO 检查写进 Agent 的日常任务。 放入
HEARTBEAT.md让 Agent 每天主动跑一次，你只需要看结果和行动建议，真正实现「问一句话，搞定所有站」的工作流。