盯服務器訪問日誌的人常常會遇到一種落差：搜尋蜘蛛确實来抓過蜘蛛池入口頁，心里踏實了一点；可過一段時間回头看，目标 URL 在日誌里一次都没出現過。這时候容易直接下结论说“蜘蛛池没用”，其實更常见的情况是鏈路中間某一环断了，只是没被注意到。日誌本身能提供不少线索，關键是知道该按什么顺序去對。
先分清两件事：入口頁被抓好，不等于連結被跟進
日誌里一條针對入口頁的請求，只能說明蜘蛛下载了這個頁面，不能說明它解析了頁面里的連結，更不能說明它把連結放進了待抓队列。想判断連結有没有“被讀到”，至少要看两件事：
- 目标 URL 是否真的出現在入口頁返回的 HTML 源碼里，而不是只在浏览器渲染之後才出現；
- 日誌里有没有针對目标 URL 的請求，哪怕是返回 4xx 或 5xx 也算被請求過。
如果源碼里根本没有這條連結，問题在入口頁的生成或輸出环节；如果源碼里有、日誌里却没有，問题更可能出在後續的抓取調度上。
按顺序排查几個常见断点
- 連結是否依赖脚本才出現。用“查看網頁源代碼”的方式打開入口頁，而不是只看渲染後的效果。源碼里搜不到目标 URL，說明連結没有被輸出。
- 是否被 robots.txt 或頁面級規則挡掉。確認入口頁自身没有被设為不可索引，同时確認目标 URL 所在路径没有被 robots.txt 禁止抓取。
- 入口頁是否被 WAF、CDN 或防爬策略拦住。如果日誌里响應碼異常、返回体积明顯偏小，或者只有部分 UA 能拿到完整内容，就要怀疑返回给蜘蛛的内容和返回给浏览器的内容不一致。
- 目标 URL 是否發生了重定向。如果目标 URL 做了 301 或 302，日誌里出現的會是跳轉之後的地址，看起来就像“從没被抓過”。
- 抓取频次是否本来就低。入口頁被抓的次數很少时，挂在後面的目标 URL 排队更久，短時間内看不到日誌属于正常現象。
做一個最小驗證，比反复猜更快
挑一個入口頁和一條目标 URL，單獨做一次驗證：手動抓取入口頁的原始 HTML，確認連結确實在里面；然後在接下来的一段時間里，只盯這一對 URL 的日誌，把時間、响應碼、抓取 UA 记下来。這样得到的判断比看整体資料可靠得多，也更容易区分是入口頁輸出問题，還是調度問题。
几個容易誤判的地方
- 只統計了部分日誌文件或部分时段，目标 URL 的請求恰好落在没看的区間里。
- 日誌按天轮轉後被压缩归档，检索时没有合並，導致结果不完整。
- 把蜘蛛 UA 当成唯一證據。UA 可以伪造，反過来真實蜘蛛也可能因為缓存、压缩等原因不产生预期日誌。
- 用第三方工具查询“是否被發現”，這類结果只能当參考，不能当结论。
抓取日誌是排查工具，不是结果指标。它能說明蜘蛛来過，但不能保證目标 URL 會被收錄，也不代表會有排名，這几件事之間没有等号。
鏈路都通了，接下来该看什么
如果入口頁的輸出正常、robots 規則没問题、也没有拦截和重定向，日誌里還能看到目标 URL 被請求過，那入口頁這一环基本可以認為完成了。再往下要關注的是目标 URL 自身的内容质量、可訪問性、是否存在大量重复，以及整站的抓取配額是否够用。把這些不同层面的問题混在一起看，很容易让入口頁背了不该背的责任。