改了什么要写下来：目录站的更新日志页该放什么，要不要让搜索引擎收

更新日志是个典型的「不做也没人骂，做了会有人喜欢」的功能。它不直接带来流量，但它解决一个很实际的问题：目录站这类站点，用户很难感知你在进步。你修了三十个死链、加了五个分类，用户只看得到首页那几十个卡片，感觉什么都没变。

写下来，用户就知道这站还活着。

图片来源：网络，版权归原作者所有，侵权请联系删除

常见错法：把提交记录直接导出当日志

最容易想到的做法是把代码仓库的 commit 记录自动生成一页。省事是省事，但读起来完全是另一种语言——「fix: 修复列表页 N+1」「refactor: 抽离卡片组件」，用户看不懂，也不关心。

更新日志的读者是使用者，不是开发者。同一件事要换个说法：前者该写成「列表页加载速度提升约 40%」，后者压根不该出现在这页上。

该写	不该写
用户能感知到的变化	纯内部重构
新增/删除了哪些分类	依赖库版本升级
已知问题和修复时间	还没上线的计划
收录规则、排序规则的调整	内部账号和权限变动

URL 固定，别按天拆成几百页

一种做法是单页加锚点：/changelog/ 一个页面，按月分段，每个月一个标题带 id。好处是权重集中，坏处是页面会越来越长（可以用折叠或者按年分页解决）。

另一种是按月分页：/changelog/2026-10/。这也可以，但要在每页顶部或底部链上相邻月份，别让它们变成孤岛。

千万别按天拆。一天一条「修复若干问题」的页面，就是标准的薄内容。真要按时间粒度细，一条变更写一段、多条变更合到一个月，比拆成三十个页面强得多。

收录取舍：看去掉日期还剩多少

判断标准很简单：把日期和版本号遮掉，看剩下的文字对陌生人还有没有价值。

值得收录的写法，是每条变更都写清「改了什么」和「对用户有什么影响」。比如「分类页默认排序改为按最近验证时间，之前是按入库时间，老条目可能位置下降」——这句话独立于日期也成立，能被搜到，也能被引用。

不值得收录的，是那种一行「优化部分页面体验」。这种条目攒一年也不该给搜索引擎看，要么不写，要么整个页面加 noindex。

让这个页面更有用的三条

• 每条带日期和影响范围。「影响全部条目」和「只影响移动端」要分开标，用户能自己判断跟自己有没有关系。
• 重大变更单独成段。收录规则调整、付费政策变化这类，写一段带背景的说明，别混在列表里当一行。
• 顺手输出一份 RSS。愿意订阅的人不多，但这些人往往是你最活跃的一批用户，成本几乎为零。

两条别踩的线

第一条，别在日志里写内部安全细节。后台路径改了、某个接口的鉴权方式换了，这些事值得记，但不值得公开记。真出了安全事故，公告该单独写，措辞和范围都要单独权衡。

第二条，别把它当路线图。写上去的「即将支持」会被当成承诺，做不出来的时候比不说更尴尬。要做路线图就单独开一页，明确标上是计划不是承诺。

最后一件事：写了就别打自己脸。页面上写着「每月核对一次」，就得真有对账记录；写着「付费不影响排序」，后台就不能有隐藏的付费加权。这类页面一旦被发现言行不一，损失的可信度比不做它大得多。