在抓取报告里，「已发现，尚未抓取」是一个容易被误读的状态。它说明蜘蛛已经知道这个 URL 存在，只是还没安排去下载它。知道不等于会抓，更不等于抓不到——多数情况下，它只代表排队。
这个状态到底在说什么
把抓取流程拆开看，一个 URL 大致会经历两段：先是发现，再是抓取。
- 发现：蜘蛛从内链、Sitemap、外链或者历史记录里看到了这个地址，把它记进待抓列表。
- 抓取：蜘蛛真的发请求把页面下载回来。这一步要花时间、占连接、消耗服务器资源。
「已发现，尚未抓取」正好卡在两步之间。地址在名单里，但还没轮到它。名单越长，等的时间越久，这和页面质量好坏不一定直接相关。
为什么会积压
待抓名单比抓取能力大得多
站点如果在短时间内产出大量新 URL——筛选参数、排序参数、日历页、标签组合——名单会迅速膨胀。蜘蛛每天能抓的数量有限，多出来的部分只能往后排。
一部分 URL 本身不值得抓
低价值地址不只是浪费自己的机会，还会占住排队位置。内容重复的列表页、只差一个参数的结果页、空标签页，都会拉长真正重要页面的等待时间。
单次抓取耗时被拉长
响应慢、首字节时间长、频繁超时，都会让蜘蛛在一次抓取上耗掉更多时间。同样的抓取窗口里，能完成的请求数就变少了，积压自然更明显。
先减负，再谈催抓
看到积压就想办法让蜘蛛「快点来」，往往效果有限。更稳的顺序是先把名单压小，再推动重点地址。
- 列出积压里的地址类型，按参数页、分页、标签页、筛选页分类，看哪一类占比最大。
- 砍掉不该被抓的地址：能用 robots.txt 屏蔽的批量参数路径先屏蔽，能合并的重复列表合并，能从内链里撤掉的低价值入口撤掉。
- 收拢内链，让重要页面从首页出发的点击层级更浅，减少蜘蛛在无关页面之间来回走。
- Sitemap 只放你确实希望被抓的地址，不要把所有生成的 URL 一股脑塞进去。
- 改善响应速度，尤其是服务器稳定性和高峰期表现。
- 做完以上再看积压变化，给至少几周时间，别当天看当天判断。
那些看着像催抓、其实没用的操作
- 反复提交 Sitemap：提交只是告诉蜘蛛地址存在，不能改变排队顺序。
- 批量修改 lastmod：时间戳和实际内容对不上，只会削弱这个信号的可信度。
- 到处发外链指向同一个地址：发现路径已经够了，再多也只是重复「发现」。
- 短时间内大量新建页面：在积压没缓解前，这等于继续往名单里加人。
抓取是有限资源的分发问题。让蜘蛛少走一趟弯路，通常比让它多来一趟更有效。
怎么判断减负有没有效果
把服务器日志按时间段切片，比较减负前后蜘蛛请求的总量、落在重点目录上的比例，以及「已发现，尚未抓取」数量的走向。如果总请求没涨，但重点页面的被抓次数上升了，说明路由在往好的方向走。反过来，如果总请求涨了、重点页面却没变化，多半是低价值地址又多了。
这个状态更像体检指标，而不是故障报警。它提示的是分发效率，而不是某个页面出了问题。处理它，从名单里减东西比从外面加推力更实际。