搜索蜘蛛到访并不等于页面会被收录，但抓取这一步完不成，收录就无从谈起。有些页面长期停在“已发现”状态，抓取错误报告里堆着一排记录，问题往往不在内容本身，而在服务器给蜘蛛的响应上。
先分清：抓取失败和收录延迟是两个阶段
被抓取是前提，能不能进索引还要看页面质量和重复程度。但如果蜘蛛反复来、反复失败，页面会一直排在抓取队列里，既不会进索引，也不会被别人顶上来。所以看到收录数量长期不动，第一步应该先看抓取侧的数据，而不是急着改正文。
三个地方能看出抓取出了问题
- 服务器日志：统计搜索蜘蛛的请求里状态码怎么分布。5xx、超时、连接被重置的比例偏高，说明问题在服务端。
- 抓取统计与抓取错误报告：能看到抓取总次数、平均响应时间，以及按错误类型分组的 URL 列表。
- 索引覆盖情况：某个栏目下的 URL 长期停在“已发现，尚未抓取”，通常意味着抓取额度被消耗在了别处。
响应慢和超时，常见的四种来源
1. 首字节时间过长
数据库慢查询、缺少缓存、接口串行调用，都会让单个请求的响应时间从几百毫秒涨到几秒。蜘蛛单次抓取有时间上限，超过就会中断，日志里可能只留下一个不完整的状态。
2. 页面和资源太重
正文只有一两千字，页面却要加载几十个脚本、字体和图片。蜘蛛主要读 HTML，但下载体积和并发连接依然会拖慢整体节奏，抓取效率随之下降。
3. 5xx、限流与防护误伤
爬虫被 WAF、频率限制或 CDN 规则当成异常流量拦下，会返回 403、429 或者空响应。这类错误在日志里往往集中在某个时间段，和站点自身的访问高峰重合。
4. 重定向链叠加
一个 URL 经过两三次跳转才到最终页面，每次跳转都要重新建立连接。链条越长，超时概率越高，收录也容易落在中间的地址上。
可以照着走的排查顺序
- 从日志里筛出搜索蜘蛛的请求，按响应时间排序，看最慢的是哪一批 URL。
- 把 5xx、429、403 的 URL 单独拉一份清单，判断是全局问题还是集中在某个目录。
- 抽样测几个 URL 的响应时间和状态码，尽量从不同网络环境测，排除单点故障。
- 检查防护规则有没有误伤搜索蜘蛛的 UA 或 IP 段，必要时加白名单。
- 确认重要页面到首页的点击距离不要太深，减少无意义的重定向和参数跳转。
- 改完之后再观察一段时间的抓取统计，看响应时间和抓取量是否回升。
抓取恢复之后，索引更新还会滞后一段时间。这段时间里最好不要再动 URL 结构和站内规则，否则前后变化叠在一起，很难判断哪一步起了作用。
抓取顺了，收录才轮到内容问题
抓取恢复正常，只是把 URL 送进了下一步。之后是否进索引，仍然取决于内容是否重复、是否有独立价值、是否被正确的地址指向。把顺序理顺，排查会省力很多。