公开更新日志页：商店之外的信任面与 SEO 面

2026/9/17

背景与问题

更新说明只存在于商店内（release notes），看完即消失。把更新日志搬到公开网页（changelog page），solo 产品能多拿到三样东西：信任信号、搜索流量、召回触点。

（来源访问日期均为 2026-09-17）

事实（Releasepad 2026-04 的 SaaS 实例分析）：最好的 changelog 不只是罗列变化——建立信任、推动采用、让用户感到产品活着（alive）。对独立产品尤其重要。
事实（LaunchNotes 对比文）：公开 changelog 建立社区信任，但敏感细节（未发布计划、事故细节）保持内部——公开/内部分界要自觉。
事实（Beamer 最佳实践）：第一条是 easy to find / 不要藏起来——放在导航可见处才有信任效果。
事实（ProductLift 的 15 例）：Stripe、Linear、Notion、Figma 的 changelog 是标准范式——按时间倒序、每条一句人话、带日期与版本号。
推测：solo 的 changelog 页有三重边际收益——①潜在用户判断「这产品还在维护吗」的最快答案 ②「app 名 + 功能关键词」的持续新增内容=长尾 SEO 累积 ③RSS 订阅者=天然召回列表。成本是一次性建页+每次发版多写 5 分钟。
推测：与商店 release notes 的分工：商店版写给「已安装者」（简洁+emoji），网页版写给「未来用户」（完整叙述+链接）——同一次更新两份文本，不复用。

一次性建页：静态页挂在产品域名 /changelog（opc-edge-api-workers 上 10 分钟建好），导航可见（Beamer 第一条）。
每版 5 分钟纪律：日期+版本号+「新功能/改进/修复」各一条人话——写作上限 5 分钟，超出说明拆条。
双文本分工：商店 release notes 简短，changelog 完整叙述——不互相粘贴。
长尾 SEO 用法：每条标题带功能关键词（「○○ が◯◯できるようになりました」）——累积 1 年后「产品名+关键词」组合搜索开始命中（推测）。