在 Search Console 的頁面报告里，经常會看到一批 URL 停在“已發現 - 尚未抓取”。它和“已抓取 - 尚未编入索引”是两件事：前者表示蜘蛛已经知道這個地址存在，但還没有發出請求；後者表示請求已经發生過，只是内容没被采用。把這两類混在一起排查，很容易把問题引到错誤的环节上。
這篇文章只讨论前者：当 URL 已经在候選队列里，却迟迟等不到抓取請求时，站点侧可以按什么顺序核對。
先確認日誌里是不是真的没有請求
“尚未抓取”是 Search Console 的判断，不一定和服務器日誌完全同步。核對的第一件事，是在原始訪問日誌里把 URL 精确找一遍，而不是只看後台的統計面板。
- 用完整路径匹配，包括大小寫、尾斜杠和查询參數，避免被相似 URL 掩盖。
- 把日誌時間范围拉長到狀態更新之前，狀態本身有延迟。
- 如果站点走 CDN，回源日誌往往看不到全部請求，需要同时看邊缘节点日誌。
- 確認日誌没有被轮轉覆盖，尤其是訪問量大的站点。
如果日誌里确實有請求，說明只是狀態還没刷新，與抓取本身無關。
再看這些 URL 是怎么被交出去的
URL 進入候選队列通常有几個入口：Sitemap、正常的内鏈、接口推送或提交，以及外部連結。任何一條通路出問题，都可能導致 URL 只是被“记錄”而没有排队。
- Sitemap 是否仍然有效、能被正常訪問、没有被 robots.txt 誤封。
- URL 是否出現在某個可抓取的頁面上，且不是 JS 延迟渲染後才出現。
- 連結是否落在分頁較深、需要多点几次才能到達的位置。
- 是否只通過重定向鏈的末端暴露，導致中間环节被反复消耗。
一個常见情况是：URL 确實寫進了 Sitemap，但站内没有任何連結指向它。這时蜘蛛需要額外安排预算才會走到它，等待時間會明顯變長。
抓取容量與優先級的影响
当站点規模較大时，抓取總會有取舍。同样處于“已發現”狀態的 URL，優先級低的會被排在後面。
- 站点整体响應時間偏慢，單位時間内能抓的 URL 就少。
- 大量低價值 URL，例如篩選參數和無意义的组合頁，占據队列。
- 5xx、超时、重定向鏈過多，會让同一批 URL 被反复重试。
- 模板重复度高，蜘蛛难以判断哪一頁更值得先抓。
這些因素不會让 URL 消失，但會明顯拉長從“已發現”到“被抓取”的間隔。减少重复 URL 的數量、缩短响應時間，通常比反复提交更有效。
几個容易被誤判的点
狀態是抽样和匯總後的结果，不等于某一时刻的真實抓取行為。用它做單点结论，容易得出错誤的因果關系。
- 把“尚未抓取”当成“被惩罚”，于是改動 robots.txt 或大量删頁面。
- 一天之内反复重新提交 Sitemap，观察不到變化就繼續提交。
- 只看首頁日誌，忽略内頁的抓取情况。
一張可以照着走的核對表
- 取一批代表性的“已發現”URL，尽量覆盖不同模板。
- 在完整日誌中精确匹配，確認有無請求记錄。
- 核對 Sitemap、内鏈、推送三條通路是否都正常。
- 检查這些 URL 的响應時間和狀態碼是否稳定。
- 統計同期站点整体抓取量，看是普遍偏少還是局部問题。
- 记錄核對日期，隔一段固定周期再對比一次，看趋势而不是看單日。
這類問题的處理周期通常以周為單位，短期内的狀態跳動說明不了太多。把日誌、Sitemap 和内鏈三者對齐之後，剩下的往往就是時間和容量的問题。