很多人把搜索抓取理解为「蜘蛛来不来」，但实际过程是一串有先后顺序的动作。任何一个环节卡住，后面的 URL 发现都无从谈起。把这条链路拆开看，更容易定位问题出在哪一步。
一次抓取请求的大致顺序
搜索蜘蛛访问一个 URL 前，通常要经历几个阶段：域名解析拿到 IP、建立连接与握手（HTTPS 站点还要完成证书校验）、读取 robots.txt 判断是否放行、请求目标页面、解析 HTML 中的链接并把新 URL 放进待抓队列。这个顺序决定了：越靠前的环节出问题，影响面越大。
页面本身写得再好，如果蜘蛛连域名都解析不到，或者 robots.txt 返回了超时，这次访问就止步于「发现」之前。
DNS 与连接阶段：最容易忽略的前置条件
这个阶段和网站内容无关，却直接决定抓取能否开始。常见问题包括：
- 权威 DNS 服务不稳定，解析时快时慢，不同地区结果不一致；
- 域名临近到期或解析记录被误改，部分地区直接解析失败；
- 证书过期或配置错误，握手阶段就中断；
- IPv6 记录存在但实际不可达。
这类问题在浏览器里可能因为缓存和重试被掩盖，但在抓取日志里会表现为成片的连接错误，而不是某个页面的 404。核对时优先看日志中的错误类型，而不是只看状态码分布。
robots.txt：第一道闸门，也是最容易失效的一环
蜘蛛在抓取具体页面前会先读取 robots.txt。这里有几点值得注意：
- robots.txt 必须能正常返回 200。返回 5xx 时，不同搜索引擎的处理策略不同，有的会暂停抓取，有的会按全站禁止处理；
- 文件本身要尽量轻量。如果它依赖后端逻辑、需要读数据库才能生成，一次抖动就可能拖慢整个抓取入口；
- 规则要写成蜘蛛能理解的语法，写错的规则往往不是「多放行」而是「意外全禁」；
- Sitemap 声明放在这里是成本很低的动作，但不要指望它单独解决发现延迟。
首屏 HTML：URL 发现的真正起点
页面返回之后，蜘蛛从 HTML 里提取可抓取的链接。这里的关键是链接是否「在首屏 HTML 里就有」：
- 服务端渲染或静态输出的 a 标签，发现成本最低；
- 靠 JavaScript 渲染后才出现的链接，需要额外的渲染流程，发现会滞后，也可能根本不被执行；
- 图片、按钮、表单上的跳转，通常需要脚本触发，抓取端未必跟进；
- 链接文本为空、只放图标，虽然技术上仍可能被识别，但不利于判断链接指向什么内容。
如果列表页、分类页、聚合页承担着主要的 URL 分发职责，就要保证这些页面的链接是服务端直接输出的，而不是等脚本执行完才出现。
被阻塞的资源与延迟发现
页面里引用的 CSS、JS 如果被 robots.txt 拦截，或者加载超时，可能影响渲染结果，进而影响链接的提取。资源被拦截不一定会报错，但会让渲染出的内容和用户看到的版本产生差异，链接也可能因此消失。
一个可执行的核对清单
- 用不同地区的解析工具核对域名解析结果是否一致、是否只解析到一个可用节点；
- 直接请求 robots.txt，确认返回 200、体积小、语法正确，且 Sitemap 声明可访问；
- 关闭 JavaScript 后查看列表页，确认主要入口链接依然存在；
- 检查证书有效期与 HTTPS 跳转是否形成环路；
- 在抓取日志里按错误类型分类，把连接层错误和内容层问题分开处理。
抓取链路的顺序决定排查顺序：先确认能连上，再确认放行，最后才谈链接和内容。顺序对了，很多「URL 不被发现」的问题其实不需要改页面。