网站短时维护用503还是200？Retry-After与恢复检查要一起做

如果网站只是短时间维护，暂时无法提供原有页面，应返回503 Service Unavailable，并在可估计恢复时间时提供Retry-After。不要把所有产品URL改成返回200的“正在维护”，也不要临时加noindex或返回404来让爬虫停下。维护完成后，恢复正常正文、正确状态与缓存，比把维护提示页做得漂亮更重要。

先判断是否需要整站不可用

更换支付、暂停订单或调整询盘系统，不一定需要关闭全部产品资料。能保留公开说明、联系方式与普通导航时，应尽量缩小维护范围。只有确实不能安全提供原页面的部分，才使用暂时不可用响应。把业务暂停和网站完全下线混为一谈，会扩大搜索和用户体验影响。

Google关于暂时暂停网站的文档优先建议限制功能而不是完全停站；必须紧急停站一至两天时，可使用带503状态的说明页。这个时间范围不是“停满两天绝对没影响”的保证。维护越短越可控，恢复时间不确定时应重新评估能否保留可访问内容。

503和Retry-After分别表达什么

503表示服务器暂时不能处理请求。Retry-After表达预计多久后可重试，可用秒数或HTTP日期；它是对客户端的提示，不是指定Google在某个时刻重新抓取的预约。预计时间改变时，应更新提示，而不是长期保留已经过期的日期。

HTTP/1.1 503 Service Unavailable
Content-Type: text/html; charset=utf-8
Retry-After: 1800
Cache-Control: no-store

这里的1800秒只是教学示例，表示半小时，不是建议所有维护都设置半小时。页面正文应说明暂时不可用及合适的替代联系途径，不要暴露内部错误堆栈或维护凭据。即使有友好正文，HTTP状态也要真的返回503，不能仅在页面上印一个“503”。

MDN的503说明特别提醒临时错误响应的缓存问题。可以按实际架构设置不存储这类维护响应，并检查CDN错误缓存策略；源站的no-store并不代替对供应商规则的核对。否则恢复后用户可能继续拿到旧维护页。

不要用200、404或noindex替代短时维护

每个产品地址都返回相同维护提示且状态为200，会让响应语义与实际内容不符，Google也无法取得原产品资料。404和410表达资源不存在，noindex明确要求不把页面纳入索引，均不适合用来表示短期不可用。robots.txt禁止抓取也不能向访问者解释维护，更不能代替503语义。

Google文档还明确提醒，不要让robots.txt也返回503。它是影响抓取决策的特殊入口，应按其应有规则正常提供。实际维护开关常写成“所有路径一律503”，因此必须单独检查robots.txt，而不是假设静态文件自然不受影响。

如果维护涉及登录、后台或敏感资料，继续保留原有权限控制。面向公开页面的SEO处理，不是开放私有系统的理由；检查清单应区分公共访问、授权访问和管理访问，避免临时规则放大权限。

结束维护时，按访问者看到的结果验收

1. 关闭预定维护开关，检查原来的代表性产品页、分类页与首页是否返回正确正文，而不仅是HTTP 200。
2. 检查响应头不再保留临时Retry-After或意外noindex，重定向没有全部指向维护入口。
3. 清理仍在复用的维护缓存，再从公开域复查，不只访问源站或管理员预览。
4. 核对robots.txt、必要CSS和JS、图片及公开接口；页面恢复但资源继续不可用，仍不算完成。

如果公网依然显示旧响应，可以使用公网与源站响应对照的方法定位缓存层，虽然该教程以noindex为例，同样适用于维护页滞留的排查思路。清理对象和结果应记录，别为了单页恢复无差别清全站缓存。

开始之前就约定谁负责退出维护

计划里写清维护触发条件、预计窗口、检查URL、结束负责人和回退条件。结束负责人应能同时确认应用恢复与公开响应恢复，避免开发说“已经部署好”、运营却仍看到维护页。若多人轮班，交接的是当前维护开关和未完成检查，不是只转发开始通知。

代表性检查对象应覆盖实际不同处理路径：缓存命中的静态介绍页、需要回源的产品页、必要公开接口，以及robots.txt。支付或询盘功能恢复需另做功能验收，不能因为网页200就假设订单流程正常。反过来，业务接口暂时未恢复，也不一定要继续阻断全部公开知识内容。

保留维护前能工作的版本和可执行回退方案，由具备权限的人员在约定条件下操作。若某个变更只涉及局部功能，不应借维护扩大修改旧URL、追踪代码或站点索引策略。维护结束后的记录也应说明实际超过计划的时间及原因，而不是只保留最初预计值。

预计维护拖长了，不能只修改倒计时

按Google的HTTP状态说明，持续的5xx和429会降低抓取，长期不可用还存在索引移除风险。Retry-After不会给页面无限期保留索引。若发现维护无法如期结束，应优先评估恢复可用旧版本、保留公开资料或缩小停用范围，而不是让“稍后回来”挂上数周。

在光算的谷歌SEO服务项目中，可把上线前的维护方案、关键URL检查和恢复跟踪列入具体技术协作范围。对外能承诺的是按计划检查和处理可控问题，不是停机后某天必然恢复排名。维护记录应以真实开始、结束时间及公开响应为准，随后观察Google重新抓取和索引处理。