站点维护期返回503并写明恢复时间，抓取方会怎么处理

维护或过载时返回503并给出恢复时间，抓取方读到的是「临时不可用」这一层语义：它通常会把已经收录的地址保留一段时间，按响应里给出的恢复时长稍后重试，而不是把地址判成失效。真正把维护期做坏的两件事，是把这类响应缓存下来，或者把维护页压成 404、403 这类语义完全不同的码。

503 表达的到底是什么

它对应的是服务临时无法处理请求，而不是内容不存在。升级窗口、流量突发、依赖的数据库暂时无响应，都属于这一类。语义上它和「页面被删了」「禁止访问」是三种不同的事实，混用会让读取响应的一方做出错误的长期决定：误判成失效会掉收录，误判成禁止访问会停止抓取节奏。

也正因为它是临时状态，规范口径要求把恢复的估计时间写在响应头里，能给出就给出。抓取方与监控工具据此安排下一次访问，运维也据此判断维护窗口是否超时。

恢复时间该由哪一层给出

恢复时间只有一个来源才有效：要么由程序在返回维护页时写，要么由承担维护的那一层网关统一写。两处都写时，读到的往往是最后经过的一层，排查时容易归错因。

常见分工是这样：整站挂维护页时由网关层统一拦截并给出时长；只有部分功能降级时由程序给出，此时要把「哪一段不可用」写在响应体里，而不是笼统地给整站打临时码。给出的时长要略大于计划窗口，留出入场重试与队列消化的余量；写得太短会让重试挤在恢复瞬间发生。

为什么这类响应通常不该缓存

文档口径很明确：临时问题的响应通常不该被缓存，否则修复上线之后，访客和抓取方还会从缓存里读到旧的错误页。这就是维护期最常见的收尾事故——服务已经恢复，页面却仍在展示维护说明。

落地上要注意三点。第一，维护响应本身带上不缓存的指示，别让它进入共享缓存。第二，正常页面的缓存要按内容分开处理，静态资源可以继续用带版本号的地址，正文页则在维护窗口结束后统一刷新。第三，如果前面有内容分发层，恢复动作要在那一层也执行一次，只清程序侧的缓存往往不够。

收录链路上要连带核对的哪三处

先看站点地图。站内用的是自动生成，维护窗口里要确认它是否还在按旧数据输出：如果抓取方在恢复后的第一时间里读到的仍是过期条目，重抓的优先级会被拉低。窗口结束后重新生成一次，比手动补抓更稳。

再看跳转表。站内有重定向管理，维护期不要临时加永久跳转。永久码一旦被读到，原地址的权重迁移就按长期处理，回退的成本比维持临时码高得多。需要引导时用临时语义，窗口结束即撤。

最后核对返回口径的一致性：首页、列表页、详情页这三类入口在维护期是否给同一个码、同一个恢复时长。三类不一致时，抓取方会把部分路径当成正常可用，抓回一堆维护页内容。

常见问题

维护页给 503 会不会影响已有收录？ 临时语义本身不会把地址判成失效，关键是别让它被缓存成长期事实，也别用永久码替代。

恢复时间写多久合适？ 按计划的窗口再放宽一段，避免重试集中落在恢复的那一分钟；实际超时后要更新说明，不要让响应里的时长长期失真。

只挂静态首页做维护行不行？ 行，但要保证所有路径都走同一套判断，否则接口与详情页可能返回半套数据，反而更难排查。

维护结束后还要做什么？ 重新生成站点地图、撤掉维护拦截与临时跳转、抽查三类入口的实际返回码，并确认缓存层里没有残留的错误页。