Rankow
面向 SaaS 团队

内容要对得上产品,而不只是关键词清单。

SaaS 内容通常分成两半:带不来转化的文档,和只提一次产品的博客。Rankow 从需求信号出发规划,围绕产品的真实能力写作,并在决定下一篇写什么之前先回读结果。

查看完整引擎

问题所在

这一页要解决的三个失效点。

01

关键词清单压过产品理解。

规划是一张按搜索量排序的清单,于是页面写的都是产品并不能比别人回答得更好的词。

02

单薄文章加一个演示按钮。

八百字、提一次产品、放一个 CTA。没有对比、没有数字,读者在前三条结果里都能看到同样的内容。

03

发布之后没有负责人。

团队转向下一个发布。没人检查页面是否收录、是否有排名、是否拿到点击。

运行什么

同一套闭环,跑在你的站点上。

下面是产品页中记录过的引擎章节——不是为某个细分人群另做的一套产品。

01 · 发现

从需求证据出发,而不是一张竞品词表。

竞品只是输入之一,而不是起点。Rankow 用两个真实需求信号认证种子:竞品自然排名词,以及你 Search Console 里有曝光但未进前三的查询;再用关键词构想、搜索建议与相关词扩池。四类来源合并成一份带来源标记的候选池。

这一层如何工作

03 · 写作

草稿必须凭质量赢得发布名额。

写作从一份简报开始,简报会锁定实体、搜索意图、大纲、来源和 FAQ。质量检查运行之前,先强制执行 3,000 字的下限。

这一层如何工作

05 · 反馈

让 Search Console 闭合这个闭环。

第 28 天,每个页面都会对照 Search Console 检查:收录状态、展示量、排名位置和点击量。结果决定下一步动作。

这一层如何工作

你会得到什么

结果,以及背后的规则。

下面每一条都来自引擎实际运行的同一本规则手册,没有一条是排名承诺。

12,000 个候选关键词,变成这个月的页面清单。

每个周期 120 个页面单元:先枢纽页,再支撑页,支柱页需要通过关卡。

来源 · engine/dfs/planning/plan.py

每篇草稿都要达到 3,000 字并通过对信息增量检查,才能发布。

字数只是底线,不是终点。低于底线或没有增量信号的草稿会被拦下。

来源 · engine/dfs/writing/gate.py

第 28 天:Search Console 告诉你每个页面发生了什么。

按 URL 读取收录状态、平均排名、曝光与点击率,而不是只看账号总量。

来源 · Google Search Console

返回产品总览

常见问题

开始之前。

页面计划每个周期都从竞品覆盖与你自己的 Search Console 查询重建。已发布页面在第 28 天回读,并在第 14 天按刷新规则重新判定。

不会。Rankow 规划和撰写面向搜索需求的页面。文档仍由产品团队维护;这些页面可以作为内链目标,让文章把读者送到权威出处。

可以,通过发布契约:你的应用接收 HTML 正文、SEO 字段与结构化数据,然后自行渲染。目前完全托管的发布路径是 Shopify;其他渠道接收可直接发布的草稿或 payload。

SaaS

规划出你的产品应该占住的页面。

接入 Search Console 和几个竞品域名。第一份产出是页面清单,而不是一批文章。

7 天 · 1 个站点 · 免信用卡

SaaS 团队的 SEO 内容:需求驱动规划与发布后回读 · Rankow