抓取日誌里常见一種狀態：URL 已经被發現，日誌里也留下了痕迹，但迟迟没有抓取记錄。只看總量很难判断問题出在哪，把 URL 按组切開再看，堵点通常自己會浮出来。
先分清三種“没被抓”
同样是“没有抓取记錄”，背後的狀態並不一样，處理方式也完全不同：
- 未被發現：没有任何入口指向它，Sitemap 里没有，内鏈也不通，搜尋蜘蛛根本不知道這個 URL 存在。
- 被發現但未入队：入口已经把它交出去了，但由于重复變体、robots 規則、頁面價值判断等原因，抓取被压後甚至跳過。
- 入队但未抓取：URL 已经排在队列里，只是抓取频次低、服務器响應慢，或者總撞上维護窗口。
日誌能直接證明的主要是第三種，前两種要靠内鏈巡检和 Sitemap 清單交叉核對。分组之前先把這三類分開，後面的排查才不容易绕圈。
按什么维度分组
分组的目的是让每一组的頁面结构、模板和入口来源尽量一致，這样组内表現才有可比性。
- 目錄：/product/、/blog/、/help/ 各自被發現了多少、被抓了多少。
- 模板：詳情頁、列表頁、篩選頁、标簽聚合頁分開統計。
- 入口来源：從 Sitemap 進来的、從内鏈進来的、從站内搜尋頁進来的，分別看回訪情况。
- 响應表現：平均响應時間、超时比例、返回狀態碼的分布。
四個维度不必一次全上。先按目錄切一次，哪一组的“已發現 / 已抓取”比例明顯偏低，再往下按模板和入口来源细分。
几组常见结果和處理方向
低频目錄：整组只被抓了一小部分
這類目錄往往离首頁层級較深，或者長期没有新内容，抓取机會被更活跃的栏目吃掉。可以先检查這批 URL 是否在列表頁有稳定入口、分頁有没有断鏈，再决定是把它們收拢到更靠近首頁的聚合頁，還是减少重复入口、把预算留给真正需要更新的頁面。
參數與篩選頁：發現量大，抓取量小
篩選參數會成倍放大 URL 數量。如果這些頁面没有獨立價值，比較稳妥的做法是用規范标簽收敛、在 robots 中限制不必要的參數组合，或者干脆让篩選结果不生成可抓取的連結。保留下来的部分再單獨观察，看是否值得给入口。
响應慢的目錄：抓取频次被拉低
同一批 URL 里，响應時間長的目錄通常抓取間隔更長。這類問题不在 URL 本身，而在服務器和資料库查询。先確認是不是某個模板在做全表掃描，或者調用了不稳定的外部接口，修掉之後再观察日誌里的抓取間隔是否回落。
核對動作清單
- 導出最近一段時間的抓取日誌，按目錄、狀態碼、响應時間做一次基础分组。
- 把日誌里的 URL 與 Sitemap、内鏈入口清單做一次差集，找出“有入口但日誌里完全没有”的那几组。
- 對差集里的 URL 手動抽查几條，確認是否可訪問、是否返回正常狀態碼、是否存在重复變体。
- 检查這些頁面的入口位置：是在首頁導航、栏目列表，還是藏在分頁深處或需要脚本才能渲染的位置。
- 調整後固定一批样本 URL，持續跟踪它們的抓取間隔，而不是只看一次日誌。
观察周期與改動顺序
抓取行為有滞後，改動当天看不到變化是正常的。建议给自己留两到四周的观察期，期間尽量一次只改一類東西，否則後面無法判断到底是哪一步起了作用。
顺序上，先修可達性和服務器响應，再動入口结构，最後才考虑收紧或放宽 URL 數量。前面两步没做好就急着砍 URL，很可能把本来能被正常抓取的頁面一起誤伤。
分组的價值不在于把數字做得好看，而在于让每一類“發現但不抓取”都能對應到一個具体可改的動作。改完再看日誌，才知道方向對不對。