一次抓取不等于完整讀取
很多人把“蜘蛛来過”理解為“頁面内容全部進库”。實际抓取更像一次带预算的訪問：蜘蛛先請求 URL，拿到响應头與 HTML，再解析可用連結，把新 URL 放進待抓队列。如果中途超时、响應体過大或解析被阻塞，後面的連結就可能没被取到。對 URL 發現来说，损失的不是目前頁面，而是這個頁面本该带出的下一批地址。
蜘蛛會在哪些环节“半路停下”
1. 响應時間過長
服務器處理慢、資料库卡顿、TLS 握手反复失敗，都會让蜘蛛在等待中放弃。抓取日誌里表現為請求開始後没有後續，或同一 URL 反复被尝试。连接超时和 5xx 增多时，蜘蛛通常會降低對站点的抓取频率，URL 發現速度随之放缓。
2. HTML 体积過大
把大量 JSON、内联脚本、样式和未分頁的列表塞進同一份 HTML，會让解析成本上升。蜘蛛不一定讀不完，但更可能優先抓取它認為更轻、更清晰的頁面。把主要連結放在前部、减少無意义的内联資料，有助于連結被讀到。
3. 關键連結被脚本或交互遮挡
依赖点击展開、滚動加载或异步請求後才出現的連結，蜘蛛未必會执行到底。即使能渲染，也有時間限制。重要入口最好在初始 HTML 中以标准 a 标簽存在。
4. 重定向與跳轉鏈過長
每一跳都要重新請求。跳轉次數多，抓取單個 URL 的成本增加，蜘蛛可能缩短在该路径上的停留。將重定向鏈收敛到一跳，能减少半路中断的概率。
提示：先确保頁面能稳定返回 200 和可解析的 HTML，再谈連結结构。基础不稳定时，内鏈和 Sitemap 的效果都會被放大或抵消。
半路停下對 URL 發現的影响
- 内鏈顺延變慢：列表頁没被完整解析，詳情頁可能晚几天才進入待抓队列。
- Sitemap 成為主要入口：如果内鏈断掉，蜘蛛更依赖 Sitemap 發現地址，但 Sitemap 只给 URL，不给上下文和優先級。
- 新内容窗口缩短：活動頁、时效内容如果没被及时带出，可能错過最佳抓取时机。
- 抓取频率被拉低：频繁超时會让蜘蛛認為站点不稳定，整体抓取节奏收缩。
怎么自查：從日誌和响應看問题
- 看抓取日誌中的响應碼分布，統計 5xx、超时和连接重置的比例。
- 抽查列表頁的 HTML 体积與首字节時間，確認是否因後端慢或頁面過大導致。
- 對照 Sitemap 與日誌，看已提交 URL 中有多少從未被請求，判断是發現环节還是抓取环节卡住。
- 检查重要列表頁是否在初始 HTML 中直接輸出詳情連結，而不是等脚本补充。
几個可落地的調整
控制頁面体积。把列表分頁或按需加载，但保留可抓取的分頁連結；减少内联大對象，把不參與首屏的資料後移。
稳定服務器响應。設定合理的超时與重试，监控 5xx，別让偶發抖動變成持續半路停下。
把入口放在前部。導航、分類、分頁和重要詳情連結尽量靠前，並使用普通連結。
保持 Sitemap 更新。Sitemap 不能替代内鏈，但可以在内鏈薄弱时提供兜底發現通道，尤其是新栏目和孤立 URL。
收敛重定向與參數。减少跳轉层級，避免同一内容被多個參數 URL 反复消耗抓取。
不要指望一次調整立刻见效
抓取路径的修复通常有滞後。蜘蛛需要重新訪問、重新解析並驗證稳定性，才會逐步恢复抓取频率和 URL 發現速度。更實际的做法是持續观察日誌、响應時間和 Sitemap 覆盖率，把“半路停下”的比例压下去，而不是盯着某一天的抓取量。只要入口清晰、响應稳定，URL 發現會慢慢回到正常节奏。