在 Search Console 的索引覆盖率报告里，“已發現，目前未抓取”是一個容易被略過的狀態。它既不是错誤，也不算成功，而是介于“搜尋引擎知道有這個 URL”和“真的去抓”之間的一段排队期。多數情况下它會自己走完，但如果長期卡在這一列，往往說明站点在某個环节给了错誤的信号。
先分清：已發現、已抓取、已索引
這三個狀態對應三個不同环节，混在一起谈，容易得出“蜘蛛不来就是内容不行”的结论。
- 已發現：URL 通過站点地图、内鏈、外鏈或提交接口被记錄，進入待抓取队列。
- 已抓取：蜘蛛真正取回了頁面，能讀到狀態碼、响應头和 HTML 内容。
- 已索引：内容被判断為可獨立展示、有检索價值，才進入索引。
“已發現但未抓取”卡的是調度，不是质量判断。搜尋引擎還没看到頁面内容，谈不上评價好坏。這一点先想清楚，後面的排查方向才不會跑偏。
長期停在“已發現”的常见原因
内鏈太浅，或者根本没有内鏈入口
站点地图只能說明“存在這些 URL”，但抓取優先級很大程度由内鏈决定。一個只出現在 sitemap 里、全站没有任何連結指向的頁面，等于被孤立在站点结构之外。相比之下，從首頁点击三四次就能到達的頁面，通常排得更靠前。
URL 數量在短時間暴增
一次性放出几萬條 URL，而站点日常被抓取量只有几百條，队列自然會被拉長。分頁、篩選、日歷、标簽等自動生成的地址尤其容易造成這種堆积，其中大部分並不需要進入索引。
服務器响應拖慢整站抓取
频繁的 5xx、超时或响應時間過長，會让調度系統降低對整站的抓取频次，连正常頁面也一起被拖慢。這一類問题在服務器日誌里通常比在覆盖率报告里更早暴露。
低價值 URL 占着队列
空结果頁、重复的篩選组合、带追踪參數的副本，會挤占本就不多的抓取額度。它們大多停在“已發現”狀態，看起来無害，實际消耗的是同一份調度资源。
處理顺序：從成本最低的開始
- 先確認這些 URL 是否真的需要被收錄。不需要的用 robots.txt 或 noindex 收口，別让它們繼續在队列里占位。
- 检查是否有可点击的内鏈入口，尽量让重要頁面從首頁三到四次点击可達。
- 整理站点地图，只保留規范版本的 URL，去掉參數變体、已被重定向的舊地址和明确不打算收錄的頁面。
- 翻一遍服務器日誌，確認蜘蛛實际在抓的是哪些目錄，和你的预期是否一致。
- 观察两到四周再判断。短時間内反复改動结构，反而让信号更混乱。
几個不建议做的事
- 反复提交同一個 URL。手動提交有一定作用，但重复提交通常不會加快調度。
- 用蜘蛛池或代理流量伪装成搜尋蜘蛛訪問。這類流量不會被当作真實抓取處理，還會让日誌分析失真。
- 把“提交了就一定收錄”当成前提。提交只是让 URL 被更快知道，抓取和索引仍是另外两步。
- 為了让數字好看，把不需要的頁面也硬塞進索引。
把“已發現”当作一個提醒，而不是一個故障。它更多是在说：這條 URL 已经進入视野，但站点结构、抓取額度或服務器狀態還没准备好接住它。
最後提醒一句观察周期。新站、新栏目或者刚经歷過改版的站点，出現一段時間的排队属于正常現象。真正需要動手的，是那些有明确價值、有清晰内鏈入口，却连續數周没有動静的頁面。先處理這一小批，再看整站的抓取分布是否随之變化，通常比一次性大改结构要稳妥得多。