很多站点在推进新页面收录时，习惯一上来就改标题、加内链、调 canonical，折腾一圈之后索引状态却没有变化。收录慢通常不是单点问题，而是卡在某一层前置条件上。把排查拆成四层，按顺序往下走，比反复试错更省时间。

第一层：页面本身能不能被稳定访问

抓取的前提是服务器能在合理时间内返回 200 状态码。这一层不成立，后面的优化基本没有意义。

• 状态码异常：5xx、连接超时、TLS 握手失败，都会让抓取中断。
• 响应过慢：TTFB 长期偏高时，抓取配额更容易分给响应更快的页面。
• 稳定性差：同一个 URL 时而 200、时而 503，会被视为不可靠。
• 端上不一致：移动端打不开或报错，同样会影响收录判断。

排查方式很直接：用服务器日志或监控看目标 URL 在一段时间内的状态分布，而不是只抽查一次。

第二层：爬虫有没有机会抓

页面能打开，不等于爬虫抓得到。这一层常见的两个问题是明确禁止抓取，以及根本没有入口。

• robots.txt 规则是否误伤了目标目录或带参数的 URL。
• 页面 meta robots 或响应头 X-Robots-Tag 是否写了 noindex、nofollow。
• 是否存在至少一条可爬取的内部链接指向它，而不是只放在 JS 触发的菜单里。
• sitemap 是否包含该 URL，且地址与页面实际 URL 完全一致。

需要提醒的是，允许抓取与允许索引是两件事，robots.txt 放行只是第一步。

第三层：抓到的内容能不能被渲染出来

现在不少页面依赖前端渲染，如果爬虫拿到的 HTML 里没有核心内容，收录就会延后，甚至长期停在发现阶段。

• 正文是否直接出现在 HTML 源码中，还是完全依赖接口返回。
• 渲染所需的关键 JS、CSS 是否被 robots.txt 屏蔽。
• 接口是否要求登录、携带特定 Cookie 或 Referer 才返回数据。
• 是否使用了爬虫难以稳定执行的交互，比如滚动加载、点击展开。

检查方式是查看源码视图，或用抓取工具对比原始 HTML 与渲染后 DOM 的内容差异。

第四层：内容信号是否支持收录

前置条件都满足，页面仍可能停留在“已发现”或“已抓取但未编入索引”。这时要回到页面本身，看它是否具备被收录的理由。

• 与站内其他页面高度雷同：同一模板换关键词、同一列表换排序。
• 内容量过少：只有标题加几句描述，缺少可支撑判断的信息。
• 主题完全重叠：多个 URL 讲的是同一件事，看不出分工。
• 缺少引用：站内没有任何页面主动链接它，结构上体现不出重要性。

这一层没有硬性阈值，能做的是把页面之间的差异讲清楚，让每个 URL 都有独立的主题和用途。

为什么强调按顺序排查

四层之间存在依赖关系。第一层不成立，第二层无从谈起；第二层被堵住，第三层做得再好也没人看到；前三层都通过，才轮到内容信号的判断。

排查收录问题，先把最靠前的阻断项排除掉，再讨论优化手段。顺序颠倒，容易把简单问题做复杂。

几个容易踩的坑

1. 只盯一个页面看，忽略同批次页面的共性表现。
2. 改完设置立刻看结果，忽略抓取与索引本身需要时间窗口。
3. 把收录慢直接归因于“权重不够”，却不去检查服务器与渲染。
4. 频繁调整 URL、canonical 和内链，让爬虫反复重新识别同一个页面。

收录推进慢，多数时候是某一层的技术前提没被满足。把可用性、可抓取、可渲染、内容信号依次过一遍，找到真正的阻断点再做针对性调整，通常比盲目优化更有效。