503 和 500 在蜘蛛眼里不是一回事
503 表示服务器暂时无法处理请求，通常来自维护、过载、上游超时。500 表示服务器内部错误，蜘蛛也会视为暂时性故障，但 503 带有明确的临时含义，配合 Retry-After 能告诉蜘蛛什么时候再来。蜘蛛遇到 503 一般不会立刻把页面从索引里删除，而是降低该 URL 的抓取优先级，等一段时间再试。
Retry-After 怎么写，蜘蛛才愿意等
Retry-After 可以写秒数，也可以写 HTTP 日期。写秒数更直观，例如维护预计 20 分钟，写 1200 比写一个遥远的日期更容易被执行。写得太短，蜘蛛可能很快再来，继续撞上 503；写得太长，蜘蛛可能把这次抓取排到很后面，恢复后也不会立刻回来。
- 维护窗口 10 分钟：Retry-After 写 600 左右，留一点缓冲。
- 维护窗口数小时：写 3600 或按实际时间，不建议写几天。
- 不确定结束时间：不要写一个夸张的数值，宁可写 3600，并在维护结束后尽快恢复 200。
需要说明的是，Retry-After 是建议而非强制，不同蜘蛛的执行细节不完全一致。它能减少无意义的重复请求，但不能保证蜘蛛一定按这个时间回来。
长时间 503 会带来什么
如果站点连续几天返回 503，蜘蛛会逐步降低抓取频率。一开始可能只是减少对同一路径的访问，时间再长，部分 URL 的抓取会被推迟，新 URL 的发现也会变慢。恢复 200 之后，抓取频率通常不会瞬间回到原来的水平，而是随着多次成功响应慢慢回升。
这也是为什么维护窗口要尽量短。如果只是某个接口或某个目录出问题，不要全站返回 503，只让受影响的部分返回 503，其余页面保持正常，蜘蛛还能继续抓取其他内容。
维护页返回 200 是个常见的坑
有些站点在维护时把首页或全站都指向一个“系统维护中”的页面，但 HTTP 状态码仍然是 200。对蜘蛛来说，这等于告诉它“页面正常，内容就是这个维护页”。结果可能是蜘蛛把原来的标题、描述和正文替换成维护页内容，等维护结束后再改回来，又要等一轮重新抓取。
正确做法是让维护页返回 503，并在页面上说明预计恢复时间。不要用 200，也不要用 302 跳到一个临时地址，除非这个跳转是长期策略。
全站 503 时，Sitemap 和内链怎么办
维护期间 Sitemap 可以继续可访问，也可以暂时返回 503，但不要返回 404。内链结构不需要改动，蜘蛛恢复后仍然会沿着原有路径走。如果维护期间正好有新页面要上线，最好等站点恢复 200 之后再提交或放出内链，避免新 URL 第一次被抓取就吃到 503。
如果你运营多个站点，同服务器上的站点同时 503，蜘蛛看到的是同一批 IP 持续不可用，抓取压力的恢复会更慢。维护时间尽量错开，或者把不同站点放在不同的资源池里。
恢复后的检查清单
- 确认全站关键 URL 返回 200，而不是 503 或 500。
- 检查 robots.txt 没有误屏蔽，也没有临时写下的 Disallow 规则忘记删。
- 在抓取日志里观察 503 比例是否下降，200 响应是否回升。
- 重新提交 Sitemap，让蜘蛛知道内容已经可用。
- 如果维护期间改动了 URL，确认 301 映射正确，不要让旧链接直接 404。
- 保持服务器稳定一段时间，避免恢复后立刻再次过载。
蜘蛛的抓取节奏受很多因素影响，503 只是其中一个信号。把维护窗口做短、状态码写对、恢复后保持稳定，通常比反复提交 URL 更有用。
提示：503 不是屏蔽手段。想长期阻止抓取，应该用 robots.txt 或合适的鉴权状态码，而不是让蜘蛛一直撞 503。
小结
服务器稳定性直接影响蜘蛛的抓取安排。503 配合合理的 Retry-After，能让蜘蛛知道这是临时情况；维护页返回 200，或者长时间全站 503，则可能让抓取频率回退得更明显。恢复后，给蜘蛛一个稳定、可访问、内链清晰的站点，抓取节奏会慢慢回来。