在蜘蛛池或任何以入口頁带動 URL 發現的玩法里，最常见的期待是：入口頁被搜尋蜘蛛抓了，目标 URL 就會跟上。但實际操作中更常见的情况是，目标 URL 在抓取統計或日誌里長期停在“已發現，尚未抓取”這一层，既没有抓取记錄，也没有明确的报错。這篇文章拆解這一步到底卡在哪里，以及怎么用日誌和資料做排查。
“已發現但未抓取”到底代表什么
它至少說明两件事：搜尋蜘蛛已经從某個入口頁或其他来源解析出了這個 URL，並把它放進了待抓取队列；但它還没有真正發起對目标 URL 的請求。也就是说，發現环节已经完成，卡住的是抓取环节。把這两件事混在一起，會導致排查方向完全跑偏——繼續加入口頁、繼續堆連結，通常不會让這個狀態發生變化。
常见的几類卡点
1. 站点整体抓取配額被占满
搜尋引擎给每個站点分配的抓取能力是有限的，取决于站点規模、响應速度、歷史更新频率和内容质量。如果同一時間有大量低價值 URL 在排队，比如參數頁、重复列表頁、批量生成的入口頁，目标 URL 就會被排到很後面。這时候入口頁再多，也只是往队列里塞更多待办。
2. 入口頁本身的可信度不足
從入口頁解析出的連結，其優先級很大程度上取决于入口頁自身。一個刚上线、没有任何外鏈、内容稀薄的入口頁，它给出的連結在抓取調度里優先級很低。入口頁被爬過，不代表入口頁輸出的連結會被同等對待。
3. 目标頁响應或结构存在問题
目标 URL 如果响應時間長、返回大量重定向鏈、或者首屏依赖脚本渲染，抓取調度通常會降低它的優先級。另外，同一内容對應多個 URL，比如带不同參數、不同大小寫、重复路径，會让搜尋引擎难以判断该抓哪一個，進一步拖延抓取。
4. 目标 URL 與入口頁主题跨度太大
入口頁讲 A，連結指向完全不相關的 B，這種連結在语义上很弱，被發現之後也容易被判定為低價值。
建议的排查顺序
- 先確認目标 URL 确實處于“已發現”狀態，而不是被 robots.txt、noindex 或登入墙挡在了發現环节之外。
- 在服務器日誌里搜目标 URL，確認是否真的没有任何搜尋蜘蛛請求，区分“没抓”和“抓了但没记錄”。
- 检查目标 URL 的响應時間、狀態碼、重定向鏈長度，尽量做到一次請求返回 200。
- 检查是否存在内容重复的多個 URL 變体，用 canonical 或 301 收敛到一個主 URL。
- 回看入口頁质量：是否有實质内容、連結數量是否合理、連結是否真實存在于 HTML 中。
- 观察站点整体抓取曲线，判断是不是整体配額不足，而不是單個 URL 的問题。
可以尝试的調整
- 减少無效入口頁：與其扩量，不如先保證少數入口頁能被稳定抓取，並保持内容更新。
- 缩短連結路径：让重要目标 URL 距离首頁或入口頁的点击深度更浅。
- 用 sitemap 做补充：sitemap 的作用是提示發現，不能保證抓取，但能减少完全没被發現的情况。
- 控制新 URL 的产生速度：一次放出几百上千個新 URL，抓取队列消化不完，狀態會長期停在“已發現”。
- 提升目标頁响應：稳定、快速、可缓存的頁面更容易被優先抓取。
需要明确的是：把 URL 放進蜘蛛池入口頁，只是提高被發現的概率，抓取时机和最终收錄由搜尋引擎的調度策略决定，任何手法都不能承诺结果。
用日誌驗證抓取路径
最直接的驗證方式還是看日誌：按時間排序，看搜尋蜘蛛是否訪問了入口頁，之後是否出現過目标 URL 的請求。如果入口頁有记錄、目标 URL 長期没有，那問题在抓取調度或目标頁本身；如果两者都没有，那問题還在發現环节，應该回到入口頁的連結形式、robots 設定和是否被拦截上。
整体思路是把發現和抓取拆開看，先定位到底卡在哪一步，再针對那一步做調整，而不是持續堆入口頁和連結數量。