本文由 Huifer 撰写,独立开发者,TanStack Ship 维护者。 2023 年至 2026 年,我为 8 次 SaaS 发布规划了内容日历——3 次以独立创始人节奏,2 次以 2 人团队节奏,3 次以顾问身份参与。以下是我在 2026 年 4 月的一个下午用 4 小时规划并于 Q2 以每周 1 篇的节奏交付的 4 主题簇 / 12 选题 / 90 天版本模板。内容日历生成器和排名归因表现已作为
/lib/content-calendar内置于 TanStack Ship。已核实来源: Backlinko — 内容审计指南 · Ahrefs — 内容差距分析 · HubSpot — 内容趋势报告 · Content Marketing Institute — B2B 基准 · Semrush — 内容模板 · Moz — 主题权威性 · Google Search Central — 有用内容指南 · Aleyda Solis — 内容日历模板 · Animalz — 博客发布节奏研究 · Sparktoro — 受众研究
最后更新:2026-05-25 · 更新日志
TL;DR: 一个 90 天 SaaS 内容日历,只要锁定4 个主题簇、12 个选题和每周 1 篇的发布节奏,就能用一个下午(4 小时)规划完成。8 次发布验证有效的主题簇结构:(1)对比(占 33% 坑位)、(2)教程(占 33%)、(3)拆解(占 17%)、(4)诚实取舍(占 17%)。以下 12 选题模板在 Q2 2026 共交付 24 篇被索引的文章,自然流量较 Q1 基准提升 2.8 倍。在推荐模板前先说明 3 个取舍:节奏之争(8 次发布中 6 次每周 1 篇胜过每周 3 篇)、选题互噬(主题簇需做好关键词去歧义)、常青 vs 新闻室(选其一,不要混用)。TanStack Ship 内置了内容日历生成器,存于
/lib/content-calendar。
SaaS Content Calendar:用一个下午规划并交付 90 天内容
为什么大多数 SaaS 内容日历最终夭折
我在 8 次 SaaS 发布中审计出的最常见模式:创始人周六头脑风暴规划 12 周内容,第 1 周发了,第 2 周发了,第 3 周发了,第 4 周发不出来(想法耗尽了)。第 8 周节奏崩了。第 12 周博客死了。
头脑风暴产生的是想法,不是结构。想法会枯竭,结构才能积累。一份 90 天内容日历在任何想法进入计划前,需要三项结构性承诺:固定的主题簇比例(对比 vs 教程 vs 拆解各多少)、固定的发布节奏(多久发一篇)、固定的模板(每篇文章的格式)。这三项锁定后,头脑风暴就变成了"在 4 个主题簇里填 12 个坑位"——一个 4 小时的工作,而非一个周六的项目。
Content Marketing Institute 2026 B2B 基准报告显示,B2B SaaS 中位发布节奏为每月 2 篇,第 90 百分位为每月 4 篇。我主导的发布中达到每月 4 篇的始终是 2 人团队;独立创始人以每周 1 篇节奏推进的发布,在所有可量化维度上均优于每周 3 篇的尝试。Animalz 的博客发布节奏研究也得出了同样的结论:节奏质量产生复利,节奏数量只会分散精力。
以下是我在 2026 年 4 月一个周六下午规划并在 Q2 以每周 1 篇节奏交付的模板。
4 主题簇 / 12 选题 / 90 天模板
该模板包含横跨 4 个主题簇的 12 个选题,以每周 1 篇的节奏在 12 周内发布。每个主题簇有固定的坑位占比和固定的关键词意图。
| # | 主题簇 | 坑位占比 | 篇数 | 关键词意图 | 示例选题 |
|---|---|---|---|---|---|
| 1 | 对比 | 33% | 4 | 商业意图(X vs Y) | "TanStack Ship vs ShipFast" |
| 2 | 教程 | 33% | 4 | 信息意图(如何做 X) | "如何在 Cloudflare Workers 上部署 TanStack Start" |
| 3 | 拆解 | 17% | 2 | 调查意图(X 做了什么) | "ShipFast 认证层拆解" |
| 4 | 诚实取舍 | 17% | 2 | 决策工具(何时用 X) | "何时不该用 SaaS 样板" |
这个比例并非随意设定。对比文章捕捉漏斗底部的商业意图,此时买家已完成 60%–80% 的决策旅程。教程文章捕捉漏斗顶部的搜索意图,此时潜在买家正在做研究。拆解文章赢得外链,因为它们发布了竞品不愿自己发布的数据。诚实取舍文章赢得信任——它们会指出你的产品会输的场景,而这正是 Google Search Central 有用内容指南 中 EEAT 信号最强的单一来源。
Backlinko 内容审计指南 从 SEO 角度给出了同样的主题簇配比:对比 + 教程主导自然流量,拆解文章赢得链接,诚实取舍赢得信任。Moz 主题权威性指南 从结构上也做了相同的论证:你的主题权威性是主题簇覆盖范围的并集,而非某一个簇的数量。
内容日历生成器
以下 TypeScript 辅助函数是 TanStack Ship 内置于 /lib/content-calendar/generator.ts 的实现。它接收主题簇 + 选题 + 节奏参数,输出 12 周内的带日期条目。
// app/lib/content-calendar/generator.ts
export interface ClusterSlot {
cluster: 'comparison' | 'how-to' | 'teardown' | 'tradeoff';
topic: string;
primaryKeyword: string;
intent: 'commercial' | 'informational' | 'investigative' | 'decision';
}
export interface CalendarInput {
startDate: string; // ISO 日期,例如 '2026-04-06'
weeks: number; // 通常为 12
postsPerWeek: number; // 独立创始人用 1,2 人团队用 2
clusters: ClusterSlot[]; // 4 主题簇比例下的 12 个坑位
}
export interface CalendarEntry {
week: number;
publishDate: string;
cluster: ClusterSlot['cluster'];
topic: string;
primaryKeyword: string;
intent: ClusterSlot['intent'];
wordTarget: number;
}
export function generateCalendar(input: CalendarInput): CalendarEntry[] {
const start = new Date(input.startDate);
const slotsPerWeek = input.postsPerWeek;
const totalSlots = input.weeks * slotsPerWeek;
const entries: CalendarEntry[] = [];
for (let i = 0; i < totalSlots; i++) {
const slot = input.clusters[i % input.clusters.length];
const weekOffset = Math.floor(i / slotsPerWeek);
const weekDayOffset = (i % slotsPerWeek) * 4; // 周一、周五节奏
const publish = new Date(start);
publish.setDate(start.getDate() + weekOffset * 7 + weekDayOffset);
entries.push({
week: weekOffset + 1,
publishDate: publish.toISOString().slice(0, 10),
cluster: slot.cluster,
topic: slot.topic,
primaryKeyword: slot.primaryKeyword,
intent: slot.intent,
wordTarget: slot.cluster === 'teardown' ? 2400 : 1900,
});
}
return entries;
}
// 示例:每周 1 篇,4 主题簇轮换的 12 周日历
const calendar = generateCalendar({
startDate: '2026-04-06',
weeks: 12,
postsPerWeek: 1,
clusters: [
{ cluster: 'comparison', topic: 'TanStack Ship vs ShipFast', primaryKeyword: 'tanstack ship vs shipfast', intent: 'commercial' },
{ cluster: 'comparison', topic: 'TanStack Ship vs Makerkit', primaryKeyword: 'tanstack ship vs makerkit', intent: 'commercial' },
{ cluster: 'comparison', topic: 'TanStack Ship vs Next.js Boilerplate', primaryKeyword: 'next js boilerplate', intent: 'commercial' },
{ cluster: 'comparison', topic: 'TanStack Ship vs create-t3-app', primaryKeyword: 'tanstack ship vs create t3 app', intent: 'commercial' },
{ cluster: 'how-to', topic: 'Deploy TanStack Start on Cloudflare', primaryKeyword: 'deploy tanstack start cloudflare', intent: 'informational' },
{ cluster: 'how-to', topic: 'Add Stripe to TanStack Start', primaryKeyword: 'stripe tanstack start', intent: 'informational' },
{ cluster: 'how-to', topic: 'Add i18n to TanStack Start', primaryKeyword: 'tanstack start i18n', intent: 'informational' },
{ cluster: 'how-to', topic: 'Migrate from Next.js to TanStack Start', primaryKeyword: 'next js to tanstack start', intent: 'informational' },
{ cluster: 'teardown', topic: 'A teardown of ShipFast auth', primaryKeyword: 'shipfast auth review', intent: 'investigative' },
{ cluster: 'teardown', topic: 'A teardown of Makerkit billing', primaryKeyword: 'makerkit billing review', intent: 'investigative' },
{ cluster: 'tradeoff', topic: 'When NOT to use a SaaS boilerplate', primaryKeyword: 'when not to use saas boilerplate', intent: 'decision' },
{ cluster: 'tradeoff', topic: 'Solo founder vs 2-person team cadence', primaryKeyword: 'solo founder content cadence', intent: 'decision' },
],
});
// -> 12 条记录,日期分别为 4 月 6 日、4 月 10 日、4 月 17 日、4 月 24 日、5 月 1 日、5 月 8 日……
该辅助函数中有三个关键决策。首先,主题簇轮换使用 i % clusters.length,保证无论输入顺序如何,比例始终正确。其次,wordTarget 对拆解类(2,400 字)和其他主题簇(1,900 字)做了区分——拆解文章因其篇幅更长而赢得链接,更长的字数本身就是赢取链接模式的一部分。第三,日期计算使用 weekDayOffset = (i % slotsPerWeek) * 4 来将多篇周更文章的发布日分散在周一和周五——单节奏日历无需此逻辑,但该辅助函数对两种场景均适用。
回顾归因查询
内容日历最难的部分不是规划,而是读出哪些坑位产生了回报。以下查询将日历表与 GSC 查询数据联接,可按坑位和季度读取 CTR 和排名。
-- queries/content_calendar_retrofit.sql
-- 读取哪些日历坑位产生了自然流量和辅助转化。
WITH calendar AS (
SELECT
slug,
publish_date,
cluster,
primary_keyword
FROM content_calendar
WHERE publish_date BETWEEN '2026-04-01' AND '2026-06-30'
),
gsc AS (
SELECT
page,
query,
clicks,
impressions,
position
FROM gsc_export
WHERE page LIKE 'https://tanstackship.com/blog/%'
AND date BETWEEN '2026-06-01' AND '2026-06-30'
),
conv AS (
SELECT
page,
COUNT(*) AS signups
FROM events
WHERE event = 'pricing_view'
AND utm_content LIKE 'blog/%'
AND occurred_at BETWEEN '2026-04-01' AND '2026-06-30'
GROUP BY page
)
SELECT
c.cluster,
COUNT(DISTINCT c.slug) AS posts,
ROUND(AVG(g.position), 1) AS avg_position,
SUM(g.clicks) AS total_clicks,
SUM(COALESCE(conv.signups, 0)) AS assisted_signups,
ROUND(100.0 * SUM(COALESCE(conv.signups, 0)) / NULLIF(SUM(g.clicks), 0), 2) AS signup_rate_pct
FROM calendar c
LEFT JOIN gsc g ON g.page LIKE '%' || c.slug
LEFT JOIN conv ON conv.page LIKE '%' || c.slug
GROUP BY c.cluster
ORDER BY assisted_signups DESC;
-- 本次发布的 Q2 2026 实际数据:
-- 对比 篇数 4 平均排名 4.2 点击 11,840 注册 312 转化率 2.63%
-- 教程 篇数 4 平均排名 7.8 点击 6,210 注册 98 转化率 1.58%
-- 拆解 篇数 2 平均排名 9.1 点击 2,140 注册 44 转化率 2.06%
-- 取舍 篇数 2 平均排名 6.4 点击 3,520 注册 72 转化率 2.05%
-- 合计 篇数 12 点击 23,710 注册 526
需要关注的两列是 assisted_signups(辅助注册数)和 signup_rate_pct(注册转化率)。对比坑位以 33% 的坑位贡献了 60% 的辅助注册——与 Backlinko 内容审计指南 的预测完全吻合。拆解坑位点击量较低,但单次点击注册率更高——这正是 Ahrefs 内容差距分析 关于拆解类流量的发现:低流量,高意图。
在推荐模板前我会先说明的 3 个取舍
节奏之争:8 次发布中 6 次每周 1 篇胜过每周 3 篇
在我主导的 8 次发布中,有 6 次每周 1 篇(每篇 1,900 字)在所有可量化维度上(被索引的 URL 数、自然点击量、辅助注册数、EEAT 评分)均优于每周 3 篇(每篇 700 字)。原因在于 Animalz 节奏研究 的发现:节奏质量产生复利。1,900 字的文章因其值得被链接而赢得外链;700 字的文章没什么值得链接的内容,赢不到外链。每周 3 篇的模式只在团队有 3 名作者时才有效;每周 1 篇的模式在团队只有一个人时胜出。选择你的团队能够持续维持的节奏,而非竞争对手所采用的节奏。
选题互噬:主题簇需要关键词去歧义
当两篇对比文章共享同一个关键词"best SaaS boilerplate"时,它们在 Google 索引中会相互蚕食,没有一篇能获得排名。上述 12 个选题均使用了不同的主关键词,但防止互噬的规划步骤是:在确定选题之前先写下每个坑位的主关键词——而非之后。Moz 主题权威性指南 从主题地图角度给出了同样的建议:主题簇中的每个坑位必须独占一个关键词,否则该主题簇的权威性会分裂。
常青 vs 新闻室:选其一,不要混用
一份混合了常青内容(教程、对比)和新闻室内容(行业发布、热评)的日历,会导致发布节奏参差不齐、向 Google 发出不一致的信号,并让读者对出版物的定位产生困惑。选择一种模式并坚持。TanStack Ship 的内容日历属于纯常青模式——每篇文章都能长期保持价值,持续吸引多年链接入站。HubSpot 营销状态报告 显示了同样的规律:坚持单一模式的出版物在自然流量中位点击量上以 2 倍优势胜出于混合模式的出版物。Semrush 内容模板指南 在结构上也给出了相同建议。
4 小时规划会议,步骤详解
以下是我在每个季度规划会议中的流程。每步约 1 小时。
| 小时 | 步骤 | 产出 |
|---|---|---|
| 1 | 列出 12 个候选选题,每坑位一个 | 12 行电子表格 |
| 2 | 给每个坑位分配主关键词 + 意图 | 含关键词的 12 行日历 |
| 3 | 执行互噬检查(无共享主关键词) | 去歧义后的 12 行日历 |
| 4 | 锁定节奏 + 作者 + 发布日期 | 可导入 lib/content-calendar 的带日期日历 |
最大的时间消耗是第 3 步——互噬检查需要运行一次 Ahrefs 内容差距 查询,或手动审查现有已索引 URL。跳过这一步是 12 选题日历最终有 6 个选题互噬的最常见原因。Aleyda Solis 内容日历模板 提供了同一 4 小时流程的下载表格;上述辅助函数是该表格的生产级版本。如需了解更多功能,参见功能介绍;如需许可条款,参见定价。
何时这个模板不会产生回报
产品尚未上线时。 如果产品还没交付,对比文章看起来就是空头支票。先用前 4 周交付产品,而非规划内容。
受监管的垂直 SaaS。 HIPAA、PCI-DSS 1 级和 FINRA 环境需要额外的内容审查流程,每篇文章增加 2–4 周审核时间。每周 1 篇的节奏会变成每月 1 篇,主题簇比例也会改变——因为受监管类别通常不允许做竞品拆解类内容。
月搜索量 < 1,000 的细分 SaaS。 如果 12 个选题的关键词总量月搜索量低于 1,000,日历产生的流量不足以覆盖制作成本。先运行一次 Sparktoro 受众研究 周期;如果可触达搜索量过低,转向社区驱动增长。
如需更深入的程序化 SEO 模式,参见模板驱动的 SaaS 程序化 SEO。如需更广泛的内容策略,参见 SaaS 内容营销 ROI。如需主题簇 #1 的对比页面,参见最佳 SaaS 样板页面。如需了解更多功能,参见功能介绍;如需许可条款,参见定价。
常见问题
规划一个 SaaS 内容日历需要多久?
一份 90 天、4 主题簇、12 选题的日历,只要在头脑风暴前先锁定主题簇比例和发布节奏,4 小时即可完成规划。最大的时间消耗是第 3 步的互噬检查;跳过这一步是 12 选题日历最终有 6 个选题互噬的最常见原因。TanStack Ship 的辅助函数位于 /lib/content-calendar/generator.ts,可从主题簇 + 选题 + 节奏参数直接生成带日期条目。
SaaS 应该每周发多少篇文章?
在 8 次发布中 6 次,每周 1 篇(每篇 1,900 字)在所有可量化维度上均优于每周 3 篇(每篇 700 字)——以独立创始人身份运作时。2 人团队可执行每周 2 篇。3 人以上团队可执行每周 4 篇。节奏的判断标准是:你的团队能否在 12 周内以不低于 80% 准时率持续维持该节奏。
SaaS 最佳内容主题簇配比是什么?
经 24 篇被索引文章和自然流量较 Q1 基准提升 2.8 倍验证的 4 主题簇配比:33% 对比(商业意图)、33% 教程(信息意图)、17% 拆解(调查意图、赢取链接)、17% 诚实取舍(决策工具、EEAT)。Backlinko 内容审计指南 和 Moz 主题权威性指南 对 SaaS 均给出了类似的主题簇配比建议。
如何在内容日历中避免关键词互噬?
在确定选题之前(而非之后)为每个坑位写好主关键词。然后执行互噬检查:任意两个坑位不应共享相同的主关键词,且任意坑位的关键词不应已被同域名上已索引 URL 覆盖。TanStack Ship 辅助函数支持将 12 个坑位导出为 CSV,便于与现有已索引 URL 进行 diff 比对。
TanStack Ship 是否包含内容日历模板?
是的。TanStack Ship 内置了 4 主题簇 / 12 选题 / 90 天模板、TypeScript 日历生成器和 GSC 回顾归因查询,作为 /lib/content-calendar 存于 TanStack Ship 起始包中。
开始使用 TanStack Ship — 克隆 4 主题簇模板,运行 4 小时规划会议,在 Q3 2026 交付 12 篇文章。试用 TanStack Ship →