页面不收录，很多人第一反应是内容质量问题或外链不够。但先看一眼服务器日志常常更有效：蜘蛛可能压根没拿到你的页面，而是拿到一个失败的响应。抓取失败和抓到了但不收录是两件不同的事，混在一起排查会绕远路。

先分清：蜘蛛拿到的是页面还是错误响应

在日志里按爬虫 UA 过滤，看这批请求的状态码分布。常见的几种情况，处理方向完全不同：

• 200：页面正常返回，问题在后续环节，比如内容判断、canonical、重复内容。
• 301/302/307：跳转本身不是问题，但链条过长或指向错误地址会拖慢抓取。
• 403/429：多半是被 WAF、CDN 或限流规则拦下，爬虫身份被误判。
• 500/502/503/504：服务端自身的问题，影响范围往往是整段路径甚至整站。
• 超时无响应：日志里可能只留一条连接中断，状态码都不完整。

同一批 URL 如果 5xx 比例明显偏高，先别改内容，先修服务端。

5xx 的连锁影响比想象中大

偶发的 5xx 问题不大，但如果某个目录长期不稳定，蜘蛛对该目录的抓取频次会明显下降。更需要注意的是两个特殊文件：

• robots.txt 返回 5xx：部分搜索引擎会在一段时间内暂停对整站的抓取，而不是照常抓取。此时全站不收录，往往只是抓取被自己掐断了。
• sitemap 返回 5xx 或超时：URL 发现渠道失效，新页面很难进入队列，老页面的更新信号也会减弱。

建议把这两个文件加到独立监控里，返回码异常时第一时间告警，而不是等收录数据掉了才回头查。

429 与 403：被拦截的蜘蛛

不少站点上了 CDN 或云 WAF，默认规则会按 UA、请求频率、IP 段做限制。真实爬虫被拦下的表现通常是 403 或 429，日志里看得到，但很多人只看有没有来，不看来了拿到什么。

处理思路：

• 在日志中确认爬虫声明的 IP，并做反向解析验证，不要只看 UA 字符串。
• 对验证通过的真实爬虫放行，而不是整段 IP 段放开。
• 限流规则里给爬虫留单独速率，不要和普通访客共用一套阈值。

UA 可以伪造，IP 反查不能。放行前先确认身份，避免给恶意流量开白名单。

超时与响应慢：不是失败，效果接近失败

抓取是有时间预算的。首字节时间过长、页面体积过大、关键资源加载不出来，都会让蜘蛛提前放弃。常见原因包括：服务器本身负载高、数据库慢查询、页面里塞了过多同步请求、TTFB 长期在秒级以上。

可以先看一个指标：同一批 URL 的平均响应时间有没有随时间变差。如果只是某几个页面慢，多半是页面自身的问题；如果整站都慢，先查基础设施。

建议的排查顺序

1. 拉一段服务器日志，按爬虫 UA 统计状态码分布，确定失败比例。
2. 单独验证 robots.txt 与 sitemap 的可访问性和返回码。
3. 检查 WAF、CDN、限流的拦截记录，区分误拦和真实恶意流量。
4. 看响应时间分布，找出慢页面与慢接口。
5. 确认证书、DNS、IPv6 等基础链路没有异常。
6. 修复后再观察一段时间的抓取频次与状态码变化，而不是立刻看收录数字。

修复后怎么验证

先看抓取侧的指标：爬虫请求量、5xx 占比、平均响应时间、robots 与 sitemap 拉取是否恢复。这些稳定之后，再去看 URL 是否进入索引。收录是结果，抓取是前提，顺序反了容易得出错误结论。

如果站点同时跑着多个域名或环境，记得先确认蜘蛛访问的是哪一个，测试环境的拦截规则有时会跟着正式环境一起改。