Content

Make.com + ChatGPT：把 GSC 数据变成每周自动产出的内容简报流水线

Make.com + ChatGPT：把 GSC 数据变成每周自动产出的内容简报流水线
目录

上周二早上 9:14，一份内容简报准时落进我编辑的 Notion 工作区。三段结构 — 目标关键词、搜索意图摘要、建议的 H2 大纲。简报针对的查询我从未专门写过：「programmatic SEO content brief template」（过去 28 天 1,240 次展示、平均排名 11.3）。那份简报不是我写的，是一个 Make.com 自动化场景完成的，ChatGPT 填了正文内容。我花的时间是 47 秒，大部分在看着运行日志刷屏。

下面我把这条流水线拆给你看。它不复杂 —— 一个 12 模块的 Make.com 自动化：拉取 Google Search Console（GSC，谷歌站长工具）数据、按几条经验规则过滤、把胜出者交给 ChatGPT、再把结构化简报写进 Notion，让编辑直接接手。我第一版花了一个下午搭出来。现在跑的第三版，按我这份蓝图复制粘贴大约 15 分钟就能上线。

为什么值得做：很多人卡在「我有 GSC 数据」到「我知道下周一写什么」之间的这一步。他们导出一份 CSV，对着 4,000 行发愁，凭直觉挑三条，开干。下面的流水线把 4,000 行导出变成 8 到 12 条排好序、格式齐整的简报 — 每周一自动产出，不用人工筛选。

你需要什么

  • 一个 Make.com 账号（免费版够跑一个站点；我用的是 Core 套餐，9 美元/月，10,000 次操作）
  • 一个有 GSC 站点权限的 Google 账号
  • 一个 OpenAI API Key（任何兼容 chat-completions 协议的端点都行 — 我用的是 GPT-4o-mini，输入 0.15 美元/百万 token，每周完整跑一次不到一杯咖啡钱）
  • 一个 Notion 数据库，或者一个 Google Sheet，再不行一个 Slack 频道也行
  • 第一次需要 20 分钟左右

没了。不需要服务器，不需要 Python，也不用被 Zapier 的按任务计费割。

第一步：拉取 GSC 数据

Make.com 有原生 GSC 模块（Search Console > Perform a Query）。我用的参数：

  • siteUrl： 已验证的属性（用 sc-domain: 前缀拿域名级数据，不要用 https:// URL 前缀 — 域名级才能跨子域汇总）
  • startDate / endDate： 滚动 28 天（我把它存成 Make.com 变量，后面想改不用动场景本身）
  • dimensions： 只选 query（页面级细分后面需要再加）
  • rowLimit： 25,000（GSC 硬性上限，单个站点几乎碰不到）

模块返回（query, clicks, impressions, CTR, position）几列。不用做转换，就是原始导出。跑一次确认输出正常。如果返回 0 行，先检查日期范围 — GSC 数据有 2-3 天延迟，「从今天往前 28 天」能跑，「从昨天往前 28 天」可能会少一天。

第二步：过滤到「触手可及」的查询

4,000 行的导出大部分是噪音。你真正想要的是排名 8 到 20 的那一段 — 离首页够近，一篇好文章能撬得动；离首页又不太近，SERP（Search Engine Results Page，搜索引擎结果页）上还没被比你强的站吃掉。

Make.com 加一个 Filter 模块：position >= 8 AND position <= 20。再加一个：impressions >= 100。impressions 那个门槛是经验值 — 我一开始设 50，长尾一次性的查询太多，后来调到 100。小站点（月搜索量 5,000 以下）可以降到 50。

第三个过滤器我偶尔会加：query NOT contains (品牌词)。把"品牌词"换成你不想出简报的字符串 — 公司名、常见拼错、内部行话。如果你是名字很普通的初创公司、想排自己品牌词，这个可以不加。

结果：通常 30 到 80 条查询通过。这就是候选池。

第三步：打分排序

我想要的是排好序的简报列表，不是字母表。Make.com 有 Iterator 模块 — 把数组拆成单条查询，再丢进 Math 模块算一个简单分数：

score = impressions * (1 / position)

这个公式的偏好是「曝光大、排名一般」 — 正是用一篇文章能撬动的类型。Position 15、800 曝光的查询，永远跑赢 Position 9、90 曝光的。（你想换成更复杂的模型也行 — 我试过 logistic 曲线，对前 10 名结果没有实质影响。第一版保持简单。）

按 score 降序排，前 12 名入选。

第四步：交给 ChatGPT

这是所有人最容易过度设计的一步。Make.com 里的 OpenAI 模块走 Messages > Create a Completion。模型：gpt-4o-mini。Temperature：0.4（我要的是稳定，不是创意）。Max tokens：800。

Prompt 是唯一重要的事。下面是我用了八个月没改过的系统提示词：

You are a content strategist. Given a target search query, current
ranking position, and monthly impressions from Google Search Console,
produce a JSON object with this exact structure:

{
  "target_query": "",
  "search_intent": "",
  "intent_summary": "",
  "suggested_title": "<60 char max, includes the query verbatim>",
  "h2_outline": ["
", "
", "
", "
"],
  "competing_serp_threats": "",
  "word_count_target": ,
  "must_include_entities": ["", "", ""]
}

Do not add any prose outside the JSON. Do not use markdown fences.

用户提示词只有一行：

Target query: {{query}}
Current position: {{position}}
Monthly impressions: {{impressions}}
Top competing page (optional): {{top_page}}

我加「可选的 top competing page」字段是因为注意到 ChatGPT 偶尔会给出和首页已存在内容矛盾的 H2。当你喂一个 URL 进去，让它（用一个并行的 HTTP 模块）抓一下页面，就能用首页真实的 H2 结构作为对比目标。这一个改动，把我「编辑返工半份简报」的比例从 40% 降到 12% 左右。

第五步：解析与校验

Make.com 的 OpenAI 模块返回纯文本。JSON 解析很脆弱 — 模型偶尔会甩一个多余的 backtick 或末尾逗号，它就是会在某个凌晨两点、周日没别的事崩的时候崩。

加一个 JSON > Parse JSON 模块。包一层 Ignore error handler，单条解析失败不会让整次运行挂掉。再加一个 Filter 模块：只有解析后对象包含全部八个必需字段才继续。少一个就丢到一个 Slack 频道，标签 #content-brief-errors，附上原始输出。这种情况你手修一下 — 一个月 0 到 2 次。

第六步：写入 Notion

Notion 模块 > Create a Database Item。字段映射：

  • Title ← suggested_title
  • Query ← target_query
  • Position ← position（数字，不是字符串）
  • Impressions ← impressions
  • Status ← "Briefed"（一个 select 字段，编辑把它改成 "Drafting" → "Published"）
  • Brief JSON ← 整个对象作为 Notion 代码块（让编辑不用跳出 Notion 就能看 H2 大纲和实体词）
  • Due Date ← 今天 + 7 天（滚动周节奏）

「Due Date = +7 天」这点很关键。简报堆在 backlog 里会烂掉。每条锁到下周一就有了软约束 — 编辑清楚知道这个槽位是什么时候。

第七步：定时

Make.com 的定时很直接：我设的是每周一早上 8 点本地时间。整个跑完在月曝光 5 万的站点上大约 4 分钟（12 次迭代、12 次 ChatGPT 调用、12 次 Notion 写入）。小站点（5,000 曝光以下）90 秒搞定。

设好定时之后，加一个「bundle」开关 — 场景顶部一个 boolean 变量，能整体开关。我在手动推内容、不想让新批次冲乱 Notion 视图的时候用这个。

要小心的几件事

GSC 的日期延迟。 最近 2-3 天是缺的。如果你设 endDate = today()，你会静默丢掉最近一周的数据。永远用 endDate = today() - 3 days，startDate = endDate - 28 days。我吃过亏：一份简报让我「改进」一个查询，结果那个查询在我写简报的四天前已经到 Position 4 了 — 数据晚了 4 天，而我已经发了那篇把排名推上去的文章。

关键词级排名是噪音。 「平均排名 11.3」可能是工作日 5、周末 18。排名判断用 28 天平均，不用 7 天。Position 是个数字，不是判决书。

同一条查询不要出两次简报。 加一个检查：创建 Notion 条目之前，先在数据库里搜 Query 匹配且 Status 不是 "Skipped" 的记录。找到了就把新这条标 "Duplicate" 跳过。不加这个你会每周一都给「what is X」出简报到天荒地老。

ChatGPT 的幻觉是真的，只是出现的位置你想不到。 它很少编造查询 — 查询就在 prompt 里。它会编造 实体词（建议提到的人名、工具、数据）。把 must_include_entities 当草稿，编辑在写之前每个 Google 一下。我抓到过一份简报让我引用「2024 HubSpot 研究」，那东西根本不存在。模型是从训练数据做模式匹配，不是真去查。

Make.com 的操作次数会累积。 免费版 1,000 ops/月，4 周就烧完。Core（$9/月，10,000 ops）是现实最低线。多站点或要每天跑就上 Pro。成本在 操作数 — 12 行流水线一次跑大约 350 ops（GSC 拉取、迭代、数学、Prompt、解析、Notion 写入、并行 SERP 抓取分支）。单站点、每周跑，Core 足够。

它不是什么

它替代不了编辑判断。流水线给出候选，编辑才决定哪个匹配品牌、漏斗、下季度主题。我有一条铁律：没有编辑在 Notion 里点头的简报不能进写作。自动化 47 秒帮你从数据走到 80% 草稿，剩下 20% 还得是人。

它也不是低流量站点的银弹。如果你的域名月曝光不到 5 万，触手可及那一段查询很有限，简报会很重复。5,000 月曝光的站点每周可能只有 2 条简报，同一个查询可能每 5-6 周循环一次。没问题 — 只是流水线会跑得轻一些。

半年跑下来的结果

我在三个站点上跑这个场景。汇总起来，过去 180 天我发出去的文章里，大约 38% 是这条流水线产出的简报驱动的。这些文章里 90 天进前 10 的比例：大约 41%。对比我以前的流程（手动 CSV 筛选 + 直觉选词）：22%。提升不是来自 AI 写出更好的简报 — 而是来自 AI 不会累、不会跳过一周、也不会挑一个我已经排上的查询。

我给 pillar page（核心支柱页）还是手写简报。模型建议的 H2 大纲我不同意的时候还是会改。但「下周一发什么」这种稳定的鼓点，流水线搞定。

整套 12 个模块，每周跑一次，成本大约 0.4 美元 OpenAI 费用 + 一份 9 美元的 Make.com 订阅。会配一个 Zap 的人，一个下午能搭出来。