网站维护中怎么设置？别把蜘蛛挡门外

做站这些年，最怕的不是网站出故障，而是出故障时手忙脚乱，顺手把搜索引擎也一起挡在了门外。很多人一听到网站维护中，第一反应就是丢个提示页上去，或者干脆在 robots.txt 里全站禁止抓取，觉得等活儿干完再撤掉就行。结果维护结束，蜘蛛回来一看，站点像是长期关门歇业，收录掉得比谁都快。这篇不聊虚的，就把维护模式怎么设、状态码怎么给、后台怎么保住、蜘蛛怎么别得罪，一条条给你摆清楚。

先分清：维护期间访客和蜘蛛看到的不该是同一套东西

网站维护中的本质，是告诉外界“这站还活着，只是暂时不接客”，而不是“这站没了”。想清楚这一点，后面所有配置都是围着它转的。访客打开页面，看到的应该是一个干净的维护提示，最好写清大概多久恢复、急事怎么联系；蜘蛛爬过来，收到的则应该是一个明确的临时不可用信号。这两件事必须分开处理，混在一起就会出现更隐蔽的麻烦：维护页返回 200，蜘蛛把“本站正在维护”当成首页的新内容抓走，站点恢复之后，搜索结果的标题和摘要还挂着那句提示，用户点进来才发现早就好了，白白损失点击，而这个覆盖过程少则几天，多则几周。

为什么要用 503，而不是 200 或者 404

HTTP 状态码是给程序看的语言，用错了，蜘蛛就会理解错。页面返回 200，意思是内容没问题、放心收录；返回 404，意思是这个地址永久没了；只有返回 503，才是在说服务暂时不可用、过会儿再来，维护场景要的正是最后这一个。503 属于临时性状态，蜘蛛一般不会因此删掉索引，还会参考你给的等待时间择日再来。判断标准记牢：临时维护给 503，永久下线给 404 或者 410，这两件事别弄反。当然 503 也不是万能挡箭牌，站点长期挂着不恢复，蜘蛛的耐心照样会耗尽，所以维护窗口尽量压缩，能半夜做就别挑白天，能在测试环境改完再推上去，就别在生产环境上边改边等，真要几天的大工程，宁可拆成几批，每次影响控制在半小时以内。

Nginx 里把维护页配成 503 的完整写法

Nginx 下的做法很朴素。先在站点目录放一个自己写好的维护页，命名成 maintenance.html，然后在 server 段加一段判断：访问者不是你的固定 IP 时，让它走 error_page 503 /maintenance.html; 这一条，同时用 add_header Retry-After 3600; 附上等待时间，最后用 return 503; 把状态码真正吐出去。这三件事缺一不可，尤其是最后那句，不少人只做了跳到维护页的动作，却没给出 503，等于白设一场。改完别急着重载，先跑一遍 nginx -t 验证语法，通过了再执行 nginx -s reload。这个顺序不能反，语法错了强行重载，轻则网站短暂打不开，重则老进程被顶掉，小维护直接演变成真故障。

配置上线前，这几个细节挨个核对一遍

白名单是为了让你自己在维护期间还能正常访问和测试，判断条件一般写成 $remote_addr 不等于你的固定 IP 就跳维护页。提醒一句，如果你用的是手机流量或者动态 IP，白名单可能一刷新就失效，与其反复改配置，不如临时用 hosts 文件把域名指到另一台机器上测试。另外还有三件事要核对：维护页最好是纯静态文件，别依赖数据库，万一你正在升级的恰好是数据库，维护页自己先打不开就成了黑色幽默；配置要加在 server 段而不是 http 段，加错位置会连累同一台机器上的其他站点；站点前面挂了 CDN 或者反向代理时，真实访客 IP 可能要取 X-Forwarded-For 里的值，否则白名单拿到的是一串机房 IP，谁都对不上号。

Retry-After 到底写多少秒合适

Retry-After 的值单位是秒，写 3600 就是一小时，写 7200 就是两小时。写多少取决于你预估的维护时长，宁可比实际长一点，也别写得太乐观：写少了，蜘蛛按点回来发现还在维护，多跑两趟它就不那么勤快了；写多了，站点恢复之后它可能真要等那么久才回来。我的习惯是按预估时间再放宽一半，半小时的活儿写 2700，两小时的升级写 7200，基本都能对上。顺便说个常见误区，这个头管的是“什么时候再来”，跟“内容多久过期”是两码事。有人把它和缓存策略混着用，给维护页设了很长的缓存，结果站点恢复了，CDN 还在给访客发维护页，用户以为网站一直没好，维护期间把维护页缓存设短，恢复后主动刷一次 CDN，别让缓存替你多关几小时门。

WordPress 站点：让维护页只挡访客、不挡后台

用 WordPress 的朋友有更省事的办法。系统自带一套维护机制：站点根目录出现 .maintenance 文件时会进入维护状态，如果 wp-content 目录下放着 maintenance.php，它会优先用这个文件渲染维护页，没有就走默认提示，所以想自定义页面，把 maintenance.php 放进 wp-content 最稳。有些主题也会在自己目录里读取同名的 maintenance.php，具体加载哪个以主题说明为准。懒得动文件就装个维护模式插件，这类插件通常给一个开关和编辑内容的输入框，还能设放行规则，让你登录状态下照常浏览全站，访客才看到维护提示，后台该进还是能进。挑插件要挑最近还在更新的，关掉后顺手清一次缓存，免得维护页被缓存住不肯走。

踩坑最多的操作：拿 robots.txt 做全站 disallow

这是我最想拦着你的一个动作。资源平台里确实有生成 robots.txt 的入口，填两下就能写出 Disallow: /，看着方便，后果却不小。它的含义是禁止抓取整个站点，而不是暂时别来看，规则一旦上线又被蜘蛛读到，全站抓取就会停下来；等你维护完撤掉规则，蜘蛛也不会立刻知道，它得重新读到新的 robots.txt 才可能恢复抓取，中间这段空窗期短则几天长则几周，收录和排名都跟着抖。更要命的是，它只能阻止抓取，阻止不了已收录的页面继续出现在搜索结果里，等于你既没解决蜘蛛看到维护内容的问题，还给自己埋了颗收录掉队的雷。想阻止访问某个地址用 robots.txt，想说明站点暂时不可用用 503 加 Retry-After，这俩别拿一把钥匙去开两把锁。

维护结束后的收尾：撤规则再跑一次抓取诊断

活干完别急着关电脑，收尾这几步才决定收录受不受影响。第一步，撤掉维护配置，把 return 503 那段整段删掉，重新跑 nginx -t 和 nginx -s reload，再用 curl 或者浏览器确认首页返回的是 200，别只看页面能不能打开，状态码才是蜘蛛真正关心的东西。第二步，维护期间动过 robots.txt 的话，确认它已经是正常版本，别留着半截旧规则。第三步，去搜索引擎的资源平台跑一次抓取诊断，把首页地址提交上去，看返回码是不是 200、抓取是否成功，入口位置和提交次数以官方页面说明为准。主动模拟蜘蛛跑一遍，比干等它哪天路过踏实得多。第四步，首页、栏目页、文章页各抓一个，确认没有残留的维护提示，再看一眼 sitemap 输出是否正常。

捋一遍重点：网站维护中要的是一个临时不可用信号，Nginx 里把维护页配成 503 并带上 Retry-After，等于告诉蜘蛛过会儿再来；WordPress 站用 wp-content 下的 maintenance.php 或者维护模式插件，做到只挡访客、不挡后台；最不该做的就是拿 robots.txt 全站禁止抓取来维护，那等于把门焊死，恢复起来费劲得多；维护一结束，撤干净规则，去资源平台跑一次抓取诊断，确认蜘蛛能正常进门。维护是暂时的，收录掉下去想爬回来可就慢了，这几步花不了几分钟，做与不做差别很大。