蜘蛛没来抓某个页面，很多人的第一反应是去看 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 条目，不如先确认站点的每一层都能稳定交付内容，让蜘蛛顺着链接走得下去。