本文约 2,487 字，预计阅读 7 分钟。文中命令与配置均经过实测，可直接参考执行。
引言：关站两小时，还是关站两周，结果完全不同
站点不可能永远在线：换服务器、升级 PHP、数据库迁移、插件冲突导致白屏，都需要短暂关闭。站长真正担心的不是这几小时的流量损失，而是百度蜘蛛恰好在这段时间来抓，发现站点打不开，于是降低抓取频次甚至降权。这个担心是否成立，取决于你关站期间返回给爬虫的是什么状态码。
原理分析：百度怎么理解”打不开”
| 关闭方式 | 返回状态 | 百度的理解 | 对收录的影响 |
|---|---|---|---|
| 规范维护页 | 503 + Retry-After | 临时不可用，稍后再来 | 基本无影响 |
| 直接停服务 | 连接超时/502 | 站点不稳定 | 短期抓取频次下降 |
| 关闭页返回 200 | 200 | 内容变更 | 可能被当成新内容收录，原有页面丢失 |
| 整站返回 404 | 404 | 页面已删除 | 收录快速流失 |
| 长期关闭（数周） | 任意 | 站点失效 | 权重与收录大幅流失 |
503 的语义就是”服务暂时不可用”，它是 HTTP 协议里专门为这种情况定义的状态码。配合 Retry-After 头部告诉爬虫多久之后重试，百度会把这次访问记为一次普通的临时失败，而不是页面消失。
判断阈值没有官方公布的数字，但实践经验是：几小时到一两天的规范 503，几乎不影响收录；超过一周的不可访问，抓取频次会明显下降，恢复后需要数周才能回到原来的抓取水平；超过一个月的关闭，基本等同于站点废弃，收录会大量流失。
保姆级实操
步骤 1：维护期间返回 503，而不是 200 或 404。 在 nginx 层做，比在应用层做更可靠：
# 维护期间：对普通访问与百度蜘蛛统一返回 503 + Retry-After
server {
listen 80;
server_name mimangfei.com;
error_page 503 @maintenance;
location @maintenance {
root /var/www/maintenance;
rewrite ^(.*)$ /503.html break;
add_header Retry-After 3600 always;
add_header Cache-Control "no-store, no-cache, must-revalidate" always;
return 503;
}
location / {
if (-f /var/www/maintenance/.on) {
return 503;
}
try_files $uri $uri/ /index.php?$args;
}
}
Retry-After 用秒数（这里是 3600）或 HTTP 日期都可以，值要接近你预期的恢复时间，不要随便填 86400 却半小时就开站。
步骤 2：WordPress 自带的维护模式要会用。 核心升级期间，WordPress 会在根目录生成 .maintenance 文件，wp_maintenance() 会发送 503 状态码与 Retry-After: 600 头部，并展示维护页。这是核心行为，不需要额外配置。需要注意的是：如果维护时间超过预期，要检查 .maintenance 是否被残留——升级失败后它不会自动删除，站点会一直卡在维护页。手动删除即可恢复。
步骤 3：维护页本身要有信息量。 503 页面里写清”预计恢复时间”和临时联系方式，别只写”网站维护中”。如果用户在这期间访问，至少知道什么时候再来。
步骤 4：避开抓取高峰做维护。 从访问日志里统计 Baiduspider 的来访时间分布，挑它来访最少的时段操作：
# 统计最近 7 天百度蜘蛛按小时的抓取分布，挑低谷期做维护
zcat -f /var/log/nginx/access.log*.gz 2>/dev/null | \
grep -i "Baiduspider" | \
awk '{print substr($4,14,2)}' | sort | uniq -c | sort -rn
步骤 5：开站后主动推送。 维护结束后，到百度搜索资源平台用「抓取诊断」抓一次首页，再用「资源提交 – API 推送」把核心 URL 推一遍，帮助百度尽快恢复抓取节奏。
步骤 6：观察恢复指标。 维护后一周内每天看一下「抓取频次」与收录量。如果抓取频次一周后还没回到维护前水平，可以用 API 推送和 sitemap 更新加快恢复，判断方法见 百度抓取频次下降排查。
常见踩坑
- 维护页返回 200，百度把维护页当成首页内容收录，原首页排名被替换。
- 返回 503 但没带 Retry-After，百度按默认节奏重试，恢复更慢。
- 维护页被 CDN 缓存成 200，爬虫拿到的是缓存的错误状态。
- 用防火墙把百度蜘蛛一起挡了，误判为攻击流量。
- 升级失败后
.maintenance残留，站点卡在维护页一整天无人发现。 - 案例： 某站在数据库迁移时把整站设为 404（运维习惯性配置了”站点不存在”的返回），三天后开站，收录量从 1.2 万掉到 6000 出头，花了近两个月才恢复到 1.1 万。同样的迁移如果返回 503，影响基本可控。
- 长期关闭期间不做任何公告，用户和爬虫都得不到恢复信号。
- 维护结束后不做推送，被动等待抓取，白白多花两周恢复期。
总结
一句话区分：几小时到几天的关闭，用规范的 503 + Retry-After，影响可控；一周以上的不可访问才会明显损伤收录。三条底线记住——维护页绝不返回 200、绝不返回 404、维护结束主动推送。计划内的维护还要提前看抓取时段分布，把影响压到最小。若是域名整体更换，处理方式另见 WordPress 域名迁移 301 设置。
