有些頁面明明能被蜘蛛發現——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 质量，最後才考虑服務器與抓取频率的問题。顺序反了，容易在不重要的环节上花掉大量時間。