在站点後台的索引报告里，“已發現但尚未抓取”是一個容易被忽略、但信息量不小的狀態。它不等于頁面有問题，也不等于被拒绝，只是說明搜尋引擎已经知道這個 URL 存在，但還没安排訪問。想清楚它卡在哪一环，比反复提交要有用。
這個狀態在说什么
搜尋引擎處理一個 URL 大致會经歷几步：發現地址、進入待抓取队列、實际抓取、再判断是否進入索引。這個狀態刚好卡在發現和抓取之間——地址已经被记錄（来源可能是 sitemap、外鏈、站内連結或歷史資料），但抓取队列還没轮到它。
換句话说，問题通常不在“頁面好不好”，而在“值不值得現在去抓”。
它和“已抓取但未编入索引”的区別
這两個狀態经常被混着看，但成因差別很大。前者在抓取入口，多和抓取容量、URL 優先級、入口强度有關；後者已经完成抓取，進入质量评估环节，多和内容重复、主体内容過薄、信任信号不足有關。把两者放在一起分析，很容易做出错誤的調整。
常见原因
- 抓取频次有限：站点整体被抓取的节奏由歷史表現决定，新增 URL 需要排队。站点規模突然變大时，這個狀態會明顯增多。
- 入口太弱：URL 只出現在 sitemap 里，站内没有任何連結指向它。蜘蛛缺少再次来訪的理由。
- 抓取額度被占用：站内有大量參數頁、篩選頁、空列表頁反复被訪問，留给新頁面的空間自然變小。
- 服務器响應慢或不稳定：加载時間偏長、偶發 5xx，會让蜘蛛降低對這個站点的抓取意愿。
- 頁面重复度偏高：内容與已有頁面高度相似时，抓取的優先級會被压低。
- 抓取被阻挡：robots 規則或安全防護誤拦，日誌里看不到正常請求，但狀態仍會顯示“已發現”。
按顺序排查
- 先看服務器日誌：這個 URL 到底有没有被請求過。如果被請求過且返回異常狀態碼，問题就不在“没抓”，而在响應本身。
- 確認可訪問性：返回 200、没有登入墙、不依赖交互才出現正文。需要滚動或点击才加载的内容，抓取阶段容易判為空白。
- 检查站内入口：從主题相關的頁面加上一两條真實連結，通常比重复提交有效得多。入口位置越靠近首頁，被再次訪問的概率越高。
- 检查 sitemap：地址是否包含、lastmod 是否真實、有没有拆分成多個索引文件。sitemap 是补充通道，不是主要入口。
- 收敛低價值 URL：把篩選、排序、會话參數類地址用規范連結或抓取規則整理掉，把額度让给真正想被收錄的頁面。
- 看响應時間與 5xx 比例：稳定、快速的响應是抓取频次的基础。
- 必要时手動触發一次：少量 URL 可以借助提交接口推動，但不要重复做同一件事。
几個容易做错的動作
- 反复手動提交同一個地址，不會加快多少，反而增加無谓负担。
- 為了让它被收錄而堆大量内鏈，連結的相關性比數量重要。
- 把 sitemap 当成主要發現路径，忽略了站内連結结构這個更稳定的入口。
- 一看到這個狀態就改内容。如果日誌顯示根本没抓過，改内容並不解决排队問题。
這個狀態更接近“排队中”，而不是“被否定”。先看入口强弱和整体抓取容量，再谈内容层面的優化。
怎么判断有没有改善
判断依據應该放在日誌上，而不是盯着狀態标簽。如果一段時間内日誌里始终没有该 URL 的抓取记錄，說明還需要繼續處理入口和站点整体抓取效率；如果日誌里已经出現抓取记錄，那問题就轉移到索引阶段，接下来要看的维度就變了。
观察周期上，给一两周時間再看變化比較合理。收錄本身受站点体量、抓取资源、頁面價值等多重因素影响，任何單点動作都很难立刻见效，也不存在可以保證收錄的做法。