在 Search Console 的页面报告里，经常会看到一批 URL 停在“已发现 - 尚未抓取”。它和“已抓取 - 尚未编入索引”是两件事：前者表示蜘蛛已经知道这个地址存在，但还没有发出请求；后者表示请求已经发生过，只是内容没被采用。把这两类混在一起排查，很容易把问题引到错误的环节上。
这篇文章只讨论前者：当 URL 已经在候选队列里，却迟迟等不到抓取请求时，站点侧可以按什么顺序核对。
先确认日志里是不是真的没有请求
“尚未抓取”是 Search Console 的判断，不一定和服务器日志完全同步。核对的第一件事，是在原始访问日志里把 URL 精确找一遍，而不是只看后台的统计面板。
- 用完整路径匹配，包括大小写、尾斜杠和查询参数，避免被相似 URL 掩盖。
- 把日志时间范围拉长到状态更新之前，状态本身有延迟。
- 如果站点走 CDN，回源日志往往看不到全部请求，需要同时看边缘节点日志。
- 确认日志没有被轮转覆盖，尤其是访问量大的站点。
如果日志里确实有请求，说明只是状态还没刷新，与抓取本身无关。
再看这些 URL 是怎么被交出去的
URL 进入候选队列通常有几个入口：Sitemap、正常的内链、接口推送或提交，以及外部链接。任何一条通路出问题，都可能导致 URL 只是被“记录”而没有排队。
- Sitemap 是否仍然有效、能被正常访问、没有被 robots.txt 误封。
- URL 是否出现在某个可抓取的页面上，且不是 JS 延迟渲染后才出现。
- 链接是否落在分页较深、需要多点几次才能到达的位置。
- 是否只通过重定向链的末端暴露，导致中间环节被反复消耗。
一个常见情况是：URL 确实写进了 Sitemap，但站内没有任何链接指向它。这时蜘蛛需要额外安排预算才会走到它，等待时间会明显变长。
抓取容量与优先级的影响
当站点规模较大时，抓取总会有取舍。同样处于“已发现”状态的 URL，优先级低的会被排在后面。
- 站点整体响应时间偏慢，单位时间内能抓的 URL 就少。
- 大量低价值 URL，例如筛选参数和无意义的组合页，占据队列。
- 5xx、超时、重定向链过多，会让同一批 URL 被反复重试。
- 模板重复度高，蜘蛛难以判断哪一页更值得先抓。
这些因素不会让 URL 消失，但会明显拉长从“已发现”到“被抓取”的间隔。减少重复 URL 的数量、缩短响应时间，通常比反复提交更有效。
几个容易被误判的点
状态是抽样和汇总后的结果，不等于某一时刻的真实抓取行为。用它做单点结论，容易得出错误的因果关系。
- 把“尚未抓取”当成“被惩罚”，于是改动 robots.txt 或大量删页面。
- 一天之内反复重新提交 Sitemap，观察不到变化就继续提交。
- 只看首页日志，忽略内页的抓取情况。
一张可以照着走的核对表
- 取一批代表性的“已发现”URL，尽量覆盖不同模板。
- 在完整日志中精确匹配，确认有无请求记录。
- 核对 Sitemap、内链、推送三条通路是否都正常。
- 检查这些 URL 的响应时间和状态码是否稳定。
- 统计同期站点整体抓取量，看是普遍偏少还是局部问题。
- 记录核对日期，隔一段固定周期再对比一次，看趋势而不是看单日。
这类问题的处理周期通常以周为单位，短期内的状态跳动说明不了太多。把日志、Sitemap 和内链三者对齐之后，剩下的往往就是时间和容量的问题。