服务器过载、重启或临时维护时，抓取请求往往会集中撞上同一个时间窗口。这时怎么回应蜘蛛，会直接影响它接下来是否继续抓、隔多久再来，以及会不会把暂时状态误判成永久问题。
503 和 500 不是一回事
500 表示服务器内部错误，通常意味着代码或配置出了问题，蜘蛛很难判断下次重试是否有意义。503 表示服务暂时不可用，语义上更接近“现在不行，稍后可能可以”。
如果站点只是短暂过载，返回 503 比返回 500 更准确。搜索引擎看到 503 时，一般会把它当作临时状态，减少或暂停对当前 URL 的抓取，过一段时间再试。但这不是保证，长期 503 也可能被当作不可用。
Retry-After 告诉蜘蛛等多久
503 响应里可以带 Retry-After 响应头，值可以是秒数，也可以是 HTTP 日期。它表达的是“建议在这个时间之后再来”。蜘蛛不一定完全遵守，但相比没有任何提示的 503，它多了一个恢复时间参考。
例如服务器预计维护十分钟，可以返回 503 和 Retry-After: 600。如果维护窗口不确定，不要随便写一个很小的值，否则蜘蛛可能很快又回来，继续加重负载。
不要用 503 掩盖其他状态
有些站点为了减少抓取，会把本该 404 的页面返回 503，或者把空页面返回 200。这两种做法都会让蜘蛛对站点状态产生错误判断。404 应该保持 404，503 只用于真实的临时不可用。
另外，如果某个频道长期返回 503，蜘蛛可能逐渐降低访问频率，甚至暂时不把它当作可抓取入口。恢复之后，抓取路径需要重新被确认，内链和 Sitemap 里的入口可以帮上忙。
与 429、Crawl-delay 的区别
- 429：请求过多，通常针对单个爬虫或来源，表示“你太快了”。
- Crawl-delay：写在 robots.txt 里，属于长期限速约定，不是实时回应。
- 503 + Retry-After：服务器端临时不可用，表达“整个服务现在处理不过来”。
三者可以配合，但不要混用。把 429 写成 503，蜘蛛可能会按临时故障处理，而不是按抓取频率调整。
维护窗口中的几个实用做法
- 计划维护提前准备 503 页面，并带上合理的 Retry-After。
- 不要返回 200 的“维护中”空页面，这会让蜘蛛把空内容当成正常页面。
- 监控抓取日志里的 503 比例，恢复后观察蜘蛛是否重新访问关键入口页。
- 如果只是部分接口过载，尽量缩小 503 的范围，不要全站返回。
503 是临时信号，不是长期挡抓取的工具。用错状态码，蜘蛛看到的是另一套站点状态。
服务器稳定性是抓取路径的基础。蜘蛛愿意按路径往前走，前提是每一步都能得到明确回应。过载时给出准确的 503 和 Retry-After，比直接断开连接或返回模糊的 500 更容易让后续抓取回到正轨。