蜘蛛每次抓取一个 URL，服务器返回什么状态码，是它判断这个站点当前状况最直接的依据。它不只看“能不能拿到内容”，还会根据状态码调整对这个 URL、这个目录甚至整个站点的抓取节奏。理解这一层，能解释不少“为什么蜘蛛最近来得少了”的现象。
200 与 304：正常路径
200 表示内容正常返回，304 表示内容没变、蜘蛛省下传输成本。这两类响应不会给抓取带来负面信号。需要注意的是 200 页面本身的体积和响应时间，那属于另一个话题，这里不展开。
404 与 410：一个“没找到”，一个“已删除”
404 是“现在没找到”，410 是“已经明确删除”。对蜘蛛来说，410 的信号更干脆，它会更早停止对这个 URL 的尝试，也不会再把它当作有效入口。404 则不同，如果同一个 URL 长期返回 404，蜘蛛会在一段时间内反复回来确认，这段反复本身就是抓取浪费。
更麻烦的是软 404：页面返回 200，但正文是“该商品已下架”“找不到该页面”。蜘蛛拿到 200，会按正常页面处理，甚至可能把它当成有内容的页面留在索引里。该用 404 或 410 的地方，不要用 200 兜底。
什么时候用 410 更合适
- 内容确定永久删除，不会再恢复
- 批量下架、整个栏目撤掉
- 你希望蜘蛛尽快停止访问，而不是继续回来确认
403 与 401：别把“拒绝”当成“删除”
返回 403 或 401，并不等于告诉蜘蛛“这个页面不存在”，它只说明这次访问被拒绝，蜘蛛可能改天再来试试。如果因为防火墙规则、UA 拦截、地区限制导致蜘蛛拿到 403，长期看会表现为抓取量下滑，而你在页面上看不出任何异常。
排查抓取问题时，先看蜘蛛拿到的状态码分布，再看页面本身。很多“页面没问题但抓取变少”的情况，原因其实在响应层。
5xx：服务器不稳定时蜘蛛会自己降速
500、502、503 属于服务端临时故障。蜘蛛遇到这类响应，通常会减少对本站的抓取频率，过一段时间再逐步恢复。这本身是一种保护机制，但恢复速度取决于故障持续了多久——短时间抖动影响有限，连续几天大面积 5xx，抓取量可能几周才回到原来的水平。
503 可以配合 Retry-After 响应头，明确告诉蜘蛛“多久之后再来”，比让它自己猜更省事。计划内维护、临时限流都可以用这个方式。要注意 Retry-After 的时间不要设得太短，否则蜘蛛回来后仍然撞在故障上，反而把降速期拉长。
怎么从日志里看清状态码分布
- 按蜘蛛 UA 过滤出抓取日志
- 按状态码分组统计请求数
- 把 404 和 5xx 的 URL 单独列出来，看是否集中在某类模板或某个目录
- 对照同一时间段的服务器监控，确认 5xx 是蜘蛛引起的还是全站性问题
如果 404 集中在参数页、已下架商品这类可预期的位置，考虑用 robots.txt 或 noindex 收敛，而不是放任蜘蛛反复访问。
几个容易踩的坑
- 把 404 全部重定向到首页：蜘蛛看到的是 200 加首页内容，容易把大量无关 URL 当成首页的重复版本
- 出错时统一返回 200 的错误页：蜘蛛无法判断页面是否有效
- 长期 5xx 不做处理：抓取频率下降后，恢复需要时间
- 用 403 屏蔽蜘蛛：这和主动告诉它“别来”不是一回事，效果并不稳定
状态码是站点和蜘蛛之间最基础的一层沟通。返回得准确，蜘蛛的判断就准确；返回得含糊，它只能靠反复试探来确认，而试探的成本最终会体现在抓取效率上。