很多站長把「URL 被發現」当成终点，其實它只是起点。URL 進入搜尋引擎的已知集合之後，還要排队等待調度，才能真正被蜘蛛請求一次。理解這段等待期，比反复追問「為什么還不抓」更有用。
發現和抓取之間隔着一個队列
搜尋蜘蛛的工作大致可以拆成几件事：從各種入口拿到新 URL、把 URL 放進待抓列表、按調度規則决定先抓谁、抓完之後進入解析與索引流程。你提交 sitemap、發一條外鏈、在文章里加一個内鏈，影响的是第一步「發現」；而抓取什么时候發生，取决于第二步之後的調度。
調度並不是先到先得。搜尋引擎會综合站点整体表現、歷史抓取成功率、頁面更新频率、服務器响應速度等因素，给每個站点分配一個大致的抓取額度，再在這個額度里排優先級。所以同一批新 URL，在不同站点上排队时長可能差出好几倍。
哪些變量會拉長等待時間
- 服務器响應慢或错誤率高：超时和 5xx 會让蜘蛛降低對站点的訪問频率，队列整体後移。
- URL 所處的連結深度太深：從首頁要跳五六次才到的頁面，通常排在浅层頁面之後。
- 頁面本身缺少更新信号：長期不變化的内容，复查間隔會自然拉長。
- 站点内大量低價值 URL 占位：參數頁、篩選頁、重复内容太多，會稀释真正需要的頁面能分到的抓取次數。
- Sitemap 信息不准确：lastmod 全站统一寫成目前時間，等于没有提供有效信号。
让 URL 排得靠前一些的做法
能做的事情不多，但都比較實在：
- 让重要頁面离首頁更近，通過導航、栏目頁、相關推荐给它稳定的内鏈入口，而不是只放在 sitemap 里。
- 保持服務器稳定，把响應時間控制在一個合理范围，避免大批量 5xx 和長時間超时。
- Sitemap 只放需要被抓的規范 URL，分片清晰，lastmod 按實际修改時間更新。
- 内容有更新时同步調整頁面的修改時間、标题或正文，让复查能拿到變化。
- 清理明顯無價值的 URL，减少蜘蛛在低产出頁面上的往返。
怎么观察排队情况
服務器日誌是按時間排序的。把「URL 第一次出現在 sitemap 或内鏈里的時間」和「日誌里第一次被蜘蛛請求的時間」做個對照，就能看出這段等待大概有多長。如果某個栏目普遍等待很久，通常指向两類問题：入口太深，或者服務器在蜘蛛訪問时不稳定。
等待時間長不等于被拒绝。它更多反映的是調度顺序，而不是對頁面價值的最终判断。
几個常见的誤判
- 「提交了推送就一定會马上抓」——推送只是加快發現，並不改變調度顺序。
- 「加了内鏈就等于排到队列前面」——還要看這條内鏈所在頁面自身的抓取频率。
- 「sitemap 里 URL 越多越好」——清單越長，越容易让真正重要的頁面被淹没。
把「發現」和「抓取」分開看，很多焦虑就變得可解释：先確認 URL 确實被發現了，再看它在队列里等了多久，最後才去排查頁面本身的問题。顺序對了，排查才不會来回绕。