入口页能打开、状态码是 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，这一步做扎实了，后面的抓取和收录才有讨论的基础。