很多站点把“URL 被發現”当成一個终点：連結放上去了、Sitemap 提交了，就等着出结果。實际线上跑起来會發現，發現只是流水线的第一段。一個地址從被搜尋蜘蛛讀到，到真正被抓取、再到進入索引，中間隔着不止一道队列，而這几道队列的推進速度並不一致。

三個队列，三種节奏

把抓取流程拆開看，大致可以分為三段：

• 發現队列：搜尋蜘蛛從内鏈、Sitemap、外鏈、重定向等入口讀到某個 URL，把它记下来。這一步几乎不消耗站点资源，速度快、容量大。
• 抓取队列：真正發起請求、下载 HTML。這一步受服務器响應速度、抓取配額、並發限制影响，是整條鏈路上最“贵”的一段。
• 索引队列：抓回来的内容经過解析、去重、质量判断後决定是否保留。這一段基本在搜尋侧完成，站点能影响的只有内容本身和頁面质量。

三段速度不同，就會出現常见的错位：站点看到“URL 早就提交了”，但抓取那一环還堵着；或者抓取很勤快，索引那一环却迟迟没有反應。

為什么發現量總是大于抓取量

發現是廉價的。一個列表頁上有 200 條連結，一次抓取就可能带来 200 個新地址；如果這 200 條里還有分頁、篩選參數、标簽聚合，數量會成倍放大。而抓取要消耗真實带宽和服務器资源，搜尋蜘蛛不可能按發現的速度等比抓取。

差距一旦拉大，後果是队列里堆积大量低價值地址，真正需要及时更新的頁面排在後面。常见来源包括：

• 篩選參數组合出来的地址，同一批内容生成了几十個入口；
• 空列表頁、空标簽頁产生的無内容地址；
• 分頁翻到很深的頁面，越往後越没有獨立價值；
• 站内搜尋结果頁、會員中心等對搜尋無意义的地址。

這些地址本身没有错，但它們會占用發現队列的注意力。更實际的做法是让它們干脆不進入队列，而不是等進了队列再想办法。

卡在哪一段，日誌里能看出来

判断节奏差卡在哪一环，最直接的材料是服務器日誌。日誌里能看到的是抓取請求，也就是第二段，所以它能回答“抓取有没有来”和“来得勤不勤”，但回答不了“有没有被索引”。

观察时可以按下面几個点看：

1. 新發布的頁面，第一次出現在日誌里距發布隔了多久；
2. 同一批新頁面是集中被抓，還是零散地被抓；
3. 老頁面被回訪的間隔有没有變化；
4. 被抓的地址里，有多少是你認為不值得抓的；
5. 服務器返回 5xx 或响應時間明顯拉長的时段，抓取量是否同步下降。

如果新頁面迟迟不出現，而老頁面抓取频繁，通常說明抓取配額被存量頁面吃掉了；如果日誌里新頁面来得很快但後續没有回訪，問题更可能在後两段。

站点端能做的几件事

站点無法直接調整搜尋蜘蛛的調度，但可以改變自己進入队列的方式：

• 控制發現入口的數量：列表頁、聚合頁只暴露有獨立價值的地址，參數型入口尽量收敛或屏蔽。
• 让重要地址集中出現：把核心頁面放在稳定出現的導航和内鏈位置上，比散落在正文某處更容易被反复讀到。
• Sitemap 保持真實：只放需要被抓的地址，lastmod 按實际修改時間更新，不要每次生成都刷新全部時間。
• 守住响應稳定性：抓取队列的推進速度與服務器表現直接相關，長時間超时或 5xx 會让抓取量整体收缩。
• 减少無效跳轉：多級重定向、软 404 都會让一次抓取的實际收益下降。

發現、抓取、索引是三個不同节奏的环节，站点能優化的主要是“進入队列的地址质量”和“服務器接得住多少請求”這两件事，其余部分只能通過持續观察去适應。

一個简單的自查顺序

遇到新頁面長期没有動静时，按這個顺序排查會比較省事：先在日誌里確認抓取是否發生，再確認被抓的地址是不是你要的那個版本（协议、主机名、路径、參數是否一致），然後看同一批頁面里有没有大量無價值地址在争抢配額，最後再看服務器在那段時間的响應情况。

抓取是一條有排队的鏈路，把每一段的實际情况分開看，比笼统地说“没收錄”更容易找到可以動手的地方。