站点升级时挂维护页返回 503，为什么比返回空白页更稳妥

站点升级时挂维护页返回 503，比返回空白页稳妥，是因为它同时对三类对象说了清楚的话：对浏览器说「现在不行，稍后再试」，对搜索引擎说「这是临时状况，不要把我的页面判成失效」，对运维自己说「有一个明确的恢复时间要遵守」。MDN 的定义正是这个语义：该状态码表示服务器未准备好处理请求，常见原因是服务器在维护或过载；这一响应应仅用于临时状况，且 Retry-After 首部应尽可能包含服务恢复的预计时间。

这个状态码说的是什么

关键在于「临时」这两个字。503 表达的是当前无法服务，而不是资源不存在。这与其他几种返回形态的区别值得说清楚。

第二行与第四行是最容易误用的。「升级期间直接返回不存在」会被理解成内容被删除，恢复后需要重新建立对站点的判断；「返回空白页面」则会被当成内容变空，两者都可能造成长期影响，而修复时间远短于影响时间。

重试时间该给多少

文档要求 Retry-After 尽可能包含服务恢复的预计时间。实操上取一个略宽于预期的值更稳：宁可提前恢复后让访客早一点回来，也不要给一个短于实际的数值导致反复被重试。

三个判断要点。第一，时间应该来自你的发布计划，而不是随便写一个默认值；写短了会让客户端在维护未结束时不断重试，加重恢复瞬间的压力。第二，维护页本身要给出人可读的时间范围，与首部里的机器可读值保持一致，两处矛盾会直接损害可信度。第三，超出预计时间仍未恢复时，应当让维护页继续返回同一状态码，而不是回退到空白页。

维护页为什么不能缓存

文档对缓存有明确提示：这条响应伴随的缓存相关首部需要特别注意，因为它表示的是临时问题，通常不应缓存，否则修复后客户端可能收到过期的错误页。

这正是维护页事故里最常见的一种：站已经恢复，但共享缓存与加速节点上仍存着那份错误页，用户持续看到维护提示，而源站日志看起来一切正常。

处理上有两层要做。应用与部署层给出维护页响应时，带上不被存储的声明；恢复后主动刷新缓存层，而不是等对象自然过期。只做完第一层而不刷新，仍然可能残留已存对象；只做刷新而不加声明，则在缓存策略宽松的链路上仍会被存下。

另外，维护页不该带跳转。把不可用状态转成一次重定向，会让下游把它当作正常页面处理，也让恢复时间信息完全丢失。

升级窗口与站点地图、推送的先后

维护窗口不只是「让页面挡住访问」，还包括恢复后怎么把状态交还给抓取方。建议按这个顺序安排。

窗口开始前：先做一次备份。站内支持数据与静态文件的备份和恢复，升级出问题时可回退，这一步决定了后面所有操作是否可逆。

窗口期间：全站返回带恢复时间的不可用状态，站点地图的访问同样落在这一状态里，不要出现「页面不可用但站点地图仍可抓取并返回旧地址清单」的组合。

恢复瞬间：先确认源站正常响应，再刷新缓存层，然后核对站点地图内容是否为当前状态。站内支持站点地图自动生成，恢复后不需要手工重建文件，但需要确认它反映的是当前文档集合。

恢复之后：对窗口期间发布或改动的内容做链接推送，向搜索引擎主动提示新内容，加速重新抓取。主动推送的价值在恢复期尤其明显——它比等待对方按自己的节奏回访更直接。

如果升级同时改变了地址结构，跳转要在推送之前配置好。把大量旧地址直接留给抓取方判断，容易被当作内容消失；先设好重定向，再推送新结构，顺序反了会多做一轮无谓的解释。

容易被误用的几种做法

第一种是维护期间返回成功状态加一段提示文字。这会让下游认为页面正常，把维护提示当作内容收录。

第二种是维护页里写满业务文案与关键词。维护页应当极简，说明不可用原因与预计恢复即可。

第三种是不带恢复时间且窗口很长。超过数十分钟的不可用而不给任何时长提示，会显著提高重试与客服压力。

第四种是只在前台挂维护页，接口与后台入口照常可访问。这种半开状态容易造成数据写入与页面渲染不一致，升级时应统一收敛。

常见问题

维护页需要写原因吗？ 写一句即可，说明临时不可用与预计恢复时间。具体故障细节不必公开。

多久算太长？ 没有统一标准，但超过计划时间的维护应重新给出恢复预期，而不是让同一个时间值一直生效。

能不能只对用户挂维护页，对搜索引擎放行？ 放行时源站必须能正常渲染，否则抓取到的是半完成状态，比统一返回不可用更糟。

恢复后多久能回到正常收录节奏？ 取决于站点更新频率与回访节奏。主动推送能缩短等待，但不能替代站点地图与内容本身的稳定性。

维护期间订阅通知要不要停？ 建议暂停自动发送，避免通知里的链接指向不可用页面，恢复后再补发。