入口頁能打開、狀態碼是 200，日誌里也能看到搜尋蜘蛛的訪問记錄，但目标 URL 迟迟没有動静——遇到這種情况，很多人第一反應是去加更多入口頁，却忽略了更基础的一步：蜘蛛到底有没有從這段 HTML 里把連結讀出来。如果連結在解析阶段就没被识別，或者被识別成一個乱碼地址，後面所有的抓取、收錄讨论都無從谈起。
搜尋蜘蛛是怎么從 HTML 里找連結的
搜尋蜘蛛拿到入口頁的响應体後，會用一個容错能力比較强的解析器去提取連結元素，主要是 a 标簽的 href 属性。所谓容错，是指它不會因為頁面里有几個未閉合的标簽就整体放弃，普通的结构瑕疵一般不影响連結提取。
但容错不等于萬能。有三種情况會让連結在“讀取”這一步直接丢失：一是 href 的内容本身不是有效地址；二是這段 HTML 根本没被当作連結元素處理；三是地址被解析到了错誤的域名或路径上。
字符集声明错誤，是最容易被忽略的一類
如果頁面實际是 GBK 编碼，却在头部声明成 utf-8，或者干脆没有任何编碼声明，那么 href 里只要出現中文、特殊符号或百分号编碼，就可能在解析时變成乱碼。蜘蛛随後會去請求這個乱碼地址，结果要么 404，要么指向完全無關的路径。
這種情况的典型表現是：日誌里入口頁被正常抓取，响應 200，但目标 URL 目錄下没有任何蜘蛛訪問记錄，或者出現一批明顯不對的 404 請求。
可以這样检查
- 用命令行工具直接看响應头里的 Content-Type 是否带 charset，並和頁面内 meta charset 對照；
- 用浏览器“查看網頁源代碼”而不是看開發者工具里的渲染结果，確認肉眼看到的連結和源碼一致；
- 從入口頁里挑一條連結，手工拼成绝對地址在浏览器打開，看是否能正常訪問。
HTML 结构問题在什么情况下會真的影响解析
大多數嵌套错誤、标簽未閉合，蜘蛛都能自行修正，不必過度紧張。下面几種則比較實在：
- 連結寫在注释区块里：注释内容不會被当作連結處理；
- 連結由脚本渲染後才有：只抓原始 HTML 时看不到這些地址；
- href 為空、寫成 javascript: 或只有一個井号：没有可抓取的目标地址；
- 属性引号缺失或错位：解析器可能把整段标簽拆错，href 取出来是残缺字符串；
- base 标簽寫错：相對路径會按 base 里的域名拼接，结果連結指向了另一個站点甚至不存在的路径。
排查這類問题时，判断标准不是“頁面看起来正常”，而是“從源碼里能否稳定提取出可訪問的绝對地址”。
一套從源碼到日誌的排查顺序
- 抓原始 HTML，不要看渲染後的 DOM，確認連結是否真實存在于响應体里；
- 確認 Content-Type、meta charset 與實际文件编碼三者一致；
- 检查是否存在 base 标簽，以及它指向的域名是否符合预期；
- 把入口頁里的目标連結全部抽出来，逐條驗證能否打開；
- 用抓取工具模拟一次，看它识別到的連結列表與手工结果是否一致；
- 最後再和服務器日誌對照，確認蜘蛛實际請求的地址與预期是否吻合。
结论
入口頁被搜尋蜘蛛抓取，只說明頁面被讀到了，並不說明里面的目标 URL 會被發現。编碼声明错乱、HTML 结构损坏、base 标簽寫偏，都會让連結在解析环节就断掉，表現却和“抓了但没收錄”非常像。與其不断堆入口頁數量，不如先保證每一條入口頁里的目标地址都能被正确解析成可訪問的绝對 URL，這一步做扎實了，後面的抓取和收錄才有讨论的基础。