很多站点把“URL 被发现”当成一个终点：链接放上去了、Sitemap 提交了，就等着出结果。实际线上跑起来会发现，发现只是流水线的第一段。一个地址从被搜索蜘蛛读到，到真正被抓取、再到进入索引，中间隔着不止一道队列，而这几道队列的推进速度并不一致。
三个队列，三种节奏
把抓取流程拆开看，大致可以分为三段：
- 发现队列：搜索蜘蛛从内链、Sitemap、外链、重定向等入口读到某个 URL，把它记下来。这一步几乎不消耗站点资源，速度快、容量大。
- 抓取队列：真正发起请求、下载 HTML。这一步受服务器响应速度、抓取配额、并发限制影响，是整条链路上最“贵”的一段。
- 索引队列：抓回来的内容经过解析、去重、质量判断后决定是否保留。这一段基本在搜索侧完成，站点能影响的只有内容本身和页面质量。
三段速度不同，就会出现常见的错位：站点看到“URL 早就提交了”，但抓取那一环还堵着；或者抓取很勤快，索引那一环却迟迟没有反应。
为什么发现量总是大于抓取量
发现是廉价的。一个列表页上有 200 条链接，一次抓取就可能带来 200 个新地址；如果这 200 条里还有分页、筛选参数、标签聚合，数量会成倍放大。而抓取要消耗真实带宽和服务器资源，搜索蜘蛛不可能按发现的速度等比抓取。
差距一旦拉大，后果是队列里堆积大量低价值地址，真正需要及时更新的页面排在后面。常见来源包括：
- 筛选参数组合出来的地址，同一批内容生成了几十个入口；
- 空列表页、空标签页产生的无内容地址；
- 分页翻到很深的页面，越往后越没有独立价值；
- 站内搜索结果页、会员中心等对搜索无意义的地址。
这些地址本身没有错，但它们会占用发现队列的注意力。更实际的做法是让它们干脆不进入队列，而不是等进了队列再想办法。
卡在哪一段，日志里能看出来
判断节奏差卡在哪一环，最直接的材料是服务器日志。日志里能看到的是抓取请求，也就是第二段，所以它能回答“抓取有没有来”和“来得勤不勤”，但回答不了“有没有被索引”。
观察时可以按下面几个点看：
- 新发布的页面，第一次出现在日志里距发布隔了多久；
- 同一批新页面是集中被抓，还是零散地被抓；
- 老页面被回访的间隔有没有变化；
- 被抓的地址里，有多少是你认为不值得抓的；
- 服务器返回 5xx 或响应时间明显拉长的时段，抓取量是否同步下降。
如果新页面迟迟不出现，而老页面抓取频繁，通常说明抓取配额被存量页面吃掉了；如果日志里新页面来得很快但后续没有回访，问题更可能在后两段。
站点端能做的几件事
站点无法直接调整搜索蜘蛛的调度，但可以改变自己进入队列的方式：
- 控制发现入口的数量：列表页、聚合页只暴露有独立价值的地址，参数型入口尽量收敛或屏蔽。
- 让重要地址集中出现：把核心页面放在稳定出现的导航和内链位置上，比散落在正文某处更容易被反复读到。
- Sitemap 保持真实：只放需要被抓的地址，lastmod 按实际修改时间更新，不要每次生成都刷新全部时间。
- 守住响应稳定性：抓取队列的推进速度与服务器表现直接相关，长时间超时或 5xx 会让抓取量整体收缩。
- 减少无效跳转：多级重定向、软 404 都会让一次抓取的实际收益下降。
发现、抓取、索引是三个不同节奏的环节，站点能优化的主要是“进入队列的地址质量”和“服务器接得住多少请求”这两件事，其余部分只能通过持续观察去适应。
一个简单的自查顺序
遇到新页面长期没有动静时，按这个顺序排查会比较省事：先在日志里确认抓取是否发生，再确认被抓的地址是不是你要的那个版本（协议、主机名、路径、参数是否一致），然后看同一批页面里有没有大量无价值地址在争抢配额，最后再看服务器在那段时间的响应情况。
抓取是一条有排队的链路，把每一段的实际情况分开看，比笼统地说“没收录”更容易找到可以动手的地方。