很多站点在推進新頁面收錄时，习惯一上来就改标题、加内鏈、調 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 和内鏈，让爬虫反复重新识別同一個頁面。

收錄推進慢，多數时候是某一层的技術前提没被满足。把可用性、可抓取、可渲染、内容信号依次過一遍，找到真正的阻断点再做针對性調整，通常比盲目優化更有效。