蜘蛛没来抓某個頁面，很多人的第一反應是去看 Sitemap，或者怀疑内鏈太少。但抓取本身是一條有多道關卡的鏈路：域名能不能解析、连接建不建得起来、服務器返回什么、返回的内容能不能用、頁面里還有没有值得繼續跟的連結。任何一层断了，後面的動作都不會發生。把問题分层看，比反复提交 Sitemap 更有效。
為什么要把抓取問题分层
日誌里只看到“没来抓”，看不到原因。分层的好處是每一层都有可驗證的證據：DNS 有解析记錄，服務器有訪問日誌，响應有狀態碼，頁面有 HTML 内容，連結有具体的 href。逐层確認，就能把“蜘蛛不抓”這個模糊结论，缩小到一個具体环节。
抓取失敗通常不是單一原因，而是某几层同时存在問题。先找到第一道断裂的關卡，再谈優化。
第一层：域名解析與網絡可達
如果蜘蛛连域名都解析不了，後面所有讨论都没有意义。常见情况包括：
- 更換服務器後 DNS 记錄未同步，部分地区仍解析到舊 IP；
- 解析商對某些来源的請求做了限制，導致抓取方拿不到正确结果；
- 域名刚啟用，解析尚未全網生效。
這一层的證據是解析结果和线路差异，而不是站点日誌——因為請求根本没到你的服務器。
第二层：连接與响應
請求到了服務器，接下来看连接是否稳定。服務器忽快忽慢、並發被占满、TLS 握手频繁失敗，都會让蜘蛛在拿到内容前就放弃。
需要關注的信号
- 响應時間是否長期偏高，尤其是首字节時間；
- 是否出現間歇性 5xx，而不是稳定错誤；
- 是否因為频控或 WAF 規則，把正常抓取一起拦掉。
這一层的特点是“时好时坏”。如果同一個 URL 有时能抓、有时失敗，優先怀疑服務器承载和防護策略，而不是内容問题。
第三层：内容能否被正常解析
狀態碼 200 不代表抓取成功。頁面主体依赖前端渲染、關键内容由脚本异步加载，或者返回了一個空壳 HTML，蜘蛛拿到的就是一份没有信息的文档。
- 首屏内容是否直接存在于 HTML 源碼中；
- 重要連結是不是通過 JS 事件绑定，而不是真正的 a 标簽；
- 頁面是否因為体积過大，在抓取时被截断。
驗證方式很直接：關掉脚本，看頁面還剩多少内容和連結。剩得越少，抓取效率越受影响。
第四层：URL 發現與後續路径
前面三层都通了，蜘蛛确實進来了，但只抓了這一個頁面就走。問题往往在連結结构上：
- 頁面里没有指向其他相關内容的連結，形成孤岛；
- 連結都集中在頁脚或導航，路径重复且层級混乱；
- Sitemap 里列了 URL，站内却没有對應的入口。
抓取是沿着連結不断前行的過程。没有出口的頁面，對蜘蛛来说就是终点站。
一個可操作的排查顺序
- 確認域名解析在主要线路上一致，先排掉 DNS 問题；
- 從服務器日誌里筛出抓取来源，看狀態碼分布和响應時間；
- 對失敗 URL 做單点复测，区分稳定错誤和間歇错誤；
- 查看頁面源碼，確認正文和連結是否可直接讀取；
- 检查這些 URL 在站内是否有真實入口，以及入口所在的层級；
- 最後再回头看 Sitemap 是否與實际可抓取的 URL 一致。
顺序很重要。先把 Sitemap 做得再漂亮，前面几层不通，也只是把一份清單交给了到不了的蜘蛛。
几個容易誤判的地方
- 把没抓当成没收錄：抓取、收錄、展現是三件事，日誌能看到的只有抓取；
- 只看一次失敗就下结论：間歇性错誤需要多时段對比；
- 用提交代替修复：提交只是提示，不解决连接和内容层面的問题。
抓取排查的收益，往往来自少做無用功。與其不断新增 Sitemap 條目，不如先確認站点的每一层都能稳定交付内容，让蜘蛛顺着連結走得下去。