在索引覆盖报告里，“已发现，尚未编入索引”是一个容易被顺手忽略的状态。它和“已抓取，尚未编入索引”不是一回事：前者说明搜索引擎知道这个 URL 存在，但还没有去请求它；后者说明已经抓过，只是暂时没放进索引。把这两个状态当成同一个问题看，排查方向从一开始就会跑偏。
这个状态到底说明什么
URL 被发现的渠道通常有几种：站点地图、站内链接、外部链接，以及上一次抓取时在页面上看到的链接。发现之后，URL 会进入调度队列，等待分配抓取资源。排队时间没有固定值，取决于站点规模、抓取额度，以及这个 URL 被判断出的优先级。
所以“已发现”本身不是错误提示，它只是表示流程停在了第一步。真正需要判断的是：它是正常排队，还是被某些因素长期压在了队尾。
常见的排队卡点
- 内链入口不足：页面只出现在站点地图里，站内没有任何正文链接指向它，缺少可参考的权重信号。
- 站点地图过于臃肿：把大量低价值、重复或参数化的 URL 一起提交，抓取额度被分散。
- 服务器响应偏慢：同样的抓取额度下，慢请求能拿到的页面数更少，队列推进更慢。
- 同一内容的多个 URL 变体：调度时需要反复做去重判断，容易延后处理。
- 页面长期没有变化：更新频率低的 URL，在重新调度的排序里往往靠后。
按这个顺序排查
- 先确认 URL 能正常访问，返回 200，内容非空，且没有被 robots.txt 拦截。
- 确认它是否出现在站点地图中，位置是否合理，是否和一堆无效地址混在一起。
- 在站内相关页面加一条正文内的普通链接，锚文本与目标页主题一致。
- 查看服务器日志，确认是否真的有过抓取请求。完全没有请求，说明还在排队；有请求但状态异常，问题就不在排队环节。
- 对比同一批上线的其他 URL，判断是个别现象还是整批都在等待。
这几步的价值在于把“没被抓取”拆成可验证的分支：能不能访问、有没有被发现、有没有被请求。三者对应的问题完全不同。
哪些做法能真正缩短等待
可控性最高的是内链。把链接放进正文主体、指向主题相关的页面，比在页脚或侧栏堆一批链接更有效，因为正文链接通常被当作页面内容的一部分来处理。其次是控制站点地图的质量：只放需要收录的规范 URL，把筛选参数、排序参数这类地址排除掉。
另外，先处理掉站内已有的重复内容和软 404，让抓取额度不被浪费在无意义的请求上，对整站的调度节奏也有帮助。这类工作是间接的，但往往比单点提交更管用。
不建议做的事
- 反复手动提交同一个 URL，这不会创造额外的抓取机会。
- 用参数批量生成近似地址去试探，容易制造新的重复内容问题。
- 把没有实际内容的页面塞进站点地图，用来“占位”。
- 只盯着这一个 URL，忽略同批页面是否有共同原因。
“已发现”是一个信号，不是承诺。它说明 URL 已经进了队列，至于什么时候被请求，还取决于站点整体被信任的程度和当前的抓取额度分配。
如果你确认访问正常、内链完整、站点地图干净，日志里也能看到抓取请求，那这个状态通常会在之后的一段时间里自然变化。此时更适合把精力放在页面质量和站内结构上，而不是反复刷新状态。真正需要处理的是那些长期停在这一步、且同批 URL 都如此的情况——那往往指向抓取额度或站点层级的问题，而不是单个页面。