有些页面明明能被蜘蛛发现——Sitemap 里有它，内链也指了过去，日志里却长时间找不到对应的抓取记录。它们既不是 404，也不是被 robots.txt 挡住，而是停在“已发现、待抓取”这一步。搞清楚这类页面为什么排队，通常比反复提交 URL 更管用。
先分清三种状态，别混在一起治
不少排查之所以越查越乱，是把三种情况当成了一种：
- 未被发现：蜘蛛根本不知道这个 URL 存在，Sitemap 没收录，也没有内链或外链入口。
- 已发现未抓取：URL 进了队列，但一直没排上，日志里看不到请求记录。
- 已抓取未收录：蜘蛛抓过，但没进索引。这属于内容质量与页面价值的范畴，和抓取本身不是一回事。
这里只讨论第二种。判断方法很直接：看服务器日志里有没有该 URL 的请求记录。有请求、有正常状态码返回，说明抓取发生过；一次请求都没有，才是队列层面的问题。
URL 排在队里，常见的几个原因
1. 新 URL 批量爆发
一次性放出几千个新页面，队列会被塞满。蜘蛛的抓取能力不会因为你产出量变大而同步增长，多出来的 URL 只能往后排。分批发、按栏目逐步放量，比一口气上线更稳妥。
2. 内链入口太弱
如果新页面只挂在某个深层列表页的第八页，周围又没有其他链接指向它，蜘蛛对它的重视程度自然低。把它接到栏目首页、相关内容模块或聚合页上，往往比再提交一次 Sitemap 更有效。
3. 同一批 URL 里混了大量低价值页
排序参数、筛选组合、分页叠加，容易生成成倍的低价值 URL。它们和真正想推的页面挤在同一个队列里，等于稀释了抓取机会。处理思路是收敛而不是硬屏蔽：能用 canonical 合并的合并，能用参数规则减少的减少。
4. 站点响应不稳定
蜘蛛排队时也会参考历史抓取体验。如果之前的抓取经常超时或返回 5xx，它可能主动降低对这个站点的访问频率，队列推进速度随之下降。这种情况下先修服务器，再谈别的优化。
用日志核对，比猜更省事
把最近一段时间的日志按状态码和路径前缀分组，能较快看出问题落在哪一段：
- 先筛出目标栏目下的 URL，看有没有请求记录。
- 有记录的，看返回码和响应时间，确认抓取过程是否顺利。
- 没记录的，对照 Sitemap 和内链，确认它到底有没有被“发现”过。
- 对比同一栏目下被频繁抓取和被忽略的页面，找结构上的差异。
差异通常落在几处：链接深度、入口数量、内容是否重复、是否被参数污染。
能落地的几个调整
- 把入口集中：让重点页面从栏目页或聚合页可以直接点到，减少只能靠翻分页才能抵达的情况。
- 控制新增节奏：新栏目分几天上线，给队列留出消化的时间。
- 清理重复 URL：同一内容只保留一个主 URL，其余用跳转或 canonical 处理。
- 保持 Sitemap 准确：只放可访问、确实需要被抓的页面，lastmod 与实际更新时间保持一致。
- 服务器先稳住：响应时间平稳、错误率低，是队列能持续推进的前提。
别把“未抓取”当成收录问题治
有些运营者会给未抓取的页面堆外链、反复提交，甚至通过蜘蛛池刷日志。如果页面本身重复、内容单薄，或者入口结构没改，抓取量上来了也只是多几条日志，页面依然不会进入索引。抓取只是前置条件，不是结果。
排查顺序建议是：先确认日志里有没有抓取记录，再检查链接结构和 URL 质量，最后才考虑服务器与抓取频率的问题。顺序反了，容易在不重要的环节上花掉大量时间。