更新日志页要不要给搜索引擎看：我的答案是分版本

更新日志（changelog）全量索引，是 SaaS 站里最常见的一种自我伤害。2025 年 1 月我们看一个协作工具的站，changelog 有 640 条记录，每条一个 URL，内容平均 60 个字，整站被索引的页面里三成是这种薄页。我们改成只索引三类，三个月后整站的平均排名位置好了 2.3 位。

更新日志对 SEO 的真实作用

它几乎不带来搜索流量，这是事实。用户不会搜“XX 产品 2025 年 3 月 12 日更新了什么”。它能带来的是另外两件事：一是给产品页提供新鲜度信号，二是让 AI 回答引擎判断这个产品还在维护。

所以目标不是“让每条更新被搜到”，是“让搜索引擎知道你在持续更新，同时别制造垃圾页”。这两件事可以同时做到。

三类进索引，其余不进

第一类，大版本发布。功能模块级的变化，值得一个独立页面，标题写清版本号和核心能力。这类页面通常能吃到“XX 新功能”“XX 支持 XX”这类词。

第二类，迁移和弃用公告。 Breaking change 一定要独立页，用户会搜报错和新写法，这类页面意图极强。

第三类，年度汇总。把一年的更新按季度归并成一页，这是给搜索引擎和 AI 看的产品活跃度证明，也方便媒体引用。

其余的小修小补，全部放在一个按月分页的列表里，列表页可以索引，单条不进索引。我们用 noindex 处理单条，同时在列表页保留完整文本，用户和爬虫都能读到。

一个容易忽略的细节

changelog 页面上的日期要用机器可读格式，加 datePublished 结构化数据。我们给一个客户加上之后，Google 抓取频率从每周两次到每天都有，这不是排名魔法，就是抓取预算分配变了。

另外，changelog 里的功能名要和产品页的叫法一致。我们见过一个产品在 changelog 里叫“智能分组”，在产品页叫“自动分群”，两套词互相稀释。

别做的事

别把 changelog 做成论坛式的碎碎念。“修复了一些问题”“优化了体验”这种条目对用户没用，对搜索引擎更是噪音。我们要求客户每条更新至少写清：改了什么、影响谁、要不要动手。三条写不出来，就别发。

还有一个用法：把 changelog 接进 RSS，让社区和技术周报订阅。有几个项目的更新会被行业周报自动抓取，等于免费的二次曝光，成本只是一行订阅入口。

小团队没有精力维护 changelog 的话，可以只发大版本，一个月一条也比六百条碎记录强。索引量不是资产，能被信任的页面才是。