SEO 数据只有在推动决策时才真正有价值。Google Search Console 与 Bing Webmaster Tools 能显示点击量、展示量、点击率和平均排名，但我想要一套可重复的流程，把这些数字直接转化为工作：需要改进的页面、值得撰写的文章、应该添加的内部链接，以及需要迁移的旧网址。

因此，我开发了开源项目 GSC + Bing to Obsidian SEO Pipeline。这是一个用 TypeScript 编写的命令行工具，它收集搜索表现数据，并将 Obsidian 仓库变成一套实用的 SEO 知识库。

为什么要构建它？

我管理着多个搜索资源：主站、辅助内容，以及仍可能保留有价值搜索历史的旧资源。分别查看每个仪表盘，很难发现它们之间的关联。

我更想回答一些可直接采取行动的问题：

  • 哪些非品牌关键词已经排在第 5 至 20 位？
  • 哪些页面有大量展示，但点击率偏低？
  • 哪篇博客适合链接到主站页面？
  • 是否有多个页面在争夺同一种搜索意图？
  • 旧资源是否仍在为值得迁移的关键词获取排名？

我也希望保留原始证据。每一条建议都应该可以追溯到具体的关键词、页面、日期范围和指标。

流水线如何工作？

整个流程分为四个主要阶段。

1. 读取已配置的搜索资源

每个资源都有 ID、名称、站点网址、类型，以及可选的品牌关键词规则。类型可以区分主站、博客、旧域名或其他自定义来源。

敏感信息只保留在本地。凭据、API 密钥、Obsidian 路径和真实资源配置均被 Git 忽略；仓库中只提交安全的示例文件来说明配置方式。

2. 按天获取搜索数据

对于 Google，CLI 通过 Search Console API 获取同一时段的多个数据视图：关键词、页面、关键词与页面组合、国家、设备，以及带日期的关键词与页面记录。请求会以每批 25,000 行进行分页。

时间范围会按天抓取。工具先保存可审计的每日快照，再将其聚合为区间和年度数据。聚合时会按展示量重新计算 CTR 与加权平均排名，而不是简单地对已有平均值再次取平均。

最新更新加入了 Bing Webmaster Tools。由于 Bing 的 API 结构不同，适配器会获取关键词、页面以及页面到关键词的统计数据，再将其规范为相同的核心字段，并在每一行标记搜索引擎。Google 与 Bing 数据分别保存在 SEO/GSC/ 和 SEO/Bing/ 中，因此可以比较，又不会被意外混合。

3. 保存原始 CSV 数据集

每次导出都包含来源、搜索引擎、维度、点击量、展示量、CTR、平均排名和日期范围。含有关键词的数据集还会根据该来源的品牌规则生成一份非品牌版本。

Obsidian 仓库由此既是档案，也是工作区：

SEO/
  GSC/
    sources/<source-id>/raw/daily/
    sources/<source-id>/raw/ranges/
    sources/<source-id>/raw/yearly/
    sources/<source-id>/reports/
    sources/<source-id>/ideas/
    combined/
  Bing/
    sources/
    combined/

每日、区间和年度三个层级让我可以检查某一天、研究一次活动周期，或针对整年数据建立数据透视表。

4. 把指标转化为行动

如果配置了品牌规则，报告层会先排除品牌搜索，然后寻找两个主要信号：

  • 展示量较高、CTR 低于 2% 的关键词与页面组合；
  • 展示量至少为 50、平均排名在第 5 至 20 位的关键词。

系统据此生成 Markdown 报告和可供 AI 使用的创意文件，包括快速提升机会、低 CTR 页面、排名机会和潜在新文章。每条创意都会记录当前排名页面、重要原因、建议操作、优先级和背后的指标。

当多个来源一起分析时，流水线还会寻找从博客到主站的内部链接机会、旧站迁移候选、共享关键词和潜在的关键词蚕食。来源、关键词和页面组成稳定键，因此重复运行会更新已有创意，而不是不断制造重复内容。

我使用的命令

完成本地配置后，可以先验证访问权限，而不下载数据：

pnpm gsc:verify
pnpm bing:verify

随后可以为所有启用的来源拉取最近 30 天的数据：

pnpm gsc:pull -- --all --last-days 30
pnpm bing:pull -- --all --last-days 30

本地分析不需要再次请求 Google。它可以直接使用 Obsidian 中已有的每日 CSV 快照重建报告：

pnpm gsc:analyze -- --all --from 2026-06-01 --to 2026-06-30
pnpm gsc:rebuild

这种分离很重要：数据采集、存储和分析可以独立演进；修改品牌关键词规则也不必重新调用 API 下载数据。

项目如何演进？

我在 2026 年 6 月 25 日完成了第一个可用版本。它已经支持 Google 身份验证、数据采集、CSV 导出、Markdown 报告、本地分析和跨来源洞察。

6 月 30 日，我把真实来源定义移到由 Git 忽略的本地 gsc-sources.json 文件中，加强示例配置与设置说明，并添加了本文使用的架构图片。这些调整让仓库更适合安全分享，也更容易被其他人理解。

7 月 12 日，我将流水线扩展到 Bing Webmaster Tools。此次更新加入独立的验证与拉取命令、Bing API 适配器、可识别搜索引擎的存储结构，以及针对 Bing 可用维度的兼容输出。当 Bing 没有匹配行，或没有提供 Google 对应维度时，空文件会被刻意保留；它们是审计记录，而不是被隐藏的缺失结果。

我学到了什么？

这个项目最有价值的部分并不是 API 连接本身，而是围绕它建立的数据模型。

每日快照让重建成为可能。来源元数据让跨资源分析变得有意义。原始数据与派生文件分离，能够维护对建议的信任。稳定的创意键让重复自动化保持可控。Markdown 输出则让我可以直接阅读、在 Obsidian 中搜索，并交给 AI 工具继续使用，而不必把流程锁在另一个仪表盘里。

这套流水线刻意保持本地化和文件化。我可以打开任何 CSV、检查任何建议、修改代码并重建整个知识库。对我的工作方式来说，这正是它的意义。

源代码与设置指南已发布在 GitHub。