在搜尋後台或站長工具里看到一批 URL 處于“已發現，尚未抓取”，很容易让人着急。這個狀態本身並不代表頁面有問题，它只說明搜尋引擎已经知道這個地址存在，但還没有真正安排抓取。發現和抓取是两件事，抓取和收錄又是另外两件事。把它放回整個流程里看，排查方向會清楚很多。
先分清“發現”是怎么發生的
URL 被發現，通常来自几個入口：sitemap 里列出的地址、站内連結、外部連結，以及手動提交。發現环节只负责把地址登记進待處理列表，後面還要经過去重、優先級排序、抓取排期。一個頁面被發現了，不等于它马上會被抓；被抓了，也不等于一定會進索引。
“已發現但未抓取”常见的几個卡点
- 抓取预算被其他 URL 占用。尤其是大量參數頁、篩選頁、重复列表頁，會挤占同一站点的抓取名額。
- 服務器响應慢或不稳定。爬虫遇到超时、5xx 或波動較大的响應，通常會降低對该站点的抓取频率。
- 同一頁面有多個變体。带跟踪參數、排序參數、大小寫不同、结尾斜杠不一致的地址，會在队列里形成重复登记，真正規范的那一個反而排得更久。
- 内鏈入口太弱。如果頁面只能從 sitemap 找到，站内几乎没有可点击入口，或者入口頁本身抓取频率就很低，它被安排抓取的速度自然慢。
- robots.txt 或防火墙誤伤。有时不是没抓，而是抓取請求被挡在门外，狀態就停留在發現阶段。
- 新站或低權重目錄的優先級偏低。在抓取资源有限的情况下，搜尋引擎會優先處理它認為更值得抓的部分。
排查顺序：從可抓取性開始，不要先催提交
- 確認 URL 本身可抓取。检查狀態碼是否為 200，重定向鏈是否過長，robots.txt 是否誤屏蔽，是否有登入、彈窗或驗證碼拦截。
- 检查重复變体。把同一頁面的參數版本、协议版本、大小寫版本、结尾斜杠版本列出来，能用 canonical 或跳轉收敛的先收敛，减少队列里的無效登记。
- 看服務器日誌。確認爬虫有没有来過、来了几次、抓的是哪個地址、返回了什么狀態。日誌比後台狀態更接近真實情况。
- 检查内鏈入口。從首頁出發，点几下能到目标頁；連結是否可被爬虫识別；锚文本是否自然描述了頁面主题，而不是“点击這里”。
- 收敛 sitemap。只放規范、可索引、内容相對完整的 URL。不要把參數頁、已下线頁、重复頁大量塞進去。
- 稳定响應時間。让重要目錄保持稳定的 200 响應，避免频繁超时和大幅波動。
哪些動作容易适得其反
反复手動提交同一批 URL，通常不會让抓取更快，反而可能让入口資料變得嘈杂。给參數頁、篩選頁、空结果頁大量加内鏈，也會把抓取名額導向低價值地址。為了“催抓”频繁改動頁面标题和正文，可能让頁面反复進入待观察狀態。更稳妥的做法是先把结构、重复和响應這几层整理干净，再让發現入口自然工作。
後台狀態是结果，不是原因。看到“已發現但未抓取”，先問三個問题：它是否可抓？它是否被重复地址稀释？它是否有足够清晰的站内入口？
给自己一個观察窗口
不要逐頁盯狀態。按模板或目錄分组，例如文章頁一组、栏目頁一组、聚合頁一组，每周看一次组内變化。如果某一组長期停在發現未抓取，優先處理该组的入口结构、重复變体和服務器响應，而不是繼續增加提交入口。抓取排期本身有滞後，短期波動不必過度反應；但如果几周都没有抓取痕迹，就值得按上面的顺序認真查一遍。