给静态博客添加文章，看起来只是增加一个 Markdown 文件，再运行构建。移除文章却不一定是同样简单的反向操作：如果构建只生成新文件，没有清理旧文件，旧文章即使已经从首页消失，仍可能通过原网址打开。
这个问题正好出现在本站移除最初的三篇示例文章时。下面记录实际调整，以及为什么发布检查需要覆盖多个入口。
源内容和生成内容是两份东西
本站的源内容保存在 content/posts/，生成后的文章页位于 public/posts/。构建器最初只负责写文件：读取当前文章，更新首页、归档、详情页和 RSS。
这种方式可以正确添加和修改文章，却不会自动删除已经退出文章集合的目录。源文件被移走以后，旧的 index.html 仍然留在公开目录里。
因此，“首页没有这篇文章”和“这篇文章已经下线”是两种不同状态。后者还需要直接检查原来的详情页地址。
清理放在生成成功之后
现在的构建脚本会收集本轮所有文章的 slug，完成页面生成后，再扫描 public/posts/，移除不在当前集合中的文章目录。
处理关系可以概括为：
读取并校验文章
↓
生成首页、归档、详情页和 RSS
↓
用当前 slug 集合核对公开文章目录
↓
清理已经退出集合的旧文章页把清理放在后面，可以避免在文章解析阶段就先删除旧页面。不过当前构建仍直接写入公开目录，不提供整站更新的事务保证。若生成中途失败，仍可能出现部分文件已更新的状态；要进一步解决，需要引入完整构建目录和发布切换。
初始示例文章的源文件被移到 content/drafts/ 留作本地备份，这个目录不会被文章扫描器读取，也不位于 Web 服务的公开目录中。
各个入口分别检查什么
内容变更后，可以按访客实际使用的入口检查：
- 首页：文章数量、标题、作者署名是否一致？
- 分类和搜索：新内容能否找到，已移除内容是否还出现在结果中？
- 归档：文章集合是否与首页相同？
- 详情页：正文是否完整，引用链接和代码块是否正常？
- 旧网址：已下线文章是否返回 404，而不是继续显示旧正文？
- RSS：条目是否更新，链接是否使用正确的站点地址？
其中，作者署名和联系方式也属于内容发布的一部分。只更新首页卡片，会让文章页和关于页继续保留旧信息；集中读取配置，可以减少这种不一致。
返回 200 之后，还要检查正文
HTTP 200 只能说明某个地址成功返回了内容，不能证明返回的是最新内容。代理缓存、指向另一份目录的服务，或者不同机器上的部署，都可能让读者看到旧页面。
如果本机页面已经更新，外部检查却仍然看到旧文章，下一步应该比较实际访问网址、页面标题、文章数量和一段新正文，再检查服务对应的部署目录与缓存。继续修改本地文案，并不能自动修复访问入口指向错误的问题。
对于域名申请，也应当先验证一个已经可达的站点地址。计划申请的域名还没有完成解析时，不能用它代替实际网站预览地址。
把发布结果写得可核对
一次有用的更新说明，可以写明保留了哪些文章、移除了哪些旧网址、修改了哪些个人信息，以及检查了哪个访问入口。
如果只验证了本机服务，就明确说验证范围是本机；如果公网地址经过检查，再补充对应地址和结果。这种说明比一句“已经上线”更容易帮助下一位检查者定位差异。
静态博客的维护成本确实很低，但源文件、生成文件和访问入口之间的关系仍然需要认真处理。把这些关系写清楚，后续更新就更容易重复，也更容易发现哪里没有同步。