网站迁移公告写不好，客户以为你跑路了

公告这种东西，写的人当它是走流程，看的人当它是救命信息。你可能只是把站点从一台机器挪到另一台，后台点一下，剩下的交给运维；客户那边看到的是网站打不开、订单页报错、收藏夹里那个链接变成一片白。这时候他找不到解释，脑子里冒出来的第一个念头不是“你在搬家”，而是“这伙计是不是不干了”。网站迁移公告没写好，麻烦就是从这儿开始的。

网站迁移公告是写给谁看的，先想清楚

我见过太多公告写成内部备忘录——“因业务调整，服务器将进行迁移”，完了，谁看完都一头雾水。动手之前不妨把读者列一列。一拨是天天用的老客户，他们只关心能不能登录、资料还在不在、什么时候恢复；一拨是搜索引擎的爬虫，它读不懂情绪，只认状态码和可访问性，迁移期间返回什么状态、大概持续多久，这些要按搜索引擎官方给出的抓取说明来处理；还有一拨是你自己的客服和同事，公告就是那几天统一对外的口径，省得客户一问，三个人给出三种说法。

三拨人关注点不一样，但有两句话是共通的：现在什么情况，什么时候能好。把这两句说明白，细节少写点也没事。反过来，通篇客套话却不给时间点，读的人只会更慌。

时间别写“今晚”，写清楚区间

“预计今晚完成迁移”——坑就在这个“今晚”，几点到几点？客户在别的时区怎么办？到点了还没好，他会不会觉得你在糊弄？我一般会建议写成一个带日期的区间，像“10月20日 23:00 至 10月21日 03:00（北京时间）”，后面补一句“若提前完成，会在本页更新进度”。给自己留缓冲，比把话说死体面。真赶不上计划，临时加一条进度更新，也比连夜解释省事。

还有个动作值得提前几天做：把域名的 TTL 调低，切换之后生效会快一点。具体调到多少、什么时候调回来，各家解析服务商的默认值不太一样，以服务商或官方页面的说明为准。

把“你会看到什么”提前列出来

用户最慌的不是遇到报错，是不知道这个报错正不正常。所以网站迁移公告里最好直说：这段时间可能碰到登录掉线、页面加载慢、图片刷不出来、下单失败这几种情况，遇到不用反复提交，等恢复了再试就行。

措辞越具体越好，别写“可能对部分用户造成一定影响”这种话。写“图片可能刷不出来”，用户一眼就知道自己遇到的是不是同一个问题。

别只在一处发公告

公告页做得再漂亮，藏在只有你自己知道的内页里，等于没发。一般我会铺几个入口：页面顶部一条横幅、首页弹窗（能关，但下次访问还出现）、站内消息或者邮件通知、客服的自动回复和话术。用户群体大的，公众号或者短信也算一条。平时用户从哪儿进站，你往哪儿放，别指望他自己去找。

迁移完之后那条公告，比迁移前还重要

很多人的公告只发一条“我们要迁移了”，然后没了下文。站点恢复了，公告还杵在那儿，用户第二天上来一看，还以为又出事了。

恢复之后应该补一条收尾公告：迁移已完成、完成的大致时间、哪些功能恢复正常了、还有异常去哪儿反馈。这条对搜索引擎和用户都算一个“站点还活着”的信号。迁移前那篇公告也别急着删，改成历史记录，或者加个“已完成”的状态，给后来翻到的人一个上下文——半年后还有人从搜索里点进来，迎面一句“即将迁移”，那场面挺尴尬。

我见过翻车的几种写法

一种是写成甩锅信，“因机房原因导致服务中断”，用户看不懂也不想懂。一种是细节错得离谱，日期写错、域名写错，月份写串尤其要命。还有一种是话说太满，写“绝不影响访问”——迁移期间完全不影响基本做不到，这种话等于提前埋好一个被打脸的坑。最后一种是发完没人管，评论区问了一屏也没人回。公告不是一发了事，它是那几天唯一的沟通窗口。

数据这块也一样，能说的是“迁移前已做完整备份，保留周期以服务商的备份策略为准”。自己站点有备份方案的，把保留时间和恢复方式写清楚，比一句“数据绝对安全”让人踏实。

发布前顺手过一遍这几项

时间区间（带日期和时区）、影响范围、用户可能遇到的报错列两三条、反馈入口给一个（邮箱、工单、客服都行）、TTL 和备份动作提前做、发布入口至少铺三个、恢复后补一条收尾公告。不用写得多漂亮，逐条落到文字里就够了。

迁移是技术活，公告是沟通活。技术做对了，站点能回来；沟通做对了，人才会回来。下次动手之前，把你写好的那段公告读一遍——你自己看完都不知道什么时候能好，客户就更不知道了。