入口頁上线一段時間，日誌里能看到搜尋蜘蛛来過，但目标 URL 的抓取记錄一直没出現。這種时候很多人第一反應是“入口頁不够多”或者“目标站被惩罚了”，其實更常见的是一两個具体的技術细节把跟進路径掐断了。判断顺序比數量更重要。
先分清“跳過”是哪種表現
日誌里的“来過”和“抓了”是两件事，先把現象归類，後面的排查才不至于乱。
- 入口頁被抓，頁面里的連結一條都没被請求：問题多半出在連結本身或頁面解析环节。
- 入口頁被抓，部分連結被請求，目标 URL 没有：可能是連結位置、數量或頁面体量導致抓取中断。
- 連結被請求了，目标 URL 返回異常或請求失敗：問题在目标站一侧。
入口頁侧的排查
連結是否真的能被解析出来
把入口頁 HTML 直接拉下来看源碼，而不是看浏览器渲染後的效果。常见問题包括：連結由 JavaScript 動態插入、锚点寫成按钮、href 為空或寫成井号、被前端框架包在需要交互才展開的容器里。搜尋蜘蛛拿到的是原始 HTML，看不到点击之後才出現的東西。
頁面的响應與狀態
確認入口頁返回的是 200，不是 302 跳去別處，也不是带 noindex 的頁面。如果入口頁本身把蜘蛛導向了另一個地址，蜘蛛會去抓那個地址，入口頁里的連結自然無人問津。
連結是否過于集中
一個頁面塞几百條連結、正文几乎没有，蜘蛛可能只抓前面一小部分就离開。連結數量和頁面体积的取舍属于抓取预算問题，和目标站质量無關。
目标站侧的排查
- 目标 URL 是否可正常訪問：狀態碼是否正常、跳轉鏈是否過長、是否對部分 UA 返回不同内容。
- robots.txt 是否屏蔽了對應目錄或蜘蛛。
- 頁面是否自带 noindex，或者 canonical 指向了別的地址。
- 目标站服務器是否對陌生来源的請求做了限速或拦截，導致蜘蛛請求失敗。
這一侧的特征是：連結被請求過，但返回结果不理想，或者請求直接失敗。和入口頁没關系，繼續加入口頁也解决不了。
用日誌做交叉驗證
- 按 UA 過滤出搜尋蜘蛛的請求行，先確認入口頁确實被抓過。
- 在入口頁被抓的時間点之後，查同一蜘蛛 IP 段是否請求過目标 URL。
- 把請求结果狀態碼一起看：是 200、404、5xx，還是根本没請求。
- 對比不同入口頁：如果所有入口頁的連結都没被跟進，問题偏向入口頁；如果只有某一個入口頁的没被跟進，問题多半在這一頁。
几個容易誤判的情况
一是時間窗口太短。發現連結和真正抓取本来就不是同一個動作，隔几個小时看没動静不代表失敗，建议观察几天再下结论。二是把“蜘蛛来過首頁”当成“蜘蛛掃過全站”，很多入口頁只被抓了根地址，内頁連結還没轮到。三是只看第三方工具的資料，工具抽样和真實日誌有出入，以自己服務器的日誌為准。
排查顺序建议固定下来：先確認現象属于哪一類，再看入口頁能否被解析和抓取，最後才查目标站。反過来查，很容易在目标站上白折腾半天，真正的問题却在入口頁的一行 HTML 里。
如果两邊都排查過仍然没有跟進记錄，可以把入口頁數量、連結形態、目标站狀態整理成一份對照表，小范围改動後再观察，而不是一次性全量調整——否則改完之後你也不知道是哪一步起了作用。