页面内容写得再完整，如果服务器在蜘蛛来的时候答不上话，收录流程也走不到下一步。抓取是收录的前置条件，而状态码、响应时间、连接是否稳定，决定了蜘蛛这一次访问是“拿到内容”还是“记一笔账下次再来”。
先分清两类“抓不到”
4xx 和 5xx 在蜘蛛眼里完全不是一回事。
- 404 / 410：地址确实没有内容，这是明确表态，蜘蛛会逐步把旧 URL 从索引中清理出去，410 比 404 更干脆。
- 5xx（500、502、503、504）：服务器自己出了问题，属于暂时性故障。蜘蛛通常不会因此判定页面消失，而是记为抓取异常，过一阵子再试。
把 5xx 当 404 处理，或者反过来，都会让索引状态变得混乱。比如一个临时维护的页面连续几天返回 500，蜘蛛不会立刻删掉索引里的旧版本，但如果拖得太久，抓取频次会被下调，页面更新也跟着延迟。
蜘蛛遇到 5xx 之后会做什么
多数搜索引擎对 5xx 采用“重试加退避”的策略：第一次失败后不会马上放弃，而是隔一段时间再试；连续失败则会拉长间隔、降低该目录的抓取配额。这个过程对站长不可见，你能看到的是日志里同一批 URL 反复出现 5xx，而索引里的版本停在几天前。
如果整站在某个时段集中返回 5xx，影响范围会从单个页面扩大到抓取预算——蜘蛛把时间花在等待超时上，真正该抓的新 URL 反而排到了后面。
超时和慢响应，比错误码更隐蔽
状态码至少会留痕，响应慢则容易被忽略。常见情况有：
- 首字节时间很长，蜘蛛等到超时就断开，日志里可能连完整状态码都没记下来；
- 数据库查询或第三方接口拖慢页面，动态页面尤其明显；
- 同一时间涌入大量请求，服务器排队，部分请求被直接丢弃。
这类问题不会让页面被判为“不存在”，但会明显降低蜘蛛愿意抓取的频次。对更新频繁的站点来说，抓取频次下降往往就表现为“新页面发布后很久才被处理”。
需要限速时，用服务器能听懂的方式说
如果确实不想让蜘蛛抓得太猛，不要靠随机返回 500 来“劝退”，那只会被当成故障。更稳妥的表达方式有两种：
- 503 加 Retry-After：明确告诉蜘蛛“我暂时不可用，请在指定时间后再来”。这属于标准语义，通常不会被理解为页面消失。
- 429：表示请求过多，适合接口或高负载时段使用。
robots.txt 里的 Crawl-delay 只有部分蜘蛛支持，不能当作唯一手段；真正的限速还是要落在服务器层的并发控制和缓存上。
排查顺序：从日志里的状态码分布开始
遇到收录变慢、页面更新不上，先别急着改内容，先看服务器日志：
- 把蜘蛛请求按状态码分组，看 5xx 与超时所占的比例；
- 看失败是集中在某些目录、某些参数，还是覆盖全站；
- 对比失败时段与服务器负载、发布操作、缓存刷新是否重合；
- 确认 404 是否被当成兜底响应返回，从而掩盖了真实故障。
抓取失败本身不是内容问题，但结果常常以“收录问题”的形式表现出来。先确认蜘蛛到底拿到了什么，再谈页面本身。
把服务器稳定性当成收录的基础设施来看待：状态码语义正确、响应时间可控、限速方式规范，蜘蛛才愿意把有限的抓取额度持续投到你的站点上。至于多久恢复抓取频次、多久重新处理页面，取决于故障持续时间、站点规模和历史表现，没有统一的数字。