昨天的新文章在中日文页面都能打开，首页也出现了入口。按通常的发布检查，这件事已经结束。今天再看，却发现日文文章页的页脚仍写着旧子域名 jp.gumi.ink；当前日文入口其实是 gumi.ink/ja/。仓库里的维护说明也还在讲另一套发文频率和部署命令。

这些文字不会让构建失败。它们甚至不一定让当前页面返回错误码，却会把读者或下一位维护者带向过期的方向。这是小网站很容易积攒的一类故障：程序照着指令运行，指令本身却不再描述现实。

三种旧信息，三种处理方式

仍在使用的页面文字要改。 页脚虽然短，却会出现在许多文章、列表和标签页上。旧地址留在那里，等于网站每天都在重复一次错误的自我介绍。这次我把日文页面模板里的旧域名改为当前主域名，也修正了两篇旧文章结尾指向日文版的链接，让它们直达对应文章。

会指导操作的说明要重写。 一份 README 如果还教人按旧路径复制构建产物，即使写得很完整，也不适合继续充当恢复指南。与其在原文上补几个脚注，不如把当前的文章位置、构建命令、推送与部署顺序重新写清楚。维护说明的价值，不在于保留每次迁移的痕迹，而在于下一次需要它时能照着做。

历史方案要标日期，而不是伪装成现状。 仓库里有一份旧的日本推广计划。它能说明当时如何思考日文站，直接删除会失去这段背景；但若不标明旧子域名和提交状态尚未复核，也容易被当作今天的待办。我给它加了醒目的历史说明，留下资料，同时收回它对当前部署的指导权。

我怎样找这些偏差

第一步不是大规模替换，而是列出可能过期的“假设”：旧域名、旧目录、旧命令、旧发布频率。用文本搜索找到它们出现的位置，再逐一问：这是读者仍会点击的链接、维护者会执行的步骤，还是仅供回看的历史记录？同一个字符串，位置不同，处理方式也不同。

第二步才是验证现在的入口。看站点的导航和实际公开页面，再检查具体 URL 能否访问。不要因为某个地址看起来像正规域名，就假定它会自动跳转；也不要只因为构建通过，就假定页面写的内容仍然正确。

最后分两次检查：本地构建确认页面能生成，部署后从公网打开文章和首页确认改动真的到达读者。绿色的构建结果回答的是“能否生成”，公开页面回答的是“用户看到了什么”。两者都必要，也都不能替代对文字本身的判断。

这次排查只覆盖了发现的旧地址与说明，不代表整个站点从此没有陈旧信息。小网站的维护也许就是这样：新文章之外，偶尔停下来，纠正它正在说的关于自己的话。