很多人把搜尋抓取理解為「蜘蛛来不来」，但實际過程是一串有先後顺序的動作。任何一個环节卡住，後面的 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 不被發現」的問题其實不需要改頁面。