页面内容做得不错，站点地图也提交了，可索引状态一直没动静。这时候很多人继续回头改标题、加内链，却忽略了一个更前置的环节：搜索方来抓取时，服务端给了什么回应。抓取不成功，后面的内容判断、质量评估都无从谈起。
抓取和收录是两个环节
先把这个顺序理清：发现 URL、发起抓取、拿到页面内容、判断是否入库，是四件事。抓取失败或反复失败，页面就卡在“已发现”这一层，跟内容质量没关系。如果抓取日志里同一个地址返回的是 5xx、超时或连接中断，那么去改正文是在解决错误的问题。
先看抓取时服务端返回了什么
几类常见的坏信号
- 5xx 与网关错误：源站崩溃、上游超时、CDN 回源失败，都会以 500、502、503、504 的形式返回给爬虫。偶发一次影响有限，持续出现会让抓取频次被下调。
- 响应时间过长：首字节时间动辄数秒，爬虫的连接窗口等不起，表现为大量超时记录。
- 连接重置与超时：防火墙、限速策略或 UA 拦截把爬虫请求直接掐断，日志里看不到正常的 GET 记录。
- 429 与访问频次限制：短时间大量请求触发限流，爬虫被临时拒绝。
容易被忽略的拦截层
WAF、Bot 管理、CDN 的爬虫规则经常是单独配置的。前台访问正常，只说明浏览器 UA 能通过；爬虫 UA 是否被放行，需要单独验证。可以从服务端日志里筛出爬虫 UA 的请求，看它们的状态码分布，而不是只看总体可用性。
核对顺序
- 确认现象：找一个具体 URL，用日志或抓取测试工具看爬虫实际拿到的状态码和响应时间，不要用浏览器结果代替。
- 区分是全局还是局部：只有某个模板、某个机房或某个目录异常，通常是局部配置问题；全站普遍超时，先查源站和 CDN。
- 排查拦截：检查 WAF、CDN、反向代理里的爬虫放行规则，确认没有按 UA 或频次误杀。
- 修复并验证：修完后用同样的方式复测，确认状态码回到 200、响应时间稳定在合理区间。
- 再回到内容层面：服务端恢复正常后，如果页面依然不进索引，再去核对内容质量、重复度和 URL 规范。
抓取层面的问题解决之后，收录通常不会立刻跟上，中间还隔着重新抓取和判定，观察要留出时间。
修复之后看什么
服务端恢复后，重点观察三件事：爬虫请求量是否回升、5xx 与超时占比是否下降、目标目录的抓取覆盖是否扩大。这几项稳定了，再去站点地图和索引报表里看收录变化更靠谱。如果只有部分页面的收录在恢复，说明问题可能同时存在服务端和内容两个原因，别急着下结论。
小结
收录核对不必从内容开始。先用抓取日志确认搜索方拿到的是一次正常响应，再谈页面质量，顺序对了能省下不少反复修改的功夫。