在 Search Console 的索引覆盖率报告里，“已发现，当前未抓取”是一个容易被略过的状态。它既不是错误，也不算成功，而是介于“搜索引擎知道有这个 URL”和“真的去抓”之间的一段排队期。多数情况下它会自己走完，但如果长期卡在这一列，往往说明站点在某个环节给了错误的信号。
先分清：已发现、已抓取、已索引
这三个状态对应三个不同环节，混在一起谈，容易得出“蜘蛛不来就是内容不行”的结论。
- 已发现：URL 通过站点地图、内链、外链或提交接口被记录，进入待抓取队列。
- 已抓取：蜘蛛真正取回了页面，能读到状态码、响应头和 HTML 内容。
- 已索引：内容被判断为可独立展示、有检索价值，才进入索引。
“已发现但未抓取”卡的是调度，不是质量判断。搜索引擎还没看到页面内容，谈不上评价好坏。这一点先想清楚，后面的排查方向才不会跑偏。
长期停在“已发现”的常见原因
内链太浅，或者根本没有内链入口
站点地图只能说明“存在这些 URL”，但抓取优先级很大程度由内链决定。一个只出现在 sitemap 里、全站没有任何链接指向的页面，等于被孤立在站点结构之外。相比之下，从首页点击三四次就能到达的页面，通常排得更靠前。
URL 数量在短时间暴增
一次性放出几万条 URL，而站点日常被抓取量只有几百条，队列自然会被拉长。分页、筛选、日历、标签等自动生成的地址尤其容易造成这种堆积，其中大部分并不需要进入索引。
服务器响应拖慢整站抓取
频繁的 5xx、超时或响应时间过长，会让调度系统降低对整站的抓取频次，连正常页面也一起被拖慢。这一类问题在服务器日志里通常比在覆盖率报告里更早暴露。
低价值 URL 占着队列
空结果页、重复的筛选组合、带追踪参数的副本，会挤占本就不多的抓取额度。它们大多停在“已发现”状态，看起来无害，实际消耗的是同一份调度资源。
处理顺序：从成本最低的开始
- 先确认这些 URL 是否真的需要被收录。不需要的用 robots.txt 或 noindex 收口，别让它们继续在队列里占位。
- 检查是否有可点击的内链入口，尽量让重要页面从首页三到四次点击可达。
- 整理站点地图，只保留规范版本的 URL，去掉参数变体、已被重定向的旧地址和明确不打算收录的页面。
- 翻一遍服务器日志，确认蜘蛛实际在抓的是哪些目录，和你的预期是否一致。
- 观察两到四周再判断。短时间内反复改动结构，反而让信号更混乱。
几个不建议做的事
- 反复提交同一个 URL。手动提交有一定作用，但重复提交通常不会加快调度。
- 用蜘蛛池或代理流量伪装成搜索蜘蛛访问。这类流量不会被当作真实抓取处理，还会让日志分析失真。
- 把“提交了就一定收录”当成前提。提交只是让 URL 被更快知道，抓取和索引仍是另外两步。
- 为了让数字好看，把不需要的页面也硬塞进索引。
把“已发现”当作一个提醒，而不是一个故障。它更多是在说：这条 URL 已经进入视野，但站点结构、抓取额度或服务器状态还没准备好接住它。
最后提醒一句观察周期。新站、新栏目或者刚经历过改版的站点，出现一段时间的排队属于正常现象。真正需要动手的，是那些有明确价值、有清晰内链入口，却连续数周没有动静的页面。先处理这一小批，再看整站的抓取分布是否随之变化，通常比一次性大改结构要稳妥得多。