用蜘蛛池做 URL 發現，最常见的一種卡壳是：入口頁看着有抓取日誌，目标 URL 却始终没有出現在抓取记錄里。這时候很多人會繼續加入口頁、加連結，但如果問题出在目标站本身，加再多入口頁也不會有變化。所以排查的第一步不是加量，而是分清這一环到底卡在哪一段。

先把鏈路拆成三段来看

從搜尋蜘蛛到目标 URL，中間其實有三段：入口頁被訪問、入口頁上的連結被解析、目标 URL 被訪問。這三段任何一段断了，结果都是目标 URL 没被抓。日誌只能告诉你结果，不能直接告诉你断点，需要自己逐段確認。

• 第一段：入口頁有没有被搜尋蜘蛛真實抓取
• 第二段：入口頁返回的 HTML 里，目标連結是否可被解析
• 第三段：目标 URL 自身的响應是否允许被抓取

第一段：入口頁是否真的被抓

別只看總訪問量，要看 UA 和 IP 归属，確認是搜尋蜘蛛而不是掃描器或采集程序。同时看返回狀態碼，如果入口頁對搜尋蜘蛛返回 403、429 或 5xx，說明抓取請求来過但没拿到内容，連結自然不會進入解析环节。

另一個容易被忽略的点是：入口頁被抓取，不代表里面的連結會被繼續處理。搜尋蜘蛛可能只取了部分内容，或者在解析前就因為頁面体积、渲染方式等問题停下。可以把入口頁用不带 JS 的方式抓一遍，看目标連結是否直接存在于源碼中。

第二段：連結是否真的能被解析

• 連結是不是通過 JS 動態插入的，源碼里没有 href
• 連結是否被 nofollow、onclick 等方式拦截
• 連結是否放在需要交互才展開的区域里
• 一個入口頁上堆了過多連結，靠後的部分容易被忽略

這几項都可以用看源碼的方式快速驗證：關掉 JS，直接看返回的 HTML，數一數能找到多少條可点連結。

第三段：目标站自身是否劝退了抓取

這是最容易被忽略的一段。入口頁做得再規范，如果目标 URL 返回软 404、要求登入、跳轉到驗證頁，或者服務器對搜尋蜘蛛频繁返回 5xx，抓取同样不會落地。

• robots.txt 是否屏蔽了搜尋蜘蛛
• 頁面是否設定了 noindex，或者 canonical 指向了別的 URL
• 是否因為地区、UA、频控而返回了不同内容
• 服務器响應時間是否過長，導致請求被提前中断

驗證方式並不复杂：用和搜尋蜘蛛接近的 UA、不带 Cookie 請求一次目标 URL，看狀態碼、看最终落地頁面、看响應時間。如果這一步就已经異常，那問题不在蜘蛛池。

一個可执行的排查顺序

1. 確認入口頁被搜尋蜘蛛抓取過，且返回狀態碼正常
2. 關閉 JS 查看入口頁源碼，確認目标連結直接可见
3. 检查連結是否带 nofollow 或依赖跳轉脚本
4. 用近似搜尋蜘蛛的 UA 請求目标 URL，看狀態碼與内容
5. 检查目标站的 robots.txt、noindex、canonical 等設定
6. 對比入口頁日誌與目标站日誌，看請求是否真的到達過目标站

如果目标站日誌里從来没出現過搜尋蜘蛛的請求，問题多半在入口頁到連結這一段；如果目标站日誌里出現過請求但狀態碼異常，問题就在目标站本身。

容易走偏的两種做法

第一種是不看日誌就不断加入口頁，把量不够当成唯一解释；第二種是看到目标 URL 没被抓取，就去改目标站的内容。两種做法都在没有定位断点的情况下動手，改動越多，越难判断哪一步起了作用。

更稳妥的做法是先固定一個入口頁、一個目标 URL 做小范围驗證，確認鏈路能通，再考虑扩量。這样即使後面效果不理想，也知道该往哪一段繼續查。