在索引覆盖报告里，“已發現，尚未编入索引”是一個容易被顺手忽略的狀態。它和“已抓取，尚未编入索引”不是一回事：前者說明搜尋引擎知道這個 URL 存在，但還没有去請求它；後者說明已经抓過，只是暂时没放進索引。把這两個狀態当成同一個問题看，排查方向從一開始就會跑偏。
這個狀態到底說明什么
URL 被發現的渠道通常有几種：站点地图、站内連結、外部連結，以及上一次抓取时在頁面上看到的連結。發現之後，URL 會進入調度队列，等待分配抓取资源。排队時間没有固定值，取决于站点規模、抓取額度，以及這個 URL 被判断出的優先級。
所以“已發現”本身不是错誤提示，它只是表示流程停在了第一步。真正需要判断的是：它是正常排队，還是被某些因素長期压在了队尾。
常见的排队卡点
- 内鏈入口不足：頁面只出現在站点地图里，站内没有任何正文連結指向它，缺少可參考的權重信号。
- 站点地图過于臃肿：把大量低價值、重复或參數化的 URL 一起提交，抓取額度被分散。
- 服務器响應偏慢：同样的抓取額度下，慢請求能拿到的頁面數更少，队列推進更慢。
- 同一内容的多個 URL 變体：調度时需要反复做去重判断，容易延後處理。
- 頁面長期没有變化：更新频率低的 URL，在重新調度的排序里往往靠後。
按這個顺序排查
- 先確認 URL 能正常訪問，返回 200，内容非空，且没有被 robots.txt 拦截。
- 確認它是否出現在站点地图中，位置是否合理，是否和一堆無效地址混在一起。
- 在站内相關頁面加一條正文内的普通連結，锚文本與目标頁主题一致。
- 查看服務器日誌，確認是否真的有過抓取請求。完全没有請求，說明還在排队；有請求但狀態異常，問题就不在排队环节。
- 對比同一批上线的其他 URL，判断是個別現象還是整批都在等待。
這几步的價值在于把“没被抓取”拆成可驗證的分支：能不能訪問、有没有被發現、有没有被請求。三者對應的問题完全不同。
哪些做法能真正缩短等待
可控性最高的是内鏈。把連結放進正文主体、指向主题相關的頁面，比在頁脚或侧栏堆一批連結更有效，因為正文連結通常被当作頁面内容的一部分来處理。其次是控制站点地图的质量：只放需要收錄的規范 URL，把篩選參數、排序參數這類地址排除掉。
另外，先處理掉站内已有的重复内容和软 404，让抓取額度不被浪費在無意义的請求上，對整站的調度节奏也有帮助。這類工作是間接的，但往往比單点提交更管用。
不建议做的事
- 反复手動提交同一個 URL，這不會创造額外的抓取机會。
- 用參數批量生成近似地址去试探，容易制造新的重复内容問题。
- 把没有實际内容的頁面塞進站点地图，用来“占位”。
- 只盯着這一個 URL，忽略同批頁面是否有共同原因。
“已發現”是一個信号，不是承诺。它說明 URL 已经進了队列，至于什么时候被請求，還取决于站点整体被信任的程度和目前的抓取額度分配。
如果你確認訪問正常、内鏈完整、站点地图干净，日誌里也能看到抓取請求，那這個狀態通常會在之後的一段時間里自然變化。此时更适合把精力放在頁面质量和站内结构上，而不是反复刷新狀態。真正需要處理的是那些長期停在這一步、且同批 URL 都如此的情况——那往往指向抓取額度或站点层級的問题，而不是單個頁面。